5 ms·

because I use it in my day job, not by choice.

by trpc 7y ago

pkaye 7y ago
So what language do you think does everything the right way?
- deleted 7y ago
  [deleted]
- apta 7y ago
  That's a stawman fallacy. There is no perfect language. However, there are languages that almost are strictly superior to others. Java and C# in this case are almost strictly superior to golang in almost every front.
  - AsyncAwait 7y ago
    Well, unless you consider Go's concurrency model superior, as well as the fact that you get native binaries.
    - apta 7y ago
      Compiling to a native binary is not a strict advantage, there are many advantages for running in a managed environment, and it can be argued that for critical systems it is the superior route in fact (given that you have the resources to run said VMs, which unless you're doing embedded or resource constrained systems, is a non-issue). That being said, both Java and C# can compile to native binaries. Java is getting Fibers, basically JVM managed lightweight threads, and has a strictly superior concurrency library in the form of `java.util.concurrent`. Not to mention libraries like Vertx and Akka for concurrency and actor systems.
      - Thaxll 7y ago
        - simplicity, never worked on those projects using layers of layers with a lot of magic ( like Spring ) - memory consumption, never wondered why you never see Kubernetes sidecar / daemonset in Java / C#? because they use 5-10x the Go memory, no thank you using -xmx -xms 512MB for a simple API server. - the billions GC settings that you need to try to make something work at scale ( hello Elasticsearch ) - Don't need 200MB of library to open a file or create a REST server - maven / graddle build system that are completely bloated, in Go if you have your vendor folder checked in ( and you should ) you just do go build . and you have your single binary - 50 line stack trace that tells nothing - observability imo is better in Go, it's getting better with Oracle adding stuff into OpenJDK, but it was a pain before without paying ( jvisual vm, mission control ect .. ) I worked with Java for many years and I can tell you that Go is a breeze of fresh air, it's not perfect but it's good for what it was designed.
        apta 7y ago
        > - simplicity, never worked on those projects using layers of layers with a lot of magic ( like Spring ) Another strawman. There are many other frameworks other than Spring that are simple and performant and easy to deal with. > - memory consumption, never wondered why you never see Kubernetes sidecar / daemonset in Java / C#? because they use 5-10x the Go memory, no thank you using -xmx -xms 512MB for a simple API server. No one is requiring you to use -Xmx 512MB. The JVM will take up as much memory as you give it. And newer GCs will release unnused memory back to the OS much more aggressively. > - the billions GC settings that you need to try to make something work at scale ( hello Elasticsearch ) golang barely has any settings, which completely limits how it can be used. If you want to tune your code for throughput instead of latency, well you can't. The JVM gives you this option, and even moreso with ZGC and Shanendoah (TBs of heaps with ~1ms max latency). golang's gc can't even approach that. > - Don't need 200MB of library to open a file or create a REST server That's quite ridiculous. You don't even need any dependencies to open a file. And not all JVM web frameworks are Spring. There are many light weight alternatives. > - maven / graddle build system that are completely bloated, in Go if you have your vendor folder checked in ( and you should ) you just do go build . and you have your single binary It depends on how you configure them. golang's dependency management is non-existent, so no real comparison there. > - 50 line stack trace that tells nothing On the contrary, this is one of the biggest advantages of using the JVM or .NET. You get a stack trace telling you exactly where things happened. Compare that to golang where you get a single string and you have no idea which code path was taken to reach that error. > - observability imo is better in Go, it's getting better with Oracle adding stuff into OpenJDK, but it was a pain before without paying ( jvisual vm, mission control ect .. ) The JVM is the most superior platform for metrics, measurement, and monitoring. This is an established fact, and anyone claiming otherwise shows they don't have experience in this area.
    - takeda 7y ago
      I wouldn't necessarily call Go's concurrency model superior, it seem like that initially but after all hype died out a bit it has issues. It essentially just offers one way to do concurrency. That might fit really well for some problems, not so much for others. I don't know what to say about native binaries, when a Go's "hello world" app is as big as an entire os[1]. Perhaps I'll upset some, but IMO Go would be another obscure language that no one cared about if it didn't come from Google. [1] https://kolibrios.org/en/ https://kolibrios.org/en/
      - AsyncAwait 7y ago
        > I wouldn't necessarily call Go's concurrency model superior Sure, opinions differ, the point is that it's far from clear that Java etc. are superior in every way, certainly for some use cases. > I don't know what to say about native binaries, when a Go's "hello world" app is as big as an entire os Is that OS written in Java or C#, because that's what the discussion was about. Also, CSP is not the only way of doing concurrency in Go. The standard shared variable model with mutexes is supported as well, just not preffered. Also, size seems like an odd complaint to me in today's day of cheap disk space. On the other hand, simple deployment, no VM startup time and fast compilation speed do offer real advantages for some.
        apta 7y ago
        > On the other hand, simple deployment, no VM startup time and fast compilation speed do offer real advantages for some. Java application servers have been offering this for a long time now. Just drop in a .war file and your code is running. No need to restart, and the .war file has a small size.
        apta 7y ago
        > the point is that it's far from clear that Java etc. are superior in every way, certainly for some use cases. Once Java gets fibers, its concurrency offerings will be a strict superset of golang's. golang doesn't even offer event based async concurrency. > Also, CSP is not the only way of doing concurrency in Go. The standard shared variable model with mutexes is supported as well, just not preffered. golang doesn't even have concurrent data structures. So it's either CSP or mutexes, both not ideal for high performance code.
    - pjmlp 7y ago
      Java and .NET also produce native binaries, apparently many still don't bother to learn how.
andyfleming 7y ago
Go also has other attributes that are reasons to consider it outside of language syntax.

because I use it in my day job, not by choice.

by trpc 7y ago

because I use it in my day job, not by choice.

pkaye 7y ago

So what language do you think does everything the right way?

deleted 7y ago
[deleted]
apta 7y ago
That's a stawman fallacy. There is no perfect language. However, there are languages that almost are strictly superior to others. Java and C# in this case are almost strictly superior to golang in almost every front.
- AsyncAwait 7y ago
  Well, unless you consider Go's concurrency model superior, as well as the fact that you get native binaries.
  - apta 7y ago
    Compiling to a native binary is not a strict advantage, there are many advantages for running in a managed environment, and it can be argued that for critical systems it is the superior route in fact (given that you have the resources to run said VMs, which unless you're doing embedded or resource constrained systems, is a non-issue). That being said, both Java and C# can compile to native binaries. Java is getting Fibers, basically JVM managed lightweight threads, and has a strictly superior concurrency library in the form of `java.util.concurrent`. Not to mention libraries like Vertx and Akka for concurrency and actor systems.
    - Thaxll 7y ago
      - simplicity, never worked on those projects using layers of layers with a lot of magic ( like Spring ) - memory consumption, never wondered why you never see Kubernetes sidecar / daemonset in Java / C#? because they use 5-10x the Go memory, no thank you using -xmx -xms 512MB for a simple API server. - the billions GC settings that you need to try to make something work at scale ( hello Elasticsearch ) - Don't need 200MB of library to open a file or create a REST server - maven / graddle build system that are completely bloated, in Go if you have your vendor folder checked in ( and you should ) you just do go build . and you have your single binary - 50 line stack trace that tells nothing - observability imo is better in Go, it's getting better with Oracle adding stuff into OpenJDK, but it was a pain before without paying ( jvisual vm, mission control ect .. ) I worked with Java for many years and I can tell you that Go is a breeze of fresh air, it's not perfect but it's good for what it was designed.
      - apta 7y ago
        > - simplicity, never worked on those projects using layers of layers with a lot of magic ( like Spring ) Another strawman. There are many other frameworks other than Spring that are simple and performant and easy to deal with. > - memory consumption, never wondered why you never see Kubernetes sidecar / daemonset in Java / C#? because they use 5-10x the Go memory, no thank you using -xmx -xms 512MB for a simple API server. No one is requiring you to use -Xmx 512MB. The JVM will take up as much memory as you give it. And newer GCs will release unnused memory back to the OS much more aggressively. > - the billions GC settings that you need to try to make something work at scale ( hello Elasticsearch ) golang barely has any settings, which completely limits how it can be used. If you want to tune your code for throughput instead of latency, well you can't. The JVM gives you this option, and even moreso with ZGC and Shanendoah (TBs of heaps with ~1ms max latency). golang's gc can't even approach that. > - Don't need 200MB of library to open a file or create a REST server That's quite ridiculous. You don't even need any dependencies to open a file. And not all JVM web frameworks are Spring. There are many light weight alternatives. > - maven / graddle build system that are completely bloated, in Go if you have your vendor folder checked in ( and you should ) you just do go build . and you have your single binary It depends on how you configure them. golang's dependency management is non-existent, so no real comparison there. > - 50 line stack trace that tells nothing On the contrary, this is one of the biggest advantages of using the JVM or .NET. You get a stack trace telling you exactly where things happened. Compare that to golang where you get a single string and you have no idea which code path was taken to reach that error. > - observability imo is better in Go, it's getting better with Oracle adding stuff into OpenJDK, but it was a pain before without paying ( jvisual vm, mission control ect .. ) The JVM is the most superior platform for metrics, measurement, and monitoring. This is an established fact, and anyone claiming otherwise shows they don't have experience in this area.
  - takeda 7y ago
    I wouldn't necessarily call Go's concurrency model superior, it seem like that initially but after all hype died out a bit it has issues. It essentially just offers one way to do concurrency. That might fit really well for some problems, not so much for others. I don't know what to say about native binaries, when a Go's "hello world" app is as big as an entire os[1]. Perhaps I'll upset some, but IMO Go would be another obscure language that no one cared about if it didn't come from Google. [1] https://kolibrios.org/en/ https://kolibrios.org/en/
    - AsyncAwait 7y ago
      > I wouldn't necessarily call Go's concurrency model superior Sure, opinions differ, the point is that it's far from clear that Java etc. are superior in every way, certainly for some use cases. > I don't know what to say about native binaries, when a Go's "hello world" app is as big as an entire os Is that OS written in Java or C#, because that's what the discussion was about. Also, CSP is not the only way of doing concurrency in Go. The standard shared variable model with mutexes is supported as well, just not preffered. Also, size seems like an odd complaint to me in today's day of cheap disk space. On the other hand, simple deployment, no VM startup time and fast compilation speed do offer real advantages for some.
      - apta 7y ago
        > On the other hand, simple deployment, no VM startup time and fast compilation speed do offer real advantages for some. Java application servers have been offering this for a long time now. Just drop in a .war file and your code is running. No need to restart, and the .war file has a small size.
      - apta 7y ago
        > the point is that it's far from clear that Java etc. are superior in every way, certainly for some use cases. Once Java gets fibers, its concurrency offerings will be a strict superset of golang's. golang doesn't even offer event based async concurrency. > Also, CSP is not the only way of doing concurrency in Go. The standard shared variable model with mutexes is supported as well, just not preffered. golang doesn't even have concurrent data structures. So it's either CSP or mutexes, both not ideal for high performance code.
  - pjmlp 7y ago
    Java and .NET also produce native binaries, apparently many still don't bother to learn how.

andyfleming 7y ago

Go also has other attributes that are reasons to consider it outside of language syntax.