8 ms·

I struggled for years with a chronic misunderstanding of Go. I kept trying to compare it to the usual suspects in the "next systems language" crowd (D, Rust, Zi

by sblom 5y ago

I struggled for years with a chronic misunderstanding of Go. I kept trying to compare it to the usual suspects in the "next systems language" crowd (D, Rust, Zig). That wasn't quite right. Once I realized that its sweet spot is large-ish services that you want closer to the metal than Java but for which would be silly to go as low level as C++, Go fans started making a whole lot more sense to me. I'm still not a Go fan personally—my taste in programming languages slants toward the more expressive end of the scale (C#, Rust, Scala). But at least I'm no longer confused by trying to make Go make sense where it doesn't. It's a very good tool for its kinds of jobs. Other languages also have their points of unreasonable effectiveness, too.

azth 5y ago
Define "closer to the metal than Java". What exactly does that mean, and how exactly is that an advantage?
- PeterCorless 5y ago
  "Go performance is excellent since Go compiles to bare metal and there is no runtime between the metal and the language as is the case in other languages I used in this exercise (Java & Clojure: compile to JVM bytecode, and JVM runs the bytecode, Python & Javascript: interpreted languages and the runtime runs the code (though also Python compiles to bytecode)." Source: https://www.karimarttila.fi/languages/2018/11/13/go-good-productivity-with-bare-metal.html https://www.karimarttila.fi/languages/2018/11/13/go-good-pro...
  - azth 5y ago
    That statement is misleading. You can also compile Java natively. Secondly, there is most definitely a runtime "between the metal and the language" in golang, the GC being the most obvious. This proves my thoughts that these claims are not valid.
    - nemothekid 5y ago
      >You can also compile Java natively. This is also misleading. You are implying that GraalVM isn't relatively new and that Java native compilation isn't rare. I've yet to see anyone deploy service or CLI tools that are natively compiled in Java. That statement is about as true as saying you can compile Python natively. Just because its possible doesn't mean the language is actually suited for it.
      - azth 5y ago
        I never said it was rare or not. It is possible if you truly need fast startup times. The fact of the matter, the JVM is good enough for the vast majority of the use cases, and is faster than golang so no need to even go there.
        anthk 5y ago
        >, and is faster than golang Nice joke. Go software runs much snappier and faster than any Java GUI or CLI tool.
        azth 5y ago
        Not a joke. Large real world programs are proof (otherwise, my employer will not be spending millions of dollars on reinventing performance and other toolings already present in the JVM). What golang gui programs are you comparing against? Java CLI tools compiled with GraalVM start up just as fast.
      - Cupprum 5y ago
        >That statement is about as true as saying you can compile Python natively. Python is actually compiled. When you run a file, it firstly compiles the cod into a bytecode, which is saved in ‘.pyc’ files. These are afterwards interpreted by the interpreter.
        anthk 5y ago
        So does TCL, and yet Go outperforms TCL/TK, even 8.6.
  - cpuguy83 5y ago
    There is a runtime between the metal and the language. The runtime is what makes it really nice for writing network services in. It's also what makes it really terrible for lower level things.
- Thaxll 5y ago
  Go does not have bytecode or a VM, it compiles directly to a binary with a runtime.
  - azth 5y ago
    Java (and C# I believe) can also compile to binaries. And golang has a runtime as well. Now what is the advantage again? The Java can compile to JVM bytecode and be better performing than golang, all while having superior introspection and monitoring and debugging abilities. It seems to be a win-win. Only some ideological "closer to the metal" philosophy doesn't apply, so what? If startup times are truly an issue, look at Quarkus[1] and Micronaut[2], and a lot of other frameworks that use GraalVM to compile to native binaries. [1] https://quarkus.io/ https://quarkus.io/ [2] https://micronaut.io/ https://micronaut.io/
    - sblom 5y ago
      No one insulted Java. Why so defensive? Go and Java make different tradeoffs. If you're unreasonably effective in Java and its tradeoffs work for you, that's completely fine. If you have good tools that make Java more like Go when you need Go-like characteristics, that's cool too.
      - azth 5y ago
        I'm pointing out the inconsistencies in golang fans arguments which I've seen from the very beginning since it was touted as a "systems programming language" (which has been more or less silently changed since it wasn't true, but it doesn't stop the fans from parroting it). Same goes with many other false claims about the language, which aren't just non demonstrable, but demonstrably false.
        geodel 5y ago
        Relax. Many people would call Docker/Kubernetes, and various types of databases like CockroachDB as systems. Lot of enterprises call large internal applications as "systems" There is no copyright on "systems programing" and it can be used only for OS kernels and such.
- mustache_kimono 5y ago
  Golang can usually more than halve your memory usage? The economics may dictate something more like golang.
  - azth 5y ago
    What does that have to do with being "closer to the metal"? Secondly, Java can be tuned, but its default mode of operation is to take up the most amount of memory it can in order to give you higher performance (thoughput and latency). `-Xmx` is a thing. Finally, now with GraalVM going mainstream, and frameworks like Quarkus[1] and Micronaut[2], you are able to compile Java programs to native binaries and also have lower memory usage if that's truly a restriction. [1] https://quarkus.io/ https://quarkus.io/ [2] https://micronaut.io/ https://micronaut.io/
    - mustache_kimono 5y ago
      You also asked what the advantage of golang was and I told you what the advantage was. I'm was not saying "closer to the metal" is the right description, but, if we'd stop being pedantic, I think we know what she/he meant. Some people really don't want to tune VMs. No one is saying Java doesn't have a place too. Jeez, dude.
    - unfocussed_mike 5y ago
      OK -- but you've listed a whole bunch of third party projects and technologies and tools to get Java closer to what Go does _really_ easily out of the box. I like Java (used to _love_ it about 26 years ago... been a decade since I've written any) but Go is actually a breath of fresh air for typical cross-platform systems programs.
      - azth 5y ago
        GraalVM is not third party.
        geodel 5y ago
- twic 5y ago
  The one significant thing i can think of is that Go makes pointers explicit, and allows variables and parameters which are by-value. So you can control whether some struct contains a pointer to some other struct, or just embeds the fields directly. This gives you influence over memory use patterns, access time, and garbage collection that you don't have in Java. Java is planned to gain an equivalent of this ability through primitive classes (JEP 401). As as i know, we expect to get a preview of this feature in Java 19, which should be released in September this year.
- tptacek 5y ago
  Two major things: 1. It compiles statically down to machine code; there's no JIT or bytecode interpretation execution path. 2. It offers straightforward control over the memory layout of your data structures (it doesn't offer straightforward control over the lifecycle of your memory, which is the next step towards the metal that Rust takes). The advantage is that casual Go code is generally going to be more efficient both in execution and memory usage than a casual program in a higher-level language. You can make Java do almost anything; the important thing is what languages make easy, not what they make possible.
  - codeflo 5y ago
    When the actual machine code is generated is irrelevant to the level of abstraction. There have been JIT compilers for C, and ahead-of-time compilers for C# and Java, and that changes nothing about how close to the metal any of them are. Memory layout is a valid point though. C# with its value types gives you a lot more control than Java does, but is still often grouped with Java, and I think rightly so. Go's pointers go quite a bit further, but then on the other hand, it also has high-level data structures like map as language primitives, which makes it less close to the metal as far as I'm concerned. I'd personally group all GC'd languages in roughly the same class here, but I think it's reasonable to disagree or make finer distinctions.
    - tptacek 5y ago
      By that logic, every language is equivalently close to the metal when it comes to execution, since they can all be JIT'd one way or another. It's a colorable argument but not one most practitioners would agree with.
      - codeflo 5y ago
        No, I would agree that something with a smaller runtime might be considered closer to the metal, I was talking about level of abstraction, which I think is different. One example is that a typical C code that depends on a libc is farther from the machine than C code that runs without a libc. Both might use very similar styles. I'm also not saying JIT vs. AOT is an irrelevant distinction in practice -- like everyone else, I like my programs to start fast. But in the end, you have machine code in RAM either way; the level of abstraction is, all else being equal, the same. The precise details of how that machine code gets there change nothing about how the program is written. The emphasis people put on those details aren't always warranted. I don't think they matter at all for typical backend code, which is one of Go's main niches. Edit: The earlier version of this response was maybe unnecessarily pointed, I expanded and toned it down a bit.
- fulafel 5y ago
  It wasn't claimed to be an advantage I think. It's a tradeoff.
  - azth 5y ago
    A tradeoff in what exactly?
    - fulafel 5y ago
      Shipping arch / OS / runtime vetsion neutral apps vs implementation simplicity and single file binaries, for one. Also, decoupling of the runtime from the language is huge, and lets us have nice languages like Clojure and Scala on the JVM.
mustache_kimono 5y ago
Rob Pike actually defined it exactly this way when it was introduced -- a simpler systems language, in contrast to Java. It's funny -- I actually just watched this video yesterday: https://www.youtube.com/watch?v=5kj5ApnhPAE https://www.youtube.com/watch?v=5kj5ApnhPAE
- Rochus 5y ago
  Is Java really a systems language?
  - mustache_kimono 5y ago
    That's not what I said. Pike described golang as a systems language, and specifically contrasted it with Java. Perhaps you should watch the talk.
    - Dylan16807 5y ago
      > That's not what I said. Okay, but it's a pretty reasonable interpretation, right? "Simpler X, in contrast to Y" makes it sound like Y is a less simple X.
      - mustache_kimono 5y ago
        aozgaa 5y ago
        > a simpler systems language, in contrast to Java. I read this as saying the contrast between go and java is that the former is simpler. The confusion maybe comes about because "simpler" is a comparative adjective (as opposed to, eg, "simple", which is a descriptive adjective), and because there are up to two qualities being contrasted -- simplicity and "being a systems language". Take it or leave it but I personally was a bit confused by the wording.
        Dylan16807 5y ago
unfocussed_mike 5y ago
> Once I realized that its sweet spot is large-ish services that you want closer to the metal than Java but for which would be silly to go as low level as C++, Go fans started making a whole lot more sense to me. Yep. I struggled and then I realised I could efficiently convert a complex shell pipe with a set of frustrating-to-the-customer prerequisites into a single, easily compiled cross-platform binary, and that it was really like Modula-2 and Occam to do it. That's the point I became a fan.
gameswithgo 5y ago
you aren’t closer to the metal than java
Yoric 5y ago
As far as I am concerned, Go feels like an attempt to write a systems-oriented Python. Or perhaps a systems-oriented language targeting Python developers. It's a very reasonable objective. I just happen to not be in the target audience.
- otabdeveloper4 5y ago
  Yes, there is a well-established PHP to Go pipeline among developers.
- hnhamdani2 5y ago
  I think that's pretty much aligned with Google reasoning back then. Go was designed to make it easier to onboard their fresh grads + scientists hiring,which were more familiar python to do systems stuff.
- sireat 5y ago
  Go felt to me more like improved C with GC - not surprising when Ken Thompson and Rob Pike are involved. With Go you are going to be writing a ton of very explicit for loops. The error handling also feels a bit weird. To me it seemed like a regression not to have map, filter, apply, reduce. I wrote my C for loops in the 90s! To me something like Scala feels more Python like. Both can handle similar data munging and ML tasks. Interfacing with DBs(relational or otherwise) again I'd take Python or Scala over Go just because of convenience factor. I suppose it is also question of libraries. I've grown too comfortable with the vastness that is in pip or maven. By comparison Go library landscape is relatively bare. Then again those native binaries of Go are so appealing...
  - unfocussed_mike 5y ago
    The funny thing about Go is how many different things you can recognise in it. I have a little C experience (in the distant past -- PVM, lex/yacc, Xview). I also have a little Occam and Modula-2 experience. Lots of Java and from then on a bunch of less comparable interpreted languages. Go feels idiomatically more like a Modula-2, Wirth-language expression of Occam to me than C. I like an awful lot of it. > The error handling also feels a bit weird. I think it is deliberately weird; it is designed to make you consider error handling right up front, which is where the "system language" thing comes in. No cascade of exceptions.
kevinfat 5y ago
So another way of saying this is consider the space of languages where * control over memory use and layout (in contrast java is a pig over memory usage) * some kind of easy way to use multicore (goroutines with channels or something else) * speed, good cpu utilization * garbage collected for ease of use How many mainstream languages actually fit these criteria when Go came out? None? And how many fit these criteria now?
- sblom 5y ago
  Go was definitely ahead of the curve on a few things. I'd argue C# was there (or very very close). C# has had value types (and fine-grained memory layout) since the beginning, reified generics since .NET 2.0, and also (lesser-known fact) raw pointer support (inside `unsafe {}` blocks much like Rust's approach). This was all motivated by interoperability with native code (mostly Win32 or other C-like ABIs & COM). In 2009, the concurrency paradigm in .NET was more like promises and not quite as slick as goroutines. async/await wasn't born until 2012. It wasn't on your list, but I'll toss in another point that works in favor of your original claim. ;) The main C# project also wasn't TRULY multi-platform until 2014.
