11 ms·

Go 1.19 Beta 1 is released

47 points by ngaut 4y ago

Thorentis 4y ago
Coming from Python or Java, Go's standard library is worse, and it's syntax is hard to read. I don't get the appeal. Yeah, yeah, performance. Almost every Go project I've seen is not doing anything so ground breaking or performance intensive that this is an issue. Most applications where that is an actual non-func requirement end up going with C/C++ or Rust anyway. /rant
- philliphaydon 4y ago
  .NET is faster than Go for gRPC so I often wonder if it’s worth my time learning Go for performance when it seems same same.
  - quixoticelixer- 4y ago
    Yeah i really don't understand the advantage of go over c#. Async maybe?
    - kjeetgill 4y ago
      I'd argue goroutines are a mostly better alternative to async. Maybe a bit less optimal for a vast improvement of ergonomics and applicability.
      - quixoticelixer- 4y ago
        Yeah goroutines is what i meant by better async. I've used the clojure async stuff a fair bit which was heavily inspired by goroutines and it is quite nice.
      - jpgvm 4y ago
        Goroutines are better than C# async/await but C# is still a better language than Go. When Java 19 lands you can have best of both worlds. Virtual Threads are equivalent to goroutines but you have access to better languages like Java, Kotlin and Clojure.
        deleted 4y ago
        [deleted]
        morelisp 4y ago
        I don't think virtual threads will be fully baked in time for production use at Java 19. IMO we'll be waiting at least one and probably two more releases. Valhalla has also produced an amount of language machinery that results in most of the same issues as Go. (E.g. "is this function receiving an interface or concrete value?" becomes "do I have a class, value class, or primitive class?") The performance ripples of requiring value objects to be immutable also remains to be seen.
        jpgvm 4y ago
        True. I intend to start using them the moment they land in preview but there is still some caveats (namely how they interact with synchronized). I think by Java 21 they will be rock solid though which isn't really that far away in Java timescales.
        kaba0 4y ago
        Aren’t they in preview in 19 already?
        jpgvm 4y ago
        Yes technically as they have been merged but 19 isn't out until September, you can download early-access builds today but we won't see a release build until the official release date.
        morelisp 4y ago
        Sure, but by Java 21 we'll have Go 1.21 with a couple release cycles to push generics into stdlib, and we're back to more or less useless debates about aesthetic preferences and tooling priorities again.
        kaba0 4y ago
        > The performance ripples of requiring value objects to be immutable also remains to be seen Immutability is trivial to optimize away.
    - deleted 4y ago
      [deleted]
  - morelisp 4y ago
    Stock gRPC is not a great demonstration of Go’s possible performance. The code is neither clean nor fast nor idiomatic. I have no idea why it’s so messed up. (That said, C# and Java are no performance slouches and I expect they’d all be roughly comparable in the end if the Go code didn’t suck so much.)
    - jpgvm 4y ago
      C# and Java are almost always faster than Go. Go isn't fast, it's decent but nothing special for AOT native code. (atleast the standard gc compiler, llgo, gccgo etc could end up being a different story). It can show good overall performance in I/O bound workloads because of native M:N green threading though. I imagine even that is no longer a point in Go's favor when Java's Virtual Threads land and become widespread however. Go's only real interesting runtime feature was their emphasis on having a very low latency GC. This was somewhat special for a few years but between improvements made to .NET and Java's new GCs (Shanandoah and ZGC) that gap has been eliminated while these runtimes still provide better throughput on top of their now low latency. There really isn't a good performance or resource usage reason to pick Go over C#/Java anymore, all of its advantages have been eroded.
      - erik_seaberg 4y ago
        Go’s GC throughput isn’t great, but they’re pretty good at keeping values off the heap. Java’s GC is amazing, but we’ll have big working sets and boxing overhead until value types land.
        kaba0 4y ago
        I would go as far to say that Go’s performance is good only because of value types. Their GC is known to slow down allocation when under big pressure.
        Groxx 4y ago
        I was poking into a 7-10 second test a couple years ago out of curiosity, and pulled a tracing profile. Garbage collection accounted for over 95% of the run-time. It was a perfect pathological case where it continually thrashed below/above a GC threshold, without hitting the point where it would make more room. Adding just a couple kilobytes of ballast[1] pushed it over the limit to where it reliably took about 200ms. (and then I rewrote the test to stop allocating so much junk) Go's GC is mostly pretty good in practice, but yeah. It's definitely not something you can rely on blindly. Also I wish they'd stop claiming that its pause times are tiny - the stop-the-world pauses are indeed consistently very short, but it hardly matters when it can pause goroutines for far, far longer[2]. And e.g. when you're allocating, your goroutine may be paused to "help" the GC, which can take a substantial amount of time (as happened in that^ test), which frequently leads to very large tail-latency. Most people don't care about stop-the-world times, they care about tail-latency, and Go is just leaning on people's misunderstanding that one is the cause of the other. It can be, but it's not the only source. [1]: https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i-learnt-to-stop-worrying-and-love-the-heap/ https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i... [2]: http://big-elephants.com/2018-09/unexpected-gc-pauses/ http://big-elephants.com/2018-09/unexpected-gc-pauses/ among other sources of individual goroutine pauses.
- ainar-g 4y ago
  I can get that Go's stdlib is smaller than Python's, but can you elaborate on why you feel that Go's syntax is hard to read compared to Java? Because both of them are very much C-like languages, syntax-wise.
  - erik_seaberg 4y ago
    if err != nil is continuously painful. f(g(), h()) with error handling takes nine lines, maybe twelve? Everybody has to use Errorf() everywhere or nobody gets a stack trace. There are no stdlib filter/map/reduce yet, and generics are new enough that most people are still writing the same for-range loops over and over. Lambdas don’t capture loop variable values. x, y := f() sometimes assigns and sometimes shadows an outer scope. defer isn’t block scoped, you have to simulate the code to figure out which calls are stacked at this point. Hopefully they’re added deterministically, but you can keep deferring stuff in a loop if you want. (This is aside from the many ways Scala and Kotlin are far more readable than Java.)
    - johnisgood 4y ago
      I thought that "if err != nil" is much less common now because of the changes in error handling. I personally do like "if err != nil" better. I can easily ignore that when I want, and I can easily check if I am handling the error properly without any cognitive overhead.
      - erik_seaberg 4y ago
        Have a link? I don’t see any changes in https://tip.golang.org/doc/go1.19 https://tip.golang.org/doc/go1.19 that seem likely to help. How do you easily ignore the majority of the screen? Is there an editor plugin that just doesn’t display those ifs?
        ainar-g 4y ago
        The fact that you think that error handling should be ignored is probably what prevents you from seeing the point of the Go error handling. The point is that one should never only consider the happy path. That one should actually think about how things can fail, what to do about those failures, and how to report those failures with enough context to figure something out on the outside if no appropriate handing is available in the code. Stack traces only give you line numbers. Properly used explicit error handling gives you more context in which a failure occurred. Here's one example that might make it clearer: https://commandcenter.blogspot.com/2017/12/error-handling-in-upspin.html https://commandcenter.blogspot.com/2017/12/error-handling-in....
- siscia 4y ago
  The appeal of go is that it is easy to learn, you can put any young person just out of college and have it produces a lot of line of code that resemble something working. The reality is that go is a very hard language to master and to avoid footgun. But it is an hard truth that few people are willing to accept.
  - ainar-g 4y ago
    Can you provide examples of the things that are hard to master and the footguns?
    - siscia 4y ago
      Goroutine, pointers vs value, cancelling work in goroutines, avoid dead locks. What makes go powerful also make it weak. In general the complexity need to live somewhere and in go it can only be the code itself as the language is too simple.
      - ainar-g 4y ago
        The difference between pointers/references and values is there in most languages in the same ilk as Go, maybe with the exception of Java. (C# has structs, which are value types.) It's a concept pretty much any developer in that area must know. As for concurrency, that topic is hard in pretty much any mainstream language. Maybe with the exception of Rust, but Rust isn't exactly a langauge that is not “hard to master”, and even Rust doesn't protect you from all forms of concurrency issues. Merely most of them, heh.
    - BreakfastB0b 4y ago
      Concurrency is a major stumbling block https://eng.uber.com/data-race-patterns-in-go/ https://eng.uber.com/data-race-patterns-in-go/. Mutexs, conditional variable subtleties, wait groups, null pointer propagation, partial struct initialisations, channel lifetime coordination. tl;dr shared memory concurrency is hard. The introduction of generics should make it easier to wrap these lower level concurrency primitives into higher level safe constructs without needing code generation or runtime type casting via interface{}. Most devs also struggle to structure go programs in a way that makes them easily testable, but that’s true in a lot of languages.
- jpgvm 4y ago
  There is really no reason to go from Java to Go. Go may win out in the early days of a program for resource usage and perceived complexity but by the time your team has cooked up some frankenstien of an application framework and tried to standardize logging, metrics, etc you would have been better off in JVM land from the start. At least then you can pick battle-tested and supported frameworks. Python, Ruby, JS/TS -> Go is a weird one though. I can understand why when people make that transition they think Go is the best thing since sliced bread. It's by far one of the easiest languages to learn, it's miles faster than what they are coming from and the tooling is way less shit than those interpreted languages. However all of those languages represent a very very low bar. I think if the same people could be convinced to try Kotlin (or even modern Java) they would be a) surprised how easy it is these days and b) finally understand that it's ecosystem and tooling that really matters at the end of the day. Though I have to say Go existing is by and large a good thing even if I don't like it. It helps get people off things like Typescript which are absolute garbage-tier onto something half-reasonable. When they grow out of Go they generally end up somewhere better, just takes a few years.
  - tragomaskhalos 4y ago
    One area where Go has quickly established a niche is in tooling, for example Terraform. Here the benefits of being able to run a single (non-containerised) binary vs having to fret about what version of Java your punters happen to have installed in compelling no?
    - jpgvm 4y ago
      Yeah that is fair. By and large such tools remain smaller codebases so it's flaws aren't as apparent either. My personal preference for such tools is Rust but it's admittedly a harder sell. Comment above is mostly addressing the server software use case with larger teams and 100KLOC+ (either one or many programs). I don't think anyone was using Java much in the CLI niche. It was dominated mostly by Python and Ruby (and Perl before that) before Go came along. I do think Go represents an improvement on that status quo.
      - 4y ago
- johnisgood 4y ago
  I am not sure what you are trying to say. That Go does not have a place because Python and Java exist? My personal experience: I cannot get anything related to cryptography done in Java, thanks to its standard library. I would choose Go over both Python and Java. The choice depends on a lot of things. Regardless, all I get from your message is that you mind the existence of Go, which I believe is silly.
  - Thorentis 4y ago
    The solution to a good stdlib for eg crypto should not be a new language. This just complicates the landscape. C++ and Python have fantastic crypto libraries. Trying to get one included in Java would've been time better spent than coming up with an abomination of a new language. Go's stdlib has massive gaps in other areas (the fact you still have to write your own "contains" method for slices is a joke).
- fulafel 4y ago
  Lots of people dislike Java for reasons that don't apply to Go and Python.
- konart 4y ago
  >Java, Go's ... it's syntax is hard to read. Excuse me but Java? This is as subjective as it can be.
  - qsort 4y ago
    Java's syntax is the most bog-standard Algol you can imagine. There's definitely some subjectivity to it, but how is Java hard to read?
    - konart 4y ago
      Everything is too long to read. This is mine personal problem. All java code be lie `public static void SomeReallyLongNameDescribingEverthing42 implements SomeOtherEvenLongerName` For me it's 10 times harder to follow than Go's `if err` blocks (which I actually do appreciate most of the time).
      - kaba0 4y ago
        That is not a good faith argument.. the only long thing in your example is a name you yourself created, absolutely nothing inherent in the language. But taking your argument in good faith, sure naming conventions are an important part of a language, but Java’s is not “obtusely long”, but “meaningful camel-case”.
        konart 4y ago
        >meaningful camel-case CamelCase makes it even worse. Short CamelCase is quite okay, but the longer it gets, the harder it on my eyes. But even with short naming it still like 2-3 words just to name a function. wtf.
        kaba0 4y ago
        Is unreadable abbreviations better? Like, basically everything other than C has full words concatenated in various ways.
- guggle 4y ago
  Coming from Python in the field of web backends/webservices, I just find Java's ecosystem in general has too much ceremony. Go is fairly straight forward, to the point. I don't care too much for performance, but being lightweight on resources is a nice plus compared to Python (smaller VMs) and deployment is much easier. Yes, I do miss some language features (exceptions, classes...), but it's still very manageable. Of course Python has third party libraries for everything, but Go has all the basics for web services in the standard library. C++/Rust is out as I have no such performance requirement and GC is fine in my case. So that's it... Go fills a niche like a lot of other languages, so why not ?
- jurschreuder 4y ago
  I once made a video streaming platform in Python. It needed 2 big 10k euro servers to run. I then rewrote the backend in Go, which gave a 90% performance increase. It could now run all the streams on any normal pc.
  - kaba0 4y ago
    Python is the slowest mainstream language by a factor of 10. You could have easily gotten that much increase by going to even JS. Go is not faster than other mainstream managed languages like C#, Java, JS .
MarkSweep 4y ago
Interesting to see LoongArch64 support pop up in more places.
kumarvvr 4y ago
Dotnet and C# are a killer combination and I frankly dont get why go has to be even considered. Go syntax is very cognitively demanding. Maybe I am getting old or have become used to C#, but between reading well formed go and C# code, C# always wins for me.
- KronisLV 4y ago
  You might as well say the same about Java (with select codebases), or even Python. Or, for the folks who have familiarity with different stacks, maybe something along the lines of Ruby, Node or whatever else they enjoy more. Admittedly, a lot of it comes down to personal preference and familiarity with different technologies. Though in regards to Go in particular, on a technical level: - it's simple to build self-contained executables, it's up there with the likes of FreePascal in this regard - it's also a relatively simple language that's easy to pick up and use, in contrast to how complex code can get with C# and Java - it also has fewer footguns than C or C++ without the complexity of Rust (which some might prefer), although it doesn't try to do as much - it has a decent community and lots of useful packages, even the included http libraries are nice to just get things done - it doesn't have a history of challenging versioning and platform support, when compared with .NET (Windows only support with IIS for legacy projects, anyone?) - the performance is generally good enough All of that combined means that Go is nice for writing both quick utilities, as well as smaller and larger services alike. Just look at Nomad, a container orchestration platform, the executables of which can be shipped as a single binary: https://www.nomadproject.io/downloads https://www.nomadproject.io/downloads Overall, it's pretty good for just getting things done in a reasonable amount of time and a limited amount of headaches. For example, Python might lead to code that is easier to write and read, but packaging can be a nightmare. Java might be better for select enterprise systems, but configuration is generally a bit of a mess there. .NET is a good alternative, but some folks also try to steer clear of Microsoft and tooling on *nix can be limited, much like it is for Java (your best bet would be to use JetBrains commercial products, since MonoDevelop isn't all that popular anymore, Visual Studio Code plugins wouldn't give you a "full IDE" experience and there is nothing quite like Eclipse or NetBeans for .NET). Further thoughts: the age of a language might also coincide with how loved or dreaded it is, since we simply don't see that many horrible enterprise monolith messes written in Go as of yet: https://earthly.dev/blog/brown-green-language/ https://earthly.dev/blog/brown-green-language/
nikivi 4y ago
Is it possible to install the beta with brew? I tried instructions on the site: $ go install golang.org/dl/go1.19beta1@latest $ go1.19beta1 download But I don't get where the new binary is placed. It's not in my PATH.
- dmitshur 4y ago
  The go1.19beta1 binary (which you would use to try Go 1.19 Beta 1) should be placed in the usual place where 'go install' places them. If you’re using Go’s defaults, it’s likely $HOME/go/bin, unless you’ve set either GOPATH or GOBIN env vars to point somewhere else.

47 points by ngaut 4y ago

Coming from Python or Java, Go's standard library is worse, and it's syntax is hard to read. I don't get the appeal. Yeah, yeah, performance. Almost every Go project I've seen is not doing anything so ground breaking or performance intensive that this is an issue. Most applications where that is an actual non-func requirement end up going with C/C++ or Rust anyway. /rant

philliphaydon 4y ago
.NET is faster than Go for gRPC so I often wonder if it’s worth my time learning Go for performance when it seems same same.
- quixoticelixer- 4y ago
  Yeah i really don't understand the advantage of go over c#. Async maybe?
  - kjeetgill 4y ago
    I'd argue goroutines are a mostly better alternative to async. Maybe a bit less optimal for a vast improvement of ergonomics and applicability.
    - quixoticelixer- 4y ago
      Yeah goroutines is what i meant by better async. I've used the clojure async stuff a fair bit which was heavily inspired by goroutines and it is quite nice.
    - jpgvm 4y ago
      Goroutines are better than C# async/await but C# is still a better language than Go. When Java 19 lands you can have best of both worlds. Virtual Threads are equivalent to goroutines but you have access to better languages like Java, Kotlin and Clojure.
      - deleted 4y ago
        [deleted]
      - morelisp 4y ago
        I don't think virtual threads will be fully baked in time for production use at Java 19. IMO we'll be waiting at least one and probably two more releases. Valhalla has also produced an amount of language machinery that results in most of the same issues as Go. (E.g. "is this function receiving an interface or concrete value?" becomes "do I have a class, value class, or primitive class?") The performance ripples of requiring value objects to be immutable also remains to be seen.
        jpgvm 4y ago
        True. I intend to start using them the moment they land in preview but there is still some caveats (namely how they interact with synchronized). I think by Java 21 they will be rock solid though which isn't really that far away in Java timescales.
        kaba0 4y ago
        Aren’t they in preview in 19 already?
        jpgvm 4y ago
        Yes technically as they have been merged but 19 isn't out until September, you can download early-access builds today but we won't see a release build until the official release date.
        morelisp 4y ago
        Sure, but by Java 21 we'll have Go 1.21 with a couple release cycles to push generics into stdlib, and we're back to more or less useless debates about aesthetic preferences and tooling priorities again.
        kaba0 4y ago
        > The performance ripples of requiring value objects to be immutable also remains to be seen Immutability is trivial to optimize away.
  - deleted 4y ago
    [deleted]
- morelisp 4y ago
  Stock gRPC is not a great demonstration of Go’s possible performance. The code is neither clean nor fast nor idiomatic. I have no idea why it’s so messed up. (That said, C# and Java are no performance slouches and I expect they’d all be roughly comparable in the end if the Go code didn’t suck so much.)
  - jpgvm 4y ago
    C# and Java are almost always faster than Go. Go isn't fast, it's decent but nothing special for AOT native code. (atleast the standard gc compiler, llgo, gccgo etc could end up being a different story). It can show good overall performance in I/O bound workloads because of native M:N green threading though. I imagine even that is no longer a point in Go's favor when Java's Virtual Threads land and become widespread however. Go's only real interesting runtime feature was their emphasis on having a very low latency GC. This was somewhat special for a few years but between improvements made to .NET and Java's new GCs (Shanandoah and ZGC) that gap has been eliminated while these runtimes still provide better throughput on top of their now low latency. There really isn't a good performance or resource usage reason to pick Go over C#/Java anymore, all of its advantages have been eroded.
    - erik_seaberg 4y ago
      Go’s GC throughput isn’t great, but they’re pretty good at keeping values off the heap. Java’s GC is amazing, but we’ll have big working sets and boxing overhead until value types land.
      - kaba0 4y ago
        I would go as far to say that Go’s performance is good only because of value types. Their GC is known to slow down allocation when under big pressure.
        Groxx 4y ago
        I was poking into a 7-10 second test a couple years ago out of curiosity, and pulled a tracing profile. Garbage collection accounted for over 95% of the run-time. It was a perfect pathological case where it continually thrashed below/above a GC threshold, without hitting the point where it would make more room. Adding just a couple kilobytes of ballast[1] pushed it over the limit to where it reliably took about 200ms. (and then I rewrote the test to stop allocating so much junk) Go's GC is mostly pretty good in practice, but yeah. It's definitely not something you can rely on blindly. Also I wish they'd stop claiming that its pause times are tiny - the stop-the-world pauses are indeed consistently very short, but it hardly matters when it can pause goroutines for far, far longer[2]. And e.g. when you're allocating, your goroutine may be paused to "help" the GC, which can take a substantial amount of time (as happened in that^ test), which frequently leads to very large tail-latency. Most people don't care about stop-the-world times, they care about tail-latency, and Go is just leaning on people's misunderstanding that one is the cause of the other. It can be, but it's not the only source. [1]: https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i-learnt-to-stop-worrying-and-love-the-heap/ https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i... [2]: http://big-elephants.com/2018-09/unexpected-gc-pauses/ http://big-elephants.com/2018-09/unexpected-gc-pauses/ among other sources of individual goroutine pauses.
ainar-g 4y ago
I can get that Go's stdlib is smaller than Python's, but can you elaborate on why you feel that Go's syntax is hard to read compared to Java? Because both of them are very much C-like languages, syntax-wise.
- erik_seaberg 4y ago
  if err != nil is continuously painful. f(g(), h()) with error handling takes nine lines, maybe twelve? Everybody has to use Errorf() everywhere or nobody gets a stack trace. There are no stdlib filter/map/reduce yet, and generics are new enough that most people are still writing the same for-range loops over and over. Lambdas don’t capture loop variable values. x, y := f() sometimes assigns and sometimes shadows an outer scope. defer isn’t block scoped, you have to simulate the code to figure out which calls are stacked at this point. Hopefully they’re added deterministically, but you can keep deferring stuff in a loop if you want. (This is aside from the many ways Scala and Kotlin are far more readable than Java.)
  - johnisgood 4y ago
    I thought that "if err != nil" is much less common now because of the changes in error handling. I personally do like "if err != nil" better. I can easily ignore that when I want, and I can easily check if I am handling the error properly without any cognitive overhead.
    - erik_seaberg 4y ago
      Have a link? I don’t see any changes in https://tip.golang.org/doc/go1.19 https://tip.golang.org/doc/go1.19 that seem likely to help. How do you easily ignore the majority of the screen? Is there an editor plugin that just doesn’t display those ifs?
      - ainar-g 4y ago
        The fact that you think that error handling should be ignored is probably what prevents you from seeing the point of the Go error handling. The point is that one should never only consider the happy path. That one should actually think about how things can fail, what to do about those failures, and how to report those failures with enough context to figure something out on the outside if no appropriate handing is available in the code. Stack traces only give you line numbers. Properly used explicit error handling gives you more context in which a failure occurred. Here's one example that might make it clearer: https://commandcenter.blogspot.com/2017/12/error-handling-in-upspin.html https://commandcenter.blogspot.com/2017/12/error-handling-in....
siscia 4y ago
The appeal of go is that it is easy to learn, you can put any young person just out of college and have it produces a lot of line of code that resemble something working. The reality is that go is a very hard language to master and to avoid footgun. But it is an hard truth that few people are willing to accept.
- ainar-g 4y ago
  Can you provide examples of the things that are hard to master and the footguns?
  - siscia 4y ago
    Goroutine, pointers vs value, cancelling work in goroutines, avoid dead locks. What makes go powerful also make it weak. In general the complexity need to live somewhere and in go it can only be the code itself as the language is too simple.
    - ainar-g 4y ago
      The difference between pointers/references and values is there in most languages in the same ilk as Go, maybe with the exception of Java. (C# has structs, which are value types.) It's a concept pretty much any developer in that area must know. As for concurrency, that topic is hard in pretty much any mainstream language. Maybe with the exception of Rust, but Rust isn't exactly a langauge that is not “hard to master”, and even Rust doesn't protect you from all forms of concurrency issues. Merely most of them, heh.
  - BreakfastB0b 4y ago
    Concurrency is a major stumbling block https://eng.uber.com/data-race-patterns-in-go/ https://eng.uber.com/data-race-patterns-in-go/. Mutexs, conditional variable subtleties, wait groups, null pointer propagation, partial struct initialisations, channel lifetime coordination. tl;dr shared memory concurrency is hard. The introduction of generics should make it easier to wrap these lower level concurrency primitives into higher level safe constructs without needing code generation or runtime type casting via interface{}. Most devs also struggle to structure go programs in a way that makes them easily testable, but that’s true in a lot of languages.
jpgvm 4y ago
There is really no reason to go from Java to Go. Go may win out in the early days of a program for resource usage and perceived complexity but by the time your team has cooked up some frankenstien of an application framework and tried to standardize logging, metrics, etc you would have been better off in JVM land from the start. At least then you can pick battle-tested and supported frameworks. Python, Ruby, JS/TS -> Go is a weird one though. I can understand why when people make that transition they think Go is the best thing since sliced bread. It's by far one of the easiest languages to learn, it's miles faster than what they are coming from and the tooling is way less shit than those interpreted languages. However all of those languages represent a very very low bar. I think if the same people could be convinced to try Kotlin (or even modern Java) they would be a) surprised how easy it is these days and b) finally understand that it's ecosystem and tooling that really matters at the end of the day. Though I have to say Go existing is by and large a good thing even if I don't like it. It helps get people off things like Typescript which are absolute garbage-tier onto something half-reasonable. When they grow out of Go they generally end up somewhere better, just takes a few years.
- tragomaskhalos 4y ago
  One area where Go has quickly established a niche is in tooling, for example Terraform. Here the benefits of being able to run a single (non-containerised) binary vs having to fret about what version of Java your punters happen to have installed in compelling no?
  - jpgvm 4y ago
    Yeah that is fair. By and large such tools remain smaller codebases so it's flaws aren't as apparent either. My personal preference for such tools is Rust but it's admittedly a harder sell. Comment above is mostly addressing the server software use case with larger teams and 100KLOC+ (either one or many programs). I don't think anyone was using Java much in the CLI niche. It was dominated mostly by Python and Ruby (and Perl before that) before Go came along. I do think Go represents an improvement on that status quo.
    - 4y ago
johnisgood 4y ago
I am not sure what you are trying to say. That Go does not have a place because Python and Java exist? My personal experience: I cannot get anything related to cryptography done in Java, thanks to its standard library. I would choose Go over both Python and Java. The choice depends on a lot of things. Regardless, all I get from your message is that you mind the existence of Go, which I believe is silly.
- Thorentis 4y ago
  The solution to a good stdlib for eg crypto should not be a new language. This just complicates the landscape. C++ and Python have fantastic crypto libraries. Trying to get one included in Java would've been time better spent than coming up with an abomination of a new language. Go's stdlib has massive gaps in other areas (the fact you still have to write your own "contains" method for slices is a joke).
fulafel 4y ago
Lots of people dislike Java for reasons that don't apply to Go and Python.
konart 4y ago
>Java, Go's ... it's syntax is hard to read. Excuse me but Java? This is as subjective as it can be.
- qsort 4y ago
  Java's syntax is the most bog-standard Algol you can imagine. There's definitely some subjectivity to it, but how is Java hard to read?
  - konart 4y ago
    Everything is too long to read. This is mine personal problem. All java code be lie `public static void SomeReallyLongNameDescribingEverthing42 implements SomeOtherEvenLongerName` For me it's 10 times harder to follow than Go's `if err` blocks (which I actually do appreciate most of the time).
    - kaba0 4y ago
      That is not a good faith argument.. the only long thing in your example is a name you yourself created, absolutely nothing inherent in the language. But taking your argument in good faith, sure naming conventions are an important part of a language, but Java’s is not “obtusely long”, but “meaningful camel-case”.
      - konart 4y ago
        >meaningful camel-case CamelCase makes it even worse. Short CamelCase is quite okay, but the longer it gets, the harder it on my eyes. But even with short naming it still like 2-3 words just to name a function. wtf.
        kaba0 4y ago
        Is unreadable abbreviations better? Like, basically everything other than C has full words concatenated in various ways.
guggle 4y ago
Coming from Python in the field of web backends/webservices, I just find Java's ecosystem in general has too much ceremony. Go is fairly straight forward, to the point. I don't care too much for performance, but being lightweight on resources is a nice plus compared to Python (smaller VMs) and deployment is much easier. Yes, I do miss some language features (exceptions, classes...), but it's still very manageable. Of course Python has third party libraries for everything, but Go has all the basics for web services in the standard library. C++/Rust is out as I have no such performance requirement and GC is fine in my case. So that's it... Go fills a niche like a lot of other languages, so why not ?
jurschreuder 4y ago
I once made a video streaming platform in Python. It needed 2 big 10k euro servers to run. I then rewrote the backend in Go, which gave a 90% performance increase. It could now run all the streams on any normal pc.
- kaba0 4y ago
  Python is the slowest mainstream language by a factor of 10. You could have easily gotten that much increase by going to even JS. Go is not faster than other mainstream managed languages like C#, Java, JS .

MarkSweep 4y ago

Interesting to see LoongArch64 support pop up in more places.

kumarvvr 4y ago

Dotnet and C# are a killer combination and I frankly dont get why go has to be even considered. Go syntax is very cognitively demanding. Maybe I am getting old or have become used to C#, but between reading well formed go and C# code, C# always wins for me.

KronisLV 4y ago
You might as well say the same about Java (with select codebases), or even Python. Or, for the folks who have familiarity with different stacks, maybe something along the lines of Ruby, Node or whatever else they enjoy more. Admittedly, a lot of it comes down to personal preference and familiarity with different technologies. Though in regards to Go in particular, on a technical level: - it's simple to build self-contained executables, it's up there with the likes of FreePascal in this regard - it's also a relatively simple language that's easy to pick up and use, in contrast to how complex code can get with C# and Java - it also has fewer footguns than C or C++ without the complexity of Rust (which some might prefer), although it doesn't try to do as much - it has a decent community and lots of useful packages, even the included http libraries are nice to just get things done - it doesn't have a history of challenging versioning and platform support, when compared with .NET (Windows only support with IIS for legacy projects, anyone?) - the performance is generally good enough All of that combined means that Go is nice for writing both quick utilities, as well as smaller and larger services alike. Just look at Nomad, a container orchestration platform, the executables of which can be shipped as a single binary: https://www.nomadproject.io/downloads https://www.nomadproject.io/downloads Overall, it's pretty good for just getting things done in a reasonable amount of time and a limited amount of headaches. For example, Python might lead to code that is easier to write and read, but packaging can be a nightmare. Java might be better for select enterprise systems, but configuration is generally a bit of a mess there. .NET is a good alternative, but some folks also try to steer clear of Microsoft and tooling on *nix can be limited, much like it is for Java (your best bet would be to use JetBrains commercial products, since MonoDevelop isn't all that popular anymore, Visual Studio Code plugins wouldn't give you a "full IDE" experience and there is nothing quite like Eclipse or NetBeans for .NET). Further thoughts: the age of a language might also coincide with how loved or dreaded it is, since we simply don't see that many horrible enterprise monolith messes written in Go as of yet: https://earthly.dev/blog/brown-green-language/ https://earthly.dev/blog/brown-green-language/

nikivi 4y ago

Is it possible to install the beta with brew? I tried instructions on the site: $ go install golang.org/dl/go1.19beta1@latest $ go1.19beta1 download But I don't get where the new binary is placed. It's not in my PATH.

dmitshur 4y ago
The go1.19beta1 binary (which you would use to try Go 1.19 Beta 1) should be placed in the usual place where 'go install' places them. If you’re using Go’s defaults, it’s likely $HOME/go/bin, unless you’ve set either GOPATH or GOBIN env vars to point somewhere else.