Programming language flamewars are particularly tedious and particularly easy to avoid, so please let's not do that here.
https://news.ycombinator.com/newsguidelines.html
We detached this subthread from https://news.ycombinator.com/item?id=32321813.
The "simple" bit is just me poking fun at Go though, so yeah sure detach away.
For example, "I was told that garbage collection knobs were an antifeature" (https://news.ycombinator.com/item?id=32323019) could easily be mistaken for trolling even if you didn't mean it that way, and indeed it derailed the thread.
Trolling, despite the original meaning of the word, is more about effects than intent (https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...). If it wasn't your intent to derail the thread and turn it into yet-another programming language flamewar, then you should have disambiguated your intent (https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...).
It is indeed a very good case study to prove Go's suitability as systems programming language.
Naturally one might add that writing compilers, assemblers and linkers isn't systems programming.
Largest profit Go gains from custom toolset - they able to buld precise GC.
Then they were able to build reliable preemptible scheduler, which would be hard as well if they use LLVM/GCC.
They've flouted good sense before too - they only recently started passing function arguments in registers.
Using jump tables to compile pattern matches has been done since the 90s at least.
If they could have simply use LLVM they would be stuck with slow compilation that Rust folks are very fond of telling. And they would not be able to use segmented stack which was differentiating factor for language.
IIRC, they were artificially capped at 1GB a few years ago since it was decided that stacks larger than that usually indicate an obvious bug, and if infinite recursion causes a goroutine stack to consume all memory on a machine, the OOM killer would make this harder to diagnose than a reproducible panic with a backtrace.
No, jesus christ, not every bad take is gaslighting.
which one?
We didn't pay for it, so I'm not going to drag anyone personally for something that's a cultural issue. If you're worried because you might use it, you'll see it in your benchmarks just like we did. If you don't have benchmarks, it's the least of your performance concerns.
In which case I'd recommend jerf's post at http://www.jerf.org/iri/post/2955, or my comments at https://news.ycombinator.com/item?id=30804253, or even just reasoning a bit from first principles about how intermediate slices would perform given Go's memory/execution model.
(alternatively)
Go is the most successful language released in the last 20 to 30 years, so if this is meant as a critique I can't see how it's valid.
Leverage an already existing compiler backend, typically GCC or LLVM – just like Julia, Rust, or Swift.
Or, similarly, target an existing, battle-tested VM – like e.g. Elixir, Kotlin, Clojure, or F#.
> Go is the most successful language released in the last 20 to 30 years
Python? Ruby? Javascript? Java? C#? TypeScript? PHP? R? Visual Basic?
Each of these options come with enormous, unavoidable, and ultimately unnecessary baggage derived from their substantial histories. They simply don't, can't, represent the full spectrum of acceptable foundations for new language development.
None of those VMs would allow for the native compilation that was another design goal.
They had specific design goals which nothing out there met.
And so will go if it implements the optimizations they implement. GCC and LLVM are not putting sleep(10) everywhere just for the sake of longer compilation times.
For you, maybe.
Generally this is done by building the language on an existing compiler backend, and the ability to do this is in fact why the backend/frontend distinction in compilers was created to begin with.
> Go is the most successful language released in the last 20 to 30 years, so if this is meant as a critique I can't see how it's valid.
False dichotomy. A language can both be popular and have left very obvious optimizations on the table for years.
Go was implemented on top of existing compiler backend. It just wasn't LLVM.
Go was based on a C compiler suite from Plan 9. See https://9p.io/sys/doc/compiler.html and https://github.com/huangguiyang/plan9-cc
Those compiler suite was very portable ("The compilers are relatively portable, requiring but a couple of weeks’ work to produce a compiler for a different computer.") which is a strength Go inherited from get go.
Also 2/3 of Go designers (Pike, Thompson) were intimately familiar with that code base by the virtue of having written it in the first place.
(some) people just get twisted that Go didn't pick LLVM because it had better optimizations as if in engineering you just look at one positive and ignore all the negatives. For LLVM the list of negatives is huge: slow compilation, gigantic code base that would take ages to learn and contribute changes, architecture that would preclude some of the optimizations in Go (Go has a very smart and fast linker where using LLVM would forced them to just use the LLVM linker, segmented stacks not possible, GC not possible) etc.
Just to put things in perspective: just implementing segmented stacks LLVM would probably require more man hours than the all the compiler work in Go 1. And would realistically require forking LLVM because why would Apple devs with bonuses tied to shipping what Apple needed care about some new language from 3 guys from Google.
You must be living in an alternate world...
I should have stopped my range at 20 years :) I wouldn't put Go into the ring with Java or PHP.
Anyway, I'm actually glad that Go went down this path exactly because it allows us to look at the decision and see the costs. I'm very curious to see if we do hit that S curve, as another poster mentioned.
But it didn't die. And today there are more C++ jobs available than a decade ago.
In contrast, today there are some new languages that can actually be good contenders for C++. My personal favourite is Dlang.
Compilers, HPC, GPGPU, game engines, OS drivers, C++ is probaly the king of those domains.
Distributed computing, GUI frameworks, mobile apps, CNCF, other contenders rule the day.
This is also why I follow GraalVM since the days it used to be MaximeVM.
I love C++, but secure like the ALGOL linage it will never be, no matter how many fixes we throw at it, because that C copy-paste compatibility layer is never going to be thrown away.
Security must be applied end to end, and not pontual.