4 ms·

I could write a whole article on this, but my take on this is that Go occupies one space, and Java and C# occupy a different space. This happens despite the ch

I could write a whole article on this, but my take on this is that Go occupies one space, and Java and C# occupy a different space. This happens despite the checklist similarity between these languages.

whimsicalism 2y ago
Generally, I see Go replacing a lot of projects that would have previously been written in Java (namely network services/backends). Compiler is a bit of an exception, for sure.
- klodolph 2y ago
  Yes… there’s a lot of overlapping territory, for sure. Just like how Java relaces a lot of projects that would have previously been written in C++ or C.
  - whimsicalism 2y ago
    > like how Java relaces a lot of projects that would have previously been written in C++ hearing of this pains me
    - jillyboel 2y ago
      Cheaper and safer software pains you?
      - esseph 2y ago
        That's assuming it's cheaper and works, which in my experience is asking a LOT of the run of the mill Java dev.
        jillyboel 2y ago
        The amount of CVEs for C++ apps is off the charts compared to java lol
        nurettin 2y ago
        Maybe that's because people use them.
        jillyboel 2y ago
        delusional
        nurettin 2y ago
        Finally we agree.
osigurdson 2y ago
Could you perhaps elucidate with a couple of bullet points? In my view Java / C# and Go are technically the same thing. There might be some cultural differences though, which honestly, people seem to care more about anyway.
- klodolph 2y ago
  On the technical side, Java and C# are OOP languages with nominal typing, compacting GCs (at least by default), objects are reference types, can't have a reference to a variable, strings are UTF-16, async is available via promises / tasks / futures, async scheduling is cooperative, and module boundaries are primarily type boundaries. Applications are typically shipped as platform-independent with a separate runtime. Interfaces are intrinsic to objects, from a runtime perspective. You can overload methods. Easy to dynamically load code at runtime. Go has structural typing, non-compacting GCs, allows you to freely choose value / reference types, can make references to variables, strings are bytes or UTF-8, async is built-in to the runtime, async scheduling is preemptive, and module boundaries are defined by the package you’re in. Applications are typically shipped as native code with a linked-in runtime. Interfaces are extrinsic to objects, from a runtime perspective. You cannot overload functions. Hard to dynamically load code at runtime. When I write it down like this, they don’t seem all that similar to me. They’re all… garbage collected and imperative? Memory safe (or mostly) by default? That doesn’t seem like a lot of commonalities. “They are all used for backend programming” isn’t really that interesting because backend is where you can choose whatever language you want. Facebook has a ton of Hack backend, Jane Street has OCaML, etc.
  - za3faran 2y ago
    There are more overlaps with Java. It is gaining value types. Async is built into the runtime (see virtual threads), with preemptive scheduling. Its strings can be represented as bytes internally as well. It also has packages and modules for managing boundaries.
    - klodolph 2y ago
      Java value types aren’t going to be even roughly comparable to what you can do in Go. It’s just gaining something with the name “value type”, don’t let the naming similarity lead you to believe that this is conceptually like how the same-named concept in Go works. Virtual threads are not preemptive. Maybe you can point me to documentation that says otherwise, but my understanding is that virtual threads are scheduled at blocking IO points or places where the thread interacts with the runtime. Strings can be represented internally as bytes in Java but this is kind of an optimization which happens behind the scenes under specific scenarios, and it’s not a part of the string API like it is with Go. What you’re saying is technically correct but it’s not relevant. You can use package-private accessibility in Java but surely you can see the clear difference between the way Java and C# work, and the way that languages like Rust, Go, and Haskell work, where the module is the primary technique for modularization (rather than the class). I’m really just trying to describe differences here, so I don’t think it’s really useful to fight over the technical details. Go doesn’t walk like Java, doesn’t quack like Java, it doesn’t look like Java when you squint your eyes.

whimsicalism 2y ago

Generally, I see Go replacing a lot of projects that would have previously been written in Java (namely network services/backends). Compiler is a bit of an exception, for sure.

klodolph 2y ago
Yes… there’s a lot of overlapping territory, for sure. Just like how Java relaces a lot of projects that would have previously been written in C++ or C.
- whimsicalism 2y ago
  > like how Java relaces a lot of projects that would have previously been written in C++ hearing of this pains me
  - jillyboel 2y ago
    Cheaper and safer software pains you?
    - esseph 2y ago
      That's assuming it's cheaper and works, which in my experience is asking a LOT of the run of the mill Java dev.
      - jillyboel 2y ago
        The amount of CVEs for C++ apps is off the charts compared to java lol
        nurettin 2y ago
        Maybe that's because people use them.
        jillyboel 2y ago
        delusional
        nurettin 2y ago
        Finally we agree.

osigurdson 2y ago

Could you perhaps elucidate with a couple of bullet points? In my view Java / C# and Go are technically the same thing. There might be some cultural differences though, which honestly, people seem to care more about anyway.

klodolph 2y ago
On the technical side, Java and C# are OOP languages with nominal typing, compacting GCs (at least by default), objects are reference types, can't have a reference to a variable, strings are UTF-16, async is available via promises / tasks / futures, async scheduling is cooperative, and module boundaries are primarily type boundaries. Applications are typically shipped as platform-independent with a separate runtime. Interfaces are intrinsic to objects, from a runtime perspective. You can overload methods. Easy to dynamically load code at runtime. Go has structural typing, non-compacting GCs, allows you to freely choose value / reference types, can make references to variables, strings are bytes or UTF-8, async is built-in to the runtime, async scheduling is preemptive, and module boundaries are defined by the package you’re in. Applications are typically shipped as native code with a linked-in runtime. Interfaces are extrinsic to objects, from a runtime perspective. You cannot overload functions. Hard to dynamically load code at runtime. When I write it down like this, they don’t seem all that similar to me. They’re all… garbage collected and imperative? Memory safe (or mostly) by default? That doesn’t seem like a lot of commonalities. “They are all used for backend programming” isn’t really that interesting because backend is where you can choose whatever language you want. Facebook has a ton of Hack backend, Jane Street has OCaML, etc.
- za3faran 2y ago
  There are more overlaps with Java. It is gaining value types. Async is built into the runtime (see virtual threads), with preemptive scheduling. Its strings can be represented as bytes internally as well. It also has packages and modules for managing boundaries.
  - klodolph 2y ago
    Java value types aren’t going to be even roughly comparable to what you can do in Go. It’s just gaining something with the name “value type”, don’t let the naming similarity lead you to believe that this is conceptually like how the same-named concept in Go works. Virtual threads are not preemptive. Maybe you can point me to documentation that says otherwise, but my understanding is that virtual threads are scheduled at blocking IO points or places where the thread interacts with the runtime. Strings can be represented internally as bytes in Java but this is kind of an optimization which happens behind the scenes under specific scenarios, and it’s not a part of the string API like it is with Go. What you’re saying is technically correct but it’s not relevant. You can use package-private accessibility in Java but surely you can see the clear difference between the way Java and C# work, and the way that languages like Rust, Go, and Haskell work, where the module is the primary technique for modularization (rather than the class). I’m really just trying to describe differences here, so I don’t think it’s really useful to fight over the technical details. Go doesn’t walk like Java, doesn’t quack like Java, it doesn’t look like Java when you squint your eyes.