Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It took years to root out and torch flawed APIs from the JVM ecosystem. After that example, it’s hard to defend neglecting the problem again and launching with no solution.


No language launches perfectly.

If the cost of adding generics later is "existing code still works, and now this can work too" versus "the old version of genetics is flawed, burn everything down and use this version instead" or "generics didn't work out the way we wanted, use this new thing that's totally-not-generics-wink-wink"...

Well, I'd say waiting is the right call. You're already used to adding three extra lines of boilerplate after every single line of code for error handling, living without generics wasn't that hard.

Hell, I recall half the go community was convinced they weren't needed at all by the time they came around.


> No language launches perfectly.

There's a gulf between "not launching perfectly" and launching with obvious, blatant deficiencies.

Go did the latter. Generics were always going to have to be implemented eventually, at least two languages in basically the space Go was targeting had had to bite that bullet in the decade before it was published. Support for third-party external dependencies only made that more dire.

Instead of doing the work up-front and launching with generics, they decided to launch with ad-hoc generic builtins and "lalala can't hear you" for a decade, then finally implement half-assed generics.


Languages are not created in a vacuum, or at least sane ones are not.

Go failed to take into account the last 50 years of PL design, and it shows in its ridiculous number of shortcomings.


The idea that it would be better if go waited an additional year or two to launch with generics is laughable. That extra year probably makes the difference for the languages success.


If you mean that another language with more planning might have caught on, I think that would have been a better outcome.


Why would a better planned language win and not one that rushed and beat go to the finish?


That's not what he said. He said IF that WOULD have happened, it would have been better for everyone except for the Go designers.


My point is that if you delayed the release of Go, there’s no reason to believe you end up with a better world. So his argument is bunk.


Why not? I think his reasoning makes sense. Unless you mean that having a language with better design (but being released later) is not an improvement.


My argument is that timing is very important to adoption. Unix is not the best OS to have been designed by far, but it was the first free one. If go had been delayed, something else may have filled the slot, and there’s no reason to believe it would have been a better something else. I.e when Go did release 2 years later, but with generics, it’d be too late, and no one would care.


I'm not sure the creators of Unix would have agreed. Unix was a step in a very different direction at the time. It was a reaction to baroque operating systems that did a lot of stuff and were quite complex. The key to Unix is simplicity and, if you shave it down, that it was really a system interface definition - which enabled other people to create Unixen by offering the same system call interface with the same semantics.

It was neither free, nor do I think the timing played much of a role since there wasn't any comparable OS being made at the time. The important bit of Unix was a set of key ideas.


So laughable that Rust was only just removing the green thread runtime [1] more than two years after Go had hit 1.0 [2], yet is still fine?

[1]: https://github.com/rust-lang/rfcs/blob/master/text/0230-remo...

[2]: https://go.dev/blog/go1




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: