zlacker

I don't share experience about not being suitable about bare metal. But I do have experience with high level languages doing similar things through "innovative" thinking. I've seen int overflows in Rust. I've seen libraries that waited for UDP packet to be rebroadcasted before sending another implemented in Elixir.

No Turing complete language will ever prevent people from being idiots.

It's not only programming language API and syntax. It's a conceptual complexity, which Go has very low. It's a remodeling difficulty which Rust has very high. It's implicit behavior that you get from high stack of JS/TS libraries stitched together. It's accessibility of tooling, size of the ecosystem and availability of APIs. And Golang crosses many of those checkboxes.

All the examples you've shown in your article were "huh? isn't this obvious?" to me. With your experience in C I have no idea you why you don't want to reuse same allocation multiple times and instead keeping all of them separately while reserving allocation space for possibly less than you need.

Even if you'd assume all of this should be on stack you still would crash or bleed memory through implicit allocations that exit the stack.

Add 200 of goroutines and how does that (pun intended) stack?

Is fixing those perceived footguns really a missed opportunity? Go is getting stronger every year and while it's hated by some (and I get it, some people like Rust approach better it's _fine_) it's used more and more as a mature and stable language.

Many applications don't even worry about GC. And if you're developing some critical application, pair it with Zig and enjoy cross-compilation sweetness with as bare metal as possible with all the pipes that are needed.

>>xlii+(OP)
> All the examples you've shown in your article were "huh? isn't this obvious?" to me.

It is. None of this was new to me. In C++ defining a non-virtual destructor on a class hierarchy is also not new to me, but a fair critique can be made there too why it's "allowed". I do feel like C++ can defend that one from first principles though, in a way that Go cannot.

I'm not sure what you mean by the foo99 thing. I'm guessing this is about defer inside a loop?

> Is fixing those perceived footguns really a missed opportunity?

In my opinion very yes.

>>xlii+(OP)
> With your experience in C I have no idea you why you don't want to reuse same allocation multiple times and instead keeping all of them separately while reserving allocation space for possibly less than you need.

Which part are you referring to, here?

> Even if you'd assume all of this should be on stack you still would crash or bleed memory through implicit allocations that exit the stack.

What do you mean by this? I don't mean to be rude, but this sounds confusing if you understand how memory works. What do you mean an allocation that exits the stack would bleed memory?

>>thomas+sQ
> I do feel like C++ can defend that one from first principles though, in a way that Go cannot.

How do you propose Go interfaces should be implemented then, to avoid the multiple issues the current implementation causes (more than one kind of nil is only one such issue, memory corruption under data races is another)?

>>ncruce+Yr3
As someone with extremely similar experience to thomashabets2 over my life, but less go and more rust, please allow me to compare go's Interfaces to rusts dyn Traits, both of which are implemented pretty much identically under the hood. Rust just doesn't let you construct the data nor vtable part of the interface/trait as nil/null, in any form. Either the interface/traits instances entirely whole or it can't be instanced at all. This is the way to do it, not partially filled in one part (the vtable) and not the other (the data pointer).

>>Overmi+9M3
OK, so it again all boils down to zero values.

I don't necessarily disagree that that was a design mistake, but there's zero mention of the word zero in the article.