undefined | Better HN

0 pointsstevekemp4y ago0 comments

I suspect a lot of people outside the go-team made comments, suggestions, and proposals. But honestly, thinking back damn few of them resulted in changes to the language.

If you'll recall back in the day there were several different vendoring approaches, but ultimately the go-team proposed and implemented their preferred solution.

Similarly there have been a million generics & error-handling suggestions but none of them were introduced. It's basically lots of distracting discussions, and it doesn't feel so much like a community project that is actually seeking outside discussion and ideas. (No shame in that, but the pretense is disappointing).

Personally I'm waiting for the fuzzing-support to land in 1.18. Fuzz testing is basically magical, and amazing in reporting problems even in code with "high coverage". The generics might be nice, but off-hand I don't see that I'll be needing them in the immediate future in any of my personal projects - but I fuzz-test the hell out of a lot of my projects (which largely revolve around interpreters and compilers).

0 comments

3 comments · 2 top-level

gnfargbl4y ago· 1 in thread

I actually think this is one of the reasons I like go so much, and now write code in it almost exclusively -- it isn't really a community project, but rather a labour of love from a small number of genuine experts.

If it actually were a community project, I think we would have more of the "x := make(someType) vs. x := someType{}" TMTOWTDI that you find in other mature languages, and go would be weaker for it.

frosted-flakes4y ago

TMTOWTDI = there's more than one way to do it

ithkuil4y ago

Those community efforts may have not been have adopted, but that doesn't mean their existence hasn't informed the Go team's solution

j / k navigate · click thread line to collapse