Rewriting decades of core business logic would be a tremendous effort and amount of risk.
Java and C++ still run most of Google.
Why do it in the first place? Just because you can? The code works and it's written in a popular language which plenty of people know. What's the upside?
Google has gazillions of lines of system code already built. Why rewrite everything in go? There is so much other stuff to do. All rewriting achieves is add additional risk because the new code isn't battle tested.
Depends the context, but in general, yes. C++ is very close to C on this aspect, trading memory safety for performances.
Concerning google, as far as I know the codebase is mostly C++, Java, and python. Go will surely eat a bit of the Java and Python projects but it’s unlikely to see C++ being replaced any time soon.
I don't believe this is the case. Most optimized, natively compiled languages all perform similarly. Go, C, CPP, Rust, Nim, etc. I'm sure there are edge-cases where this isn't the case, but they all perform roughly the same.
The performance rift only starts when you introduce some form of a VM, and/or use an interpreted language. Even then, under certain workloads their optimizations can put them close to their native counter parts, but otherwise are generally slower.
The real reason Google didn't re-write this in Go is likely because the library is already finished, it works, a re-write would require more extensive testing, etc. Why spend precious man-hours on a needless re-write?
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Like REALLY behind, this surprises me a lot actually. Thanks for showing me that awesome benchmark page :D
How many seconds do you suppose startup time is for those tiny programs?
How many seconds do you suppose JIT is for those tiny programs?
This argument to me is usually comes from people who have not done projects of significant scale or that required high performance, which is fine not everyone works on that level of a project. But the small difference of 10ms per operation when having to do a million operations is nearly 2.7 hours of extra time. Even 1ms is an extra 0.25/hr in time. These things start adding up when you are talking about doing millions of operations. And there is nothing wrong with Go or Rust or Python, just they aren't always the right tool in the toolbox when you need raw performance. Neither is C/C++ the right tool if you don't need that level of control/performance.
When doing distributed systems or embedded work you generally learn these rules quickly as one "ok" performing system can wreck a really well planned system, or start costing a ton of money to spin up 10x the number of instances just because of one software component isn't performant.
It's still somewhat early but I do already see software being written in Rust with best in class performance (take ripgrep for a prominent example), so lumping it in with Go and Python is really a category error in my opinion.
Personally, I'm still writing C++ for the platform support, etc. but not pretending to like it.
Totally agree C++ definitely has pain points still, but I do love the fact C++ is getting pretty regular updates so it is getting better and less painful generally. Rust is something I want to use in production but haven't seen the right opportunity to do it where the risk to reward ratio was right, yet.
You're certainly right, there IS a performance difference, and in high-computing workloads, such as the one this parser is used for.
From a "regular" web developer perspective (ie. where you only a few servers/VPS's MAX) a lot of newcomers often worry about performance, and usually for most web development the answer with performance is "Yes language [here] is faster then Python/Javascript/Ruby/etc. But those languages/frameworks allow us to develop our application far faster, and ~10ms isn't an issue." Only after performance bottlenecks are discovered would we consider breaking out pieces into a lower level language.
You're completely right though, in HPC it is totally worth worrying about every millisecond, I took the wrong perspective with the implications of the performance differences.
Most of the time, and to your point, that level of performance isn't necessary so using a language that is less likely to let you take your foot off is generally the best & most correct choice. I only resort back to C/C++ when I need the pure raw performance like this parser would, or when doing embedded work. Otherwise I reach for other tools in the tool-bag that are less likely to let me maim myself unintentionally.
Please show why you don't believe this is the case.
The rest of the comment makes some claims about performance, but does not show why we should believe those claims.
For example?
Otherwise we just have: yes it is! no it isn't!
I had thought most of the systems code inside Google would be golang by now. is that not the case ? the code doesnt look too big - I dont think porting is the big issue.