Could you please stop posting flamewar comments? You've done a ton of it in this thread alone—not cool.

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.

How is that a flamewar comment? It's just an observation.

I see what you mean, but I was looking at (and responding to) the 15 comments which that account posted to this thread, which were clearly provoking and perpetuating a flamewar.

Other than my comment on "simple" I don't see what you mean. I said in another comment I think that being able to watch newer languages evolve is interesting, and this stands out as exactly one of the more interesting tradeoffs of a new toolchain.

The "simple" bit is just me poking fun at Go though, so yeah sure detach away.

I think it has to do with posting a high volume of low-information comments on provocative points.

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

Yes, that thread was trolling. The one you've responded to was not.

As I said earlier, I was responding to the total set of 15 or so comments you posted. That's a lot of comments, especially low-quality ones. We're trying for quality rather than quantity here, so if you could post in the intended spirit in the future, we'd be grateful.

https://news.ycombinator.com/newsguidelines.html

This is one case I am fully behind Go's decision not to be yet another compiler toolchain that keeps C and C++ dependencies around.

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.

Interesting how some people are unfamiliar with how technology s-curves work.

Time will tell. We have 11 years of Go to look at so I guess your argument is that we'll start seeing rapid adoption of optimizations? So 11 years to hit the upward curve of the S, if we see that.

It was too bad they had to do it. Being able to use say LLVM's compiler tech would have had it's advantages. But they wanted a good developer UX which LLVM just doesn't provide.

And disadvantages. LLVM is still hard to build precise GC with.

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.

Nice username! Is it your opinion that the creators of go were not familiar with previous language implementations?

>This seems like a good case study in rolling your own compiler toolchain from scratch.

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.

Yeah, everyone expected Go to never implement any optimization if it is not in v1.0.

Not sure what your point is. Mine is that throwing out decades of compiler optimizations is a serious cost to pay.

Thats a kind of gaslighting isn't it. Seem to be saying no one dare to write new compiler ever because v1 of new compiler will be very likely worse than v10 of existing compiler technology.

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.

I thought Go removed segmented stacks in 1.3. Is that incorrect?

Go doesn’t use segmented stacks anymore, but it does still have resizable stacks that start small and are technically able to grow to any size.

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.

I didn't say it was the wrong call. My favorite part about new languages is being able to look at their choices over the course of decades.

Well it is implied, if one talk only about great cost but not benefits.

The post is about the optimization being implemented now. The cost is that it wasn't implemented before. I find that interesting.

> Thats a kind of gaslighting isn't it.

No, jesus christ, not every bad take is gaslighting.

Another one is adding yet another reason to keep writing code in C and C++.

Generics were a mistake. @ me in the parking lot about it.

I'm hoping atomic.Pointer's performance gain offsets the dependency of ours that rushed to switch to some generic slice function library and basically doubled memory allocations on a near-critical path.

> dependency of ours

which one?

Why does it matter?

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.

why do you need to be so combative? I like to learn from others mistakes if I can. If you don't want anyone to learn anything from your issue, and force everyone to figure out everything for themself, thats your choice.

If you're interested in learning from the issue, ask "what's wrong with X?", not "who did X?"

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.

Simply show us X then. Nobody cares who wrote it.

It's your lucky day! You're replying to exactly the comment where I did!

They've made it clear - they don't want to denigrate a library they're using, likely for free. Imagine the author of that library seeing such a comment. I'm sure you'd find it educational, but it's a terrible experience for the author.

Should it be a parking lot for blue audis? Or a parking lot for red toyotas? or a parking lot for [Object object]? string? {}?

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?

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

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