> how should they incorporate the "optimizations that other languages have had for 30 years"

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?

> 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#.

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.

GCC and LLVM both have terrible UX with their ridiculous compilation times. Go wanted good developer UX so that ruled those out.

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.

> GCC and LLVM both have terrible UX with their ridiculous compilation times.

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.

Then it won't do those optimizations. Fast compiler times are more important than being the fastest at runtime. It has to be "fast enough" and given the adoption I'd say the consensus is that it already is. More optimizations are all gravy at this point.

> Fast compiler times are more important than being the fastest at runtime.

For you, maybe.

If you need the fasted language why are you using Go?

I don't. I avoid Go like the plague. My point was that you don't get to unilaterally decide for everybody whether fast compile times or runtime performance is more important.

> If O(3) people want to design a new language, how should they incorporate the "optimizations that other languages have had for 30 years" into that language that will satisfy the internet's peanut gallery?

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.

> Generally this is done by building the language on an existing compiler backend,

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.

> most successful language released in the last 20 to 30 years

You must be living in an alternate world...

Can you explain why you think the claim is incorrect. I would think it at least plausible. A huge portion of the languages in common use are all over 20 years from introduction. So Go is certain to be in the top for language introduced after 2002. Or at least I would think.

Even if you had said only the last 15 years, that would still include languages like Clojure, Rust, Typescript, Swift, and Julia. But from 20 to 30 years you start to get into the league of: C# and Java, R, Lua, PHP, Ruby... In other words, there is no way you can prove your assertion.

Just to note, I didn’t make the original assertion about the success of Go. I was only asking why your dismissal of the claim was so emphatic. I just stated that I found the assertion plausible where languages from the last 20 years were concerned and wondered why you were so certain Go could not be at the top.

Go is pretty clearly more successful than Clojure, Rust, Swift, and Julia, and at least plausibly more successful than TypeScript.

I should have stopped my range at 20 years :) I wouldn't put Go into the ring with Java or PHP.

If you had said 20 years you'd probably have been right. But going back 30 includes Python which is still WAY bigger than Go.

Python was released Feb. 20, 1991. I checked that before I posted. And I am not the original poster and did limit my comment to 20 years. But, I did forget Java in the 30 year category.

IMO when you say "20-30" that indicates an approximation for which 31 is still qualifying. But technically you are correct (the best kind).

I think these debates boil down to people just talking past each other about things that don't matter. "Blue is the most widely used color in company logos in the last 30 years" "Yeah well I like red better" Yeah, that's fine.

You’re probably right, I was thinking about amount of code in actual production use and limiting to languages from after 2002, but some people clearly had different things in mind.

Using existing compiler toolchains, obviously. In 11 years I think it's interesting to see how that has panned out. Go is very popular for a relatively new languages, yes.

Yep... and it would have likely just fizzled out as all the existing toolchains have a terrible UX and that is one of Go's best points.

Meaning keeping C and C++ alive, if nothing else as the languages those compiler toolchains are written on.

Does anyone think that C and C++ are going to die?

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.

Ten years ago, that was the feeling. C++ was perceived as a dead end. Everything was going to be Java or C#.

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.

Kind of true, depends where you look at.

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.

Not on our lifetime, but reducing the use cases that require their uses helps.

This is also why I follow GraalVM since the days it used to be MaximeVM.

I personally have no issue with C++ being used for compilers, but to each their own.

Depends on how one stands in regards to secure code.

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.

I'm quite fond of secure code but attackers don't really exploit memory unsafety in compilers as they're not often in a position to or, if they are, there are much simpler ways to execute code.

Except compilers aren't used in isolation, if one writes the compiler toolchain in C++, chances are other system critical components are also written in C++, if nothing else for the comfort of single language use.

Security must be applied end to end, and not pontual.