← Back to context

Comment by thomashabets2

1 day ago

> I believe I know where it comes from […] poking at Go that it doesn't hide abstractions

Author here.

No, this is not where it comes from. I've been coding C form more than 30 years, Go for maybe 12-15, and currently prefer Rust. I enjoy C++ (yes, really) and getting all those handle-less knives to fit together.

No, my critique of Go is that it did not take the lessons learned from decades of theory, what worked and didn't work.

I don't fault Go for its leaky abstractions in slices, for example. I do fault it for creating bad abstraction APIs in the first place, handing out footguns when they are avoidable. I know to avoid the footgun of appending to slices while other slices of the same array may still be accessible elsewhere. But I think it's indefensible to have created that footgun in the year Go was created.

Live long enough, and anybody will make a silly mistake. "Just don't make a mistake" is not an option. That's why programming language APIs and syntax matters.

As for bare metal; Go manages to neither get the benefits possible of being high level, and at the same time not being suitable for bare metal.

It's a missed opportunity. Because yes, in 2007 it's not like I could have pointed to something that was strictly better for some target use cases.

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.

  • > 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?

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