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? {}?