6 ms·

Sorry, I don't get what you mean. Could you elaborate or re-phrase?

• Thaxll 4y ago
  None 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 4y ago
    Does Javascript not exist?
    • imran0 4y ago
      When talking about language design, it's the first one to be kicked out.
  • dylanowen 4y ago
    Java 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 4y ago
      I'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 4y ago
        I 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 4y ago
          Yeah, 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 4y ago
            Yeah good point. I would not enjoy adding Scala throughout an established Java project unless I could really compartmentalize it
      • the_gipsy 4y ago
        Had the same experience with Scala. Oh, Option types? Cool! Wait, why am I getting NPEs??? Oh, we're using some java library, nulls galore!
        • mumblemumble 4y ago
          I've come to the conclusion that, for the most part, option types make no sense in object-oriented languages. There are exceptions, but they tend to fall into "proves the rule" territory. OCaml, for example. Not just because of the null problem. It's also that option types push you toward a "conditional logic everywhere" way of doing things, because that's how you handle the options. That's all well and good and holy in a functional language, and perhaps even a procedural one. But it's the opposite of good object-oriented design. To quote Dr. Mark Crislip, when you serve cow pie with apple pie, it does not make the cow pie better. It just makes the apple pie worse.