4 ms·
The problem with: "I'm not sure if I should use Go to write this HTTP service. I'd lose immutability tracking, I'd lose compiler-enforced thread safety, I'd lo
by Thaxll 5y ago
The problem with:
"I'm not sure if I should use Go to write this HTTP service. I'd lose immutability tracking, I'd lose compiler-enforced thread safety, I'd lose the powerful type system, I'd lose the comprehensive error handling, I'd suffer from a million little papercuts, I'd have to use the weird date formatting system, I'd have to check nil pointers, I'd...
None of the modern language do it beside Rust so every language are then bad?
- cytzol 5y agoSorry, I don't get what you mean. Could you elaborate or re-phrase?
- Thaxll 5y agoNone of the modern and popular language have immutability, compiler enforced thread safety, powerful type ( debatable ), same for nil... Java / C# / Python / Ruby so they fall in the same bucket as Go I assume?
- aidaman 5y agoDoes Javascript not exist?
- imran0 5y agoWhen talking about language design, it's the first one to be kicked out.
- dylanowen 5y agoJava has immutability and more powerful types than go. Also considering how easy it is to intermix jvm languages you could add in scala or kotlin for truly powerful type systems without null.
- mumblemumble 5y agoI've grown a little disgruntled by the hype surrounding Scala's and Kotlin's null handling. For starters "without null" is a myth. They both have null. They have to; there is no other practical option. The JDK uses null all over the place, so you need to have null in order to talk to the JDK. Now, they do still have mechanism to make null easier to handle. And they're both pretty impressive designs. (Especially Kotlin's, though I haven't tried Scala 3 yet so maybe I'm missing something wonderful there. Aesthetically, I just prefer "we're going to openly acknowledge it and tame it as much as we can" over "we're going to try to sweep it under the carpet.") But there's a sort of Amdahl's Law analogue hiding in that situation: the upper bound on how much practical null safety you can achieve is constrained by how much you can avoid relying on modules that were written in Java. And I know that's basically true of languages like Haskell, too, because you often have to rely on at least a little bit of code that was written in languages like C. But it doesn't preoccupy me the same way it does in Scala or Kotlin, where interacting directly with Java code is a much more everyday kind of affair.
- dylanowen 5y agoI was pretty skeptical of this and yes I'd rather not have null at all. In practice though I've found the boundary with Java for my scala projects to be very small. This is definitely a function of what you're building but there are a lot of great scala libraries so we rarely need to reach for java.
- mumblemumble 5y agoYeah, that's absolutely fair, a greenfield Scala project can avoid a lot of Java nowadays. But, at the other end of things, teams that were already using Java and want to start incorporating Scala don't have that option. And 10 year old Scala projects didn't originally have that option, and doing something about it now may be a lift on the scale of a complete rewrite.
- dylanowen 5y ago
- mumblemumble 5y agoI think the quote marks were there to indicate that this was walking through a hypothetical thought process that someone might go through. (It proceeds on to the next line after that, where you see the closing quote mark.) The gist of the whole thing was basically to say, "Don't make the perfect the enemy of the good."