- invalidname 5y ago
  To be fair Java has made some strides in memory usage. GraalVM reduces it a lot and with Valhalla (and to some degree Loom) it should be more competitive on that front (and others) with other languages.
  - bberrry 5y ago
    I'd like to add the recent addition of ZGC as a massive benefit the JVM. Pause times always measured in microseconds regardless of heap size. No other GC:ed language has that capability as far as I know.
Abishek_Muthian 5y ago
Here's where I've settled at; Any web services for which I used Java, Python before is now written in Go. The productivity(Easy to write/read) & Cost(Concurrency saves $ at scale) improvements makes it hard to not use Go here. Then what about those sweet web frameworks for Java and Python? Go makes it easy to write web services without relying on 3rd party frameworks but it does involve a learning curve which is not steep, There are some great examples[1] and thanks to readability one can learn what's happening even if they're just starting with Go(From other languages). That said, I haven't had good experience with Go on low-memory environments even at 1GB, Perhaps it requires more thorough optimization in the code reg memory usage(which defeats the aforementioned productivity) and naturally a non-GC systems language like Rust might be better suited here. Then I recently started experimenting with Go-WASM and found that the initialization less-intuitive(requires runtime wrapper), Compiled size is humongous and Go's concurrency prowess unavailable[2]. Another area where Rust seems to be a better fit but hoping that Go becomes better here, I don't want to use 4-5 different programming languages to build a single web application. [1] https://github.com/fragmenta https://github.com/fragmenta [2] https://news.ycombinator.com/item?id=30356020#30357078 https://news.ycombinator.com/item?id=30356020#30357078

by sblom 5y ago

azth 5y ago

Define "closer to the metal than Java". What exactly does that mean, and how exactly is that an advantage?

PeterCorless 5y ago
"Go performance is excellent since Go compiles to bare metal and there is no runtime between the metal and the language as is the case in other languages I used in this exercise (Java & Clojure: compile to JVM bytecode, and JVM runs the bytecode, Python & Javascript: interpreted languages and the runtime runs the code (though also Python compiles to bytecode)." Source: https://www.karimarttila.fi/languages/2018/11/13/go-good-productivity-with-bare-metal.html https://www.karimarttila.fi/languages/2018/11/13/go-good-pro...
- azth 5y ago
  That statement is misleading. You can also compile Java natively. Secondly, there is most definitely a runtime "between the metal and the language" in golang, the GC being the most obvious. This proves my thoughts that these claims are not valid.
  - nemothekid 5y ago
    >You can also compile Java natively. This is also misleading. You are implying that GraalVM isn't relatively new and that Java native compilation isn't rare. I've yet to see anyone deploy service or CLI tools that are natively compiled in Java. That statement is about as true as saying you can compile Python natively. Just because its possible doesn't mean the language is actually suited for it.
    - azth 5y ago
      I never said it was rare or not. It is possible if you truly need fast startup times. The fact of the matter, the JVM is good enough for the vast majority of the use cases, and is faster than golang so no need to even go there.
      - anthk 5y ago
        >, and is faster than golang Nice joke. Go software runs much snappier and faster than any Java GUI or CLI tool.
        azth 5y ago
        Not a joke. Large real world programs are proof (otherwise, my employer will not be spending millions of dollars on reinventing performance and other toolings already present in the JVM). What golang gui programs are you comparing against? Java CLI tools compiled with GraalVM start up just as fast.
    - Cupprum 5y ago
      >That statement is about as true as saying you can compile Python natively. Python is actually compiled. When you run a file, it firstly compiles the cod into a bytecode, which is saved in ‘.pyc’ files. These are afterwards interpreted by the interpreter.
      - anthk 5y ago
        So does TCL, and yet Go outperforms TCL/TK, even 8.6.
- cpuguy83 5y ago
  There is a runtime between the metal and the language. The runtime is what makes it really nice for writing network services in. It's also what makes it really terrible for lower level things.
Thaxll 5y ago
Go does not have bytecode or a VM, it compiles directly to a binary with a runtime.
- azth 5y ago
  Java (and C# I believe) can also compile to binaries. And golang has a runtime as well. Now what is the advantage again? The Java can compile to JVM bytecode and be better performing than golang, all while having superior introspection and monitoring and debugging abilities. It seems to be a win-win. Only some ideological "closer to the metal" philosophy doesn't apply, so what? If startup times are truly an issue, look at Quarkus[1] and Micronaut[2], and a lot of other frameworks that use GraalVM to compile to native binaries. [1] https://quarkus.io/ https://quarkus.io/ [2] https://micronaut.io/ https://micronaut.io/
  - sblom 5y ago
    No one insulted Java. Why so defensive? Go and Java make different tradeoffs. If you're unreasonably effective in Java and its tradeoffs work for you, that's completely fine. If you have good tools that make Java more like Go when you need Go-like characteristics, that's cool too.
    - azth 5y ago
      I'm pointing out the inconsistencies in golang fans arguments which I've seen from the very beginning since it was touted as a "systems programming language" (which has been more or less silently changed since it wasn't true, but it doesn't stop the fans from parroting it). Same goes with many other false claims about the language, which aren't just non demonstrable, but demonstrably false.
      - geodel 5y ago
        Relax. Many people would call Docker/Kubernetes, and various types of databases like CockroachDB as systems. Lot of enterprises call large internal applications as "systems" There is no copyright on "systems programing" and it can be used only for OS kernels and such.
mustache_kimono 5y ago
Golang can usually more than halve your memory usage? The economics may dictate something more like golang.
- azth 5y ago
  What does that have to do with being "closer to the metal"? Secondly, Java can be tuned, but its default mode of operation is to take up the most amount of memory it can in order to give you higher performance (thoughput and latency). `-Xmx` is a thing. Finally, now with GraalVM going mainstream, and frameworks like Quarkus[1] and Micronaut[2], you are able to compile Java programs to native binaries and also have lower memory usage if that's truly a restriction. [1] https://quarkus.io/ https://quarkus.io/ [2] https://micronaut.io/ https://micronaut.io/
  - mustache_kimono 5y ago
    You also asked what the advantage of golang was and I told you what the advantage was. I'm was not saying "closer to the metal" is the right description, but, if we'd stop being pedantic, I think we know what she/he meant. Some people really don't want to tune VMs. No one is saying Java doesn't have a place too. Jeez, dude.
  - unfocussed_mike 5y ago
    OK -- but you've listed a whole bunch of third party projects and technologies and tools to get Java closer to what Go does _really_ easily out of the box. I like Java (used to _love_ it about 26 years ago... been a decade since I've written any) but Go is actually a breath of fresh air for typical cross-platform systems programs.
    - azth 5y ago
      GraalVM is not third party.
      - geodel 5y ago
twic 5y ago
The one significant thing i can think of is that Go makes pointers explicit, and allows variables and parameters which are by-value. So you can control whether some struct contains a pointer to some other struct, or just embeds the fields directly. This gives you influence over memory use patterns, access time, and garbage collection that you don't have in Java. Java is planned to gain an equivalent of this ability through primitive classes (JEP 401). As as i know, we expect to get a preview of this feature in Java 19, which should be released in September this year.
tptacek 5y ago
Two major things: 1. It compiles statically down to machine code; there's no JIT or bytecode interpretation execution path. 2. It offers straightforward control over the memory layout of your data structures (it doesn't offer straightforward control over the lifecycle of your memory, which is the next step towards the metal that Rust takes). The advantage is that casual Go code is generally going to be more efficient both in execution and memory usage than a casual program in a higher-level language. You can make Java do almost anything; the important thing is what languages make easy, not what they make possible.
- codeflo 5y ago
  When the actual machine code is generated is irrelevant to the level of abstraction. There have been JIT compilers for C, and ahead-of-time compilers for C# and Java, and that changes nothing about how close to the metal any of them are. Memory layout is a valid point though. C# with its value types gives you a lot more control than Java does, but is still often grouped with Java, and I think rightly so. Go's pointers go quite a bit further, but then on the other hand, it also has high-level data structures like map as language primitives, which makes it less close to the metal as far as I'm concerned. I'd personally group all GC'd languages in roughly the same class here, but I think it's reasonable to disagree or make finer distinctions.
  - tptacek 5y ago
    By that logic, every language is equivalently close to the metal when it comes to execution, since they can all be JIT'd one way or another. It's a colorable argument but not one most practitioners would agree with.
    - codeflo 5y ago
      No, I would agree that something with a smaller runtime might be considered closer to the metal, I was talking about level of abstraction, which I think is different. One example is that a typical C code that depends on a libc is farther from the machine than C code that runs without a libc. Both might use very similar styles. I'm also not saying JIT vs. AOT is an irrelevant distinction in practice -- like everyone else, I like my programs to start fast. But in the end, you have machine code in RAM either way; the level of abstraction is, all else being equal, the same. The precise details of how that machine code gets there change nothing about how the program is written. The emphasis people put on those details aren't always warranted. I don't think they matter at all for typical backend code, which is one of Go's main niches. Edit: The earlier version of this response was maybe unnecessarily pointed, I expanded and toned it down a bit.
fulafel 5y ago
It wasn't claimed to be an advantage I think. It's a tradeoff.
- azth 5y ago
  A tradeoff in what exactly?
  - fulafel 5y ago
    Shipping arch / OS / runtime vetsion neutral apps vs implementation simplicity and single file binaries, for one. Also, decoupling of the runtime from the language is huge, and lets us have nice languages like Clojure and Scala on the JVM.

mustache_kimono 5y ago

Rob Pike actually defined it exactly this way when it was introduced -- a simpler systems language, in contrast to Java. It's funny -- I actually just watched this video yesterday: https://www.youtube.com/watch?v=5kj5ApnhPAE https://www.youtube.com/watch?v=5kj5ApnhPAE

Rochus 5y ago
Is Java really a systems language?
- mustache_kimono 5y ago
  That's not what I said. Pike described golang as a systems language, and specifically contrasted it with Java. Perhaps you should watch the talk.
  - Dylan16807 5y ago
    > That's not what I said. Okay, but it's a pretty reasonable interpretation, right? "Simpler X, in contrast to Y" makes it sound like Y is a less simple X.
    - mustache_kimono 5y ago
      - aozgaa 5y ago
        > a simpler systems language, in contrast to Java. I read this as saying the contrast between go and java is that the former is simpler. The confusion maybe comes about because "simpler" is a comparative adjective (as opposed to, eg, "simple", which is a descriptive adjective), and because there are up to two qualities being contrasted -- simplicity and "being a systems language". Take it or leave it but I personally was a bit confused by the wording.
      - Dylan16807 5y ago

unfocussed_mike 5y ago

> Once I realized that its sweet spot is large-ish services that you want closer to the metal than Java but for which would be silly to go as low level as C++, Go fans started making a whole lot more sense to me. Yep. I struggled and then I realised I could efficiently convert a complex shell pipe with a set of frustrating-to-the-customer prerequisites into a single, easily compiled cross-platform binary, and that it was really like Modula-2 and Occam to do it. That's the point I became a fan.

gameswithgo 5y ago

you aren’t closer to the metal than java

Yoric 5y ago

As far as I am concerned, Go feels like an attempt to write a systems-oriented Python. Or perhaps a systems-oriented language targeting Python developers. It's a very reasonable objective. I just happen to not be in the target audience.

otabdeveloper4 5y ago
Yes, there is a well-established PHP to Go pipeline among developers.
hnhamdani2 5y ago
I think that's pretty much aligned with Google reasoning back then. Go was designed to make it easier to onboard their fresh grads + scientists hiring,which were more familiar python to do systems stuff.
sireat 5y ago
Go felt to me more like improved C with GC - not surprising when Ken Thompson and Rob Pike are involved. With Go you are going to be writing a ton of very explicit for loops. The error handling also feels a bit weird. To me it seemed like a regression not to have map, filter, apply, reduce. I wrote my C for loops in the 90s! To me something like Scala feels more Python like. Both can handle similar data munging and ML tasks. Interfacing with DBs(relational or otherwise) again I'd take Python or Scala over Go just because of convenience factor. I suppose it is also question of libraries. I've grown too comfortable with the vastness that is in pip or maven. By comparison Go library landscape is relatively bare. Then again those native binaries of Go are so appealing...
- unfocussed_mike 5y ago
  The funny thing about Go is how many different things you can recognise in it. I have a little C experience (in the distant past -- PVM, lex/yacc, Xview). I also have a little Occam and Modula-2 experience. Lots of Java and from then on a bunch of less comparable interpreted languages. Go feels idiomatically more like a Modula-2, Wirth-language expression of Occam to me than C. I like an awful lot of it. > The error handling also feels a bit weird. I think it is deliberately weird; it is designed to make you consider error handling right up front, which is where the "system language" thing comes in. No cascade of exceptions.

kevinfat 5y ago

So another way of saying this is consider the space of languages where * control over memory use and layout (in contrast java is a pig over memory usage) * some kind of easy way to use multicore (goroutines with channels or something else) * speed, good cpu utilization * garbage collected for ease of use How many mainstream languages actually fit these criteria when Go came out? None? And how many fit these criteria now?

sblom 5y ago
Go was definitely ahead of the curve on a few things. I'd argue C# was there (or very very close). C# has had value types (and fine-grained memory layout) since the beginning, reified generics since .NET 2.0, and also (lesser-known fact) raw pointer support (inside `unsafe {}` blocks much like Rust's approach). This was all motivated by interoperability with native code (mostly Win32 or other C-like ABIs & COM). In 2009, the concurrency paradigm in .NET was more like promises and not quite as slick as goroutines. async/await wasn't born until 2012. It wasn't on your list, but I'll toss in another point that works in favor of your original claim. ;) The main C# project also wasn't TRULY multi-platform until 2014.
invalidname 5y ago
To be fair Java has made some strides in memory usage. GraalVM reduces it a lot and with Valhalla (and to some degree Loom) it should be more competitive on that front (and others) with other languages.
- bberrry 5y ago
  I'd like to add the recent addition of ZGC as a massive benefit the JVM. Pause times always measured in microseconds regardless of heap size. No other GC:ed language has that capability as far as I know.

Abishek_Muthian 5y ago

Here's where I've settled at; Any web services for which I used Java, Python before is now written in Go. The productivity(Easy to write/read) & Cost(Concurrency saves $ at scale) improvements makes it hard to not use Go here. Then what about those sweet web frameworks for Java and Python? Go makes it easy to write web services without relying on 3rd party frameworks but it does involve a learning curve which is not steep, There are some great examples[1] and thanks to readability one can learn what's happening even if they're just starting with Go(From other languages). That said, I haven't had good experience with Go on low-memory environments even at 1GB, Perhaps it requires more thorough optimization in the code reg memory usage(which defeats the aforementioned productivity) and naturally a non-GC systems language like Rust might be better suited here. Then I recently started experimenting with Go-WASM and found that the initialization less-intuitive(requires runtime wrapper), Compiled size is humongous and Go's concurrency prowess unavailable[2]. Another area where Rust seems to be a better fit but hoping that Go becomes better here, I don't want to use 4-5 different programming languages to build a single web application. [1] https://github.com/fragmenta https://github.com/fragmenta [2] https://news.ycombinator.com/item?id=30356020#30357078 https://news.ycombinator.com/item?id=30356020#30357078