alt Hacker NewsYou draw up a list of checkboxes, you debate each individual point until you can check them off, you don't uncheck them unless you have found a showstopping semantics error or soundness hole. Once it is complete it is implemented and then everyone who had opinions about whether it should be spelt `.await` or `/await` or `.await!()` vanishes back into the woodwork from whence they came. Where's the disconnect?
Rust works like this. Sometimes an issue can be delayed for over a decade, but eventually all the boxes are checked off and it gets stabilized in latest nightly. If Go cannot solve the single problem everyone immediately has with the language, despite multiple complete perfect proposals on how to do it, simply because they cannot pick between the proposals and are waiting for people to stop bikeshedding, then their process is a farce.
Replies
and this is how rust gains its reputation as an ugly to read language with inconsistent syntax: design by committee
Programming languages are designed systems, they need to make sense holistically. They're not simply collections of tick-boxed features that are expected to be added once their tick-box requirements are satisfied.
!RemindMe in 25 years.
Did Rust become a clusterfuck like C++?
Is Go as timeless as it was during release?
> Go cannot solve the single problem everyone immediately has with the language...
What? Survey says 13% mentioned error handling.
And some people actually do prefer it as is.
> complete perfect
This is entirely subjective and paints the Go community as being paradoxical, simultaneously obstinate and wanting change.
The disappointing reality is that Go's error handling is the least terrible option in satisfying the language design ethos and developers writing Go. I have a penchant for implementing V's style of error handling, though I understand why actually implementing it wouldn't be all sunshine and rainbows.
If Haskell was mainstream and everyone piled in and complained that objects were immutable and it adds so much noise having to deal with that using lenses or state monads or whatever, do we go with democracy or do we say wait.... maybe Haskell was meant to be like this, there are reasons something is a seperate language.
"despite multiple complete perfect proposals on how to do it"
There is no such a thing.