3 ms·
> What an extremely convenient template to dismiss any nuanced argument against "worse is better". Nuance is exactly what I'm arguing for, there's none in the
by Mawr 5y ago
> What an extremely convenient template to dismiss any nuanced argument against "worse is better".
Nuance is exactly what I'm arguing for, there's none in the article.
> You even get to question my credentials a couple times! (I apparently pick metrics that are convenient to my argument, and fundamentally misunderstand programming language design).
You're right, I apologize. I usually try hard to never directly address whoever I'm responding to on HN, but figured it was fine since it's the linked article itself. It's clear to me now that reasoning makes no sense, I should have taken the time to reword it.
> I can't help but notice you carefully use the word "attempt" when referring to the promises Go /does/ make.
It's an acknowledgment that there's space to discuss Go failing to adhere to its design principles. I'd love to read an article on small changes to Go that would provide immense benefits. However, I don't see much value in an one-sided rant on the less-valued principles not being valued highly.
> correctness underpins /everything/, it's not a hobby
> [...]
> you don't get to choose not to care about "correctness". If you don't, you're just pushing the problem onto someone else.
Correctness isn't binary. It's perfectly valid to trade off correctness for gains elsewehere.
The classic example is companies switching from dynamic languages like Ruby to Go/Java once they hit scaling issues. Does that mean Ruby is a bad language and the company should have used Go/Java from the start? No. Using Ruby gave them the development velocity that let them get to scale in the first place.
If you do need strong correctness guarantees, by all means stay away from Go and use Rust/Ada/etc. Just remember that it's not free, something had to be traded off to achieve it.
- sfvisser 5y ago> It's perfectly valid to trade off correctness for gains elsewehere. Agreed, but no-one is disputing that, right? The problem is that very often saying correctness was given up in order to gain velocity and simplicity is simply a lie. Incorrectness can easily lead to slow development and tons of complexity. It’s only fun when the trade-off is actually a trade-off.
- tialaramex 5y ago> Just remember that it's not free, something had to be traded off to achieve it. I don't think that is clear at all in the general case. There's no reason why we should believe that "something had to be traded off to achieve it". In some cases probably that's what happened, maybe even explicitly, but in other cases there are just some designs that are better than others.
- mause_piep 5y agoAgreed. I just want to make clear that Rust/Ada/etc. don't give correctness guarantees! Their compiler is just more enforcing. It's all not black and white. Rust is promoted for its correctness, but those correctness related bugs Rust prevents are an extremely low fraction of real world bugs (comparing to managed memory languages). I mean, how many type-system related bugs are there in real world projects with Java, C# or Go? Rust is promoted with "fearless concurrency". Does it prevent your code from deadlocks, which are among the most tricky bugs?
- Ar-Curunir 5y agoNull pointer bugs are prevented by idiomatic use of Option in Rust, so that’s at least one case where Rust’s focus on correctness prevents memory-safety bugs.
- yencabulator 5y agoYet many Rust code bases are littered with .unwrap(), which undoes that benefit.
- Ar-Curunir 5y agobut it's explicit; you can easily tell which lines of code will panic.
- Freaky 5y agoA great deal of the benefit of Option comes from where it isn't used - you know most things can't be null and simply don't have to think about the possibility. unwrap() bugs are annoying, yes, but at the end of the day they're just a fancy assert(), helpfully spelled out in the code and confined to bits of it where the value is Option<T>. This is a much better situation than a language where nulls can in principle turn up anywhere.
- Smaug123 5y agoI mean, just yesterday while I was running the JetBrains Rider install workflow, I hit a NullReferenceException (or whatever it's called in Java). That is a type-system related bug which arises only because Java's type system trivially represents illegal state.