22 ms·

The author lists multiple reasons for this, but for me the biggest one is the first one: Go is good for almost everything. I have extremely good productivity w

The author lists multiple reasons for this, but for me the biggest one is the first one: Go is good for almost everything. I have extremely good productivity when using Go. Once your project exceeds 100 lines it is usually even better than python. And yes, I am aware that Rustians did a survey where Rust was crowned as the most efficient language but in my reality (which may differ from yours) Go is simply the best tool for most tasks. Why is that? Well, for me there are 3 reasosns: 1. The language is extremely simple. If you know 20% of C you are already a Go expert. 2. The core libraries are extremly well thought. 3. Batteries are included. The toolchain and the core libraries alone can do 90% of what most people will ever need. When people argue about the validity of these claims, I simply point them to this talk https://go.dev/talks/2012/concurrency.slide#42 https://go.dev/talks/2012/concurrency.slide#42

kaba0 2y ago
How is it different than, say, java for this generalist purpose?
- colonelpopcorn 2y ago
  Just from an ergonomic standpoint it's a million times easier to deploy a go binary instead of a whole jvm and a jar file.
  - pjmlp 2y ago
    When it is a pure Go application, only as CLI or UNIX server.
- Dansvidania 2y ago
  java on its own is not a competitor to go, IMO, due to the batteries included "culture" in the go ecosystem. I would need to compare it with, for example, Java + Spring(Boot). I find Go to be simpler and more pleasant to use.
  - pjmlp 2y ago
    Where is the GUI battery in Go?
  - matwood 2y ago
    I agree with Go being simpler, but modern Java and Spring Boot is also fine. Backend programmers are spoiled with riches nowadays with all the completely workable options we have.
  - vips7L 2y ago
    Batteries included but there’s not even a Set[T] in the standard library..
- lantry 2y ago
  IME, there are two main differences between go and java: 1) go is more "batteries included". Modules, linting, testing, and much more are all part of the standard cli. Also, the go stdlib has a ton of stuff; in java, there is almost always a well-built third party library, but that requires you to find and learn more things instead of just reaching for stdlib every time. 2) golang is "newer" and "more refined". this is pretty subjective, but golang seems to have fewer features and the features are more well-planned. It's a more "compact" or "ergonomic" language. Whereas java has built up a lot of different features and not all of them are great. You can always ignore the java features you don't like ofc, but this is still a bit of cognitive overhead and increased learning time.
  - nerdponx 2y ago
    There are surprisingly few languages in this category, especially if you limit consideration to statically typed. Go, C#, Swift? Nim, Crystal? F#? Kotlin? Go is not my favorite language, but it really is exceptional in terms of its effective utilitarian design.
  - hughesjj 2y ago
    Eh, imo the go libraries still aren't up to par with out of the box java libraries. Like there's still no Set class, nor the equivalent of Map.keys. yeah they're easy to write but that's still not an included battery. Also, while the cli to add stuff is useful, there's still nothing to the level of maven or gradle for dependency management, and I usually find myself doing some fun stuff with `find -execdir` for module management. Different strokes for different folks though. Java (really, kotlin) still makes a ton of sense for backend to me given how the jvm is architecture independent and you don't have to make tradeoffs/switch to graal if it's a long lived service. Golang is nice, love it, but it's still got a bit to grow. I'm just happy they added modules and generics. I don't think it's a matter of being 'well thought out' as much as it's a simple language that cares a lot about simplicity and backwards compatibility and has iterated ever since. For my the killer app isn't go routines so much as you can produce a binary that's resilient even to shared/dynamically linked libraries in all platforms, which is awesome for portability independent of environment. No more gcc vs clang vs msvc headaches, no more incompatible shared libraries, no more wrong version of jvm or a bad python modules path etc. Oh, also java had like a 15 year headstart on golang, and it wasn't until java 8 that many of my biggest complaints were addressed. And yeah stuff like apache commons +log4j+mockito/junit are pretty much required dependencies, and maven/gradle aren't language native. The best STL is probably python imo but even that doesn't support a proper heap/priority queue inplementation. For data structures specifically I think java/kotlin has the best STL. All of this ignoring .NET or apple platforms.
- aaomidi 2y ago
  Dependencies in Java are a pain in the ass. Publishing libraries for your own consumption is even harder. Publishing libraries for world consumption means now you also need to be a PKI expert.
- conor- 2y ago
  As someone who isn't super proficient in Java I usually find Java daunting to get started with full of buckets of "meta" issues like in my other comment. What JVM do I use? Does it matter? Does it matter what version I install, what if I have to install/manage multiple versions? If I want to write a web service can I use vanilla Java stdlib or do I have to use Spring or some framework? If I use Spring, do I have to get into the weeds of dependency injection and other complexity to actually get my app off the ground? With Go, none of those questions exist. I install the latest Go, create a main.go file, I use net/http and I'm off to the races.
  - neonsunset 2y ago
    I think it's good that Go, among other well-made toolchains, brought attention to importance of good CLI UX. But it's not something that is unique to Go: dotnet new web dotnet run curl localhost:5050 also 'dotnet watch' for hot-reload.
  - pjmlp 2y ago
    Besides what neonsunset points out for .NET world, where alongside C#, we get the pleasure to enjoy F#, VB and C++/CLI, it is relatively easy for Java. When one doesn't know, just like with Go, one picks up the reference implementation => OpenJDK. For basic stuff, the standard library also has you covered in the jdk.httpserver module. By the way, where is the Swing equivalent on Go's standard library?
  - simon_void 2y ago
    > What JVM do I use? latest LTS (longterm-support) version, so currently 21, next 25 (late 2025). > Does it matter? new is always better > what if I have to install/manage multiple versions? https://sdkman.io/ https://sdkman.io/ > If I want to write a web service can I use vanilla Java stdlib or do I have to use Spring or some framework? Spring > If I use Spring, do I have to get into the weeds of dependency injection yes, but it's not hard (or I've done it long enough) > other complexity that might just be inherent complexity when have to deal with a webservice. personally I dislike have to configure security So basically go to Spring Initializr (https://start.spring.io/ https://start.spring.io/) pick the latest LTS Java&Maven (or Kotlin&Gradle-Kotlin) and You're off to the races.
cube2222 2y ago
Yeah, this. It's just good enough for 95% of use-cases, while being very productive. Personally, one of the biggest selling points for me is that imo modelling concurrency and asynchronicity via fibers (goroutines), rather than async/await, is just a ton easier and faster to work with. Again, there are use-cases for the alternative (mainly performance, or if you like to express everything in your type-system) but it's just great for 95% of use-cases.
- sanderjd 2y ago
  I always find it odd when people refer to it as being "very productive". I find all the boilerplate very un-productive to work with. Every time I pick go back up I'm shocked how many manual loops and conditionals I have to write.
conor- 2y ago
Go is the only language I've ever felt highly productive working in. Oftentimes in other stacks I find myself in analysis paralysis on meta things that don't matter: - what design patterns/language features make sense to use - what is the best lib to accomplish X - how do you keep things up to date With Go, the language is so simple that it's pretty difficult to over engineer or write terse code. Everything you need is in stdlib. The tooling makes dependency management and upgrades trivial because of strong backwards compatibility.
- justinsaccount 2y ago
  Yep.. say you wanted to make a simple http service that needs to * request a json.gz file from another HTTP service * decompress it * deserialize the json, transform it a bit That's net/http (and maybe crypto/tls), compress/gzip, encoding/json. I need to make zero decisions to get the thing off the ground. Are they the best libraries in the world for those things? no.. but will they work just fine for almost every use case.
  - chubot 2y ago
    Sounds like curl ... | jq ... to me! Not saying you shouldn't use Go for that problem, in a particular context, but it does drive home how much of programming is glue ... there is combinatorial amounts of glue, which is why JSON, HTTP, compression, etc. end up being part of so many problems
    - dartos 2y ago
      There’s a big difference between building something on curl and jq and building something using a language’s standard library. Everything is just bits at the end of the day. Just about anything can do anything.
- mapcars 2y ago
  I do programming interviews and I found candidates struggling a lot in doing http request and parsing response json in Go while in Python its a breeze, what makes it particularly hard, is it lack of generics or dict data type?
jayd16 2y ago
I'm asking this earnestly but is Go suitable for native GUI apps (not web)? 3D graphics/Games? Audio processing?
- nasretdinov 2y ago
  For games potentially Ebiten, I believe it has some audio processing support too.
  - runeblaze 2y ago
    Probably not Ebiten for 3d games. To be fair at this point when you are doing somewhat specialist things Go starts to lose its edge. I remember trying to replicate some Numpy code in Go and that was a pain. However that's just because Python is too good at scientific things.
- xyproto 2y ago
  Yes, because one can either turn off the GC, allocate memory up front (arena style), or call C or Assembly from Go. The performance is likely to be good enough with GC turned on, though, because it is unusually fast.
  - jayd16 2y ago
    Turning off the GC isn't the blocker. Plenty of GC languages manage. I'm more interested in how Go handles graphics APIs and binding a render thread or working with GUI threads considering how goroutines are done. Does one need to write non-idiomatic go, avoiding goroutines or is there some trick? For example, GTK isn't thread safe so you can't just use that library without considering that.
    - mjevans 2y ago
      Offhand, I think the general pattern is to bind related external libraries (E.G. a gui stack) into one agent thread and use channels to send it messages.
    - 2y ago
api 2y ago
Go has very little story when it comes to desktop or mobile GUI apps, which is too bad because it would be a very productive language for that kind of thing.
- anta40 2y ago
  This makes me wonder: why there's less effort on mobile side? For web, well there are plenty of stuffs. Perhaps Go devs are not interested in native solution (like Kotlin/Swift etc) and prefer web stack (JS, React etc)?
actionfromafar 2y ago
My personal Python threshold is 10k lines. After that I tend to loose track of what I am doing and I start to miss static typing and nowadays, an IDE to navigate it. Maybe future Python IDEs can AI scan the codebase and compensate.
- JodieBenitez 2y ago
  Wait... in what year was this comment written ? ;) There's type hinting and IDEs do navigate it.
  - The_Colonel 2y ago
    optional hints Both make them much less useful than in a typical statically typed language. Besides that, the tooling sucked hard not too long ago.
- sanderjd 2y ago
  Type annotations plus modern IDEs have (in my experience) made this mostly a non-issue. It does require a bit more setup to get passable static analysis set up, which comes "for free" in languages with good compilers (like go!), but it's at least possible now to get to a (IMO) good point. (FWIW, I moved away from python and ruby over a decade ago because of exactly this frustration, but I'm finding modern python to be pretty pleasant.)
danpalmer 2y ago
> When people argue about the validity of these claims, I simply point them to this talk https://go.dev/talks/2012/concurrency.slide#42 https://go.dev/talks/2012/concurrency.slide#42 There's nothing impressive in these slides. This may have been pretty good in 2012, but this code looks very much like the equivalent Swift or Rust.
- sapiogram 2y ago
  It's better in Swift or Rust. Go channels are the worst thing about the language, even trivial use cases are difficult to get right.
eweise 2y ago
Personally I don't find it great for prototyping. There's just too much boilerplate, which is why I use other languages for fun/personal projects.
- pants2 2y ago
  Is there much boilerplate aside from err checks and JSON tags? Even then, your IDE / copilot should automatically insert those along with imports and package names.
  - lifthrasiir 2y ago
    The requirement to define at least one function by itself is a boilerplate. Also IDE doesn't fully solve the inability to compile and run a partially written program (in fact, Go compiler is even more pedantic than rustc in some aspect), which happens a lot when working with dynamically typed languages and their strongest use cases.
  - eweise 2y ago
    Err checks are a big one. I don't want to worry about error handling when prototyping. There are little things like having to prefix methods with the struct name and type, and bigger things like no default arguments and by name parameters, which makes setting up test fixtures cumbersome. Also, functions don't compose well because there can be more than one return value, so you end up just writing more intermediate values.
- sanderjd 2y ago
  Absolutely, it's my least favorite prototyping environment. It forces me to think about a bunch of stuff I don't want to think about up front.
drdaeman 2y ago
I can totally agree that Go is good enough for most projects, to the extent it's a go-to choice for many. However, it's not always the best tool - frequently it wins just because it allows to prototype quicker. YMMV, but for me, it's not a love relationship, it's a love-hate relationship. > The language is extremely simple. Simplicity is a double-edged sword. It didn't even have basic generics for a long while, and it's painful to remember how bad it was without them. Still doesn't have a lot of stuff anyone would expect from a modern language. > If you know 20% of C you are already a Go expert. Strong disagree. Knowing $language means knowing the patterns and caveats and (sorry for a cliche term, I'm not fond of it, but I don't have a better term so I hope you get the meaning) "best practices". Those are drastically different between C and Go. Especially when it comes to concurrency and parallelism. > The toolchain and the core libraries alone can do 90% of what most people will ever need. This is provably false. Virtually every serious project out there pulls a ton of dependencies, like database drivers, configuration toolkits, tracing and logging libraries and so on. Heck, I think a lot of shops have project templates for this reason - to standardize on the layout and pull the company-preferred set of libraries for common stuff. Core libraries are slowly getting there but so far they don't have very basic stuff like MapSet[T] or JSON codecs for nullable types like sql.NullString, so you gotta pull third-party stuff.
- AnimalMuppet 2y ago
  "Good enough" plus "I already know it" almost always beats the perfect tool that I don't already know.
  - sanderjd 2y ago
    There is obviously truth in this, but I think it is more often the case than many people think it is that it is more efficient to learn the better tool "good enough" than to use the worse "I already know it" tool. For instance, I've seen lots of people not want to learn sql and instead write complicated imperative implementations of relational primitives in the "I already know it" programming languages that are clearly "good enough" (because they are turing complete after all). But sql is usually a much better way to do this, and isn't hard to learn "good enough" to do most things.
ternaryoperator 2y ago
Agreed on all points except #3 re the core libraries. Coming from the Java ecosystem, it was a bit of a shock to see how small the standard libraries are. For example, the minuscule collections library, among others.
Yoric 2y ago
> The author lists multiple reasons for this, but for me the biggest one is the first one: Go is good for almost everything. I'd nuance that claim. I haven't found Go to be _particularly good_ at any specific task I've undertaken, but Go was _good enough_ for many of these tasks. Which makes Go a reasonable general programming language.
- sanderjd 2y ago
  This is true, but there are a number of _good enough_ languages, and personally I don't think go is top-tier at this use case of being the go-to swiss army knife. I do think it is top-tier at being a good choice for tools in its niche. But not as "default language I reach for when I don't want to waste time thinking about it".
  - Yoric 2y ago
    Agreed. For my personal sensibilities, Python or TypeScript are better default languages. Of course, I'm a bit obsessive about quality/safety, so I'm probably going to use Rust for most tasks :)
lenkite 2y ago
Go is not good for data science and ML. It doesn't even have a proper, maintained dataframe library for data-science. R and Python beat it hands on. Rust also beats it now thanks to polars. And mobile ? gomobile is not maintained. Fyne is amateur level on mobile. AFAIK Go has no maintained 3d game engines. Go has its well-established niche for middle-ware services and CLI tools. And that's about it. If your domain is outside this, its best to choose another language.
- merlindru 2y ago
  Also anything that requires interop/FFI, syscalls, and lower level stuff. It's extremely hard to record your screen on Go, for example. On Rust this is much more doable and there even are crates for it It's not impossible with Go, though. There's an amazing windows impl here: https://github.com/kirides/go-d3d https://github.com/kirides/go-d3d ...but if you look at the code, it's clear that you have to work against the language in some capacity
- Lyngbakr 2y ago
  Is the reason for the absence of a well-maintained dataframe library lack of demand? It looks like Gota and Dataframe-go are abandoned, while Gonum isn't particularly active. Did these wither on the vine because no one used them?
  - deleted 2y ago
    [deleted]
  - aragilar 2y ago
    It's likely because it's a pain to call Fortran or C (I'd be suspicious of anyone trying to reimplement openblas in go).
    - Something1234 2y ago
      Why would you be suspicious?
createaccount99 2y ago
Builtins well thought out? Have you seen the bignumber api?
sanderjd 2y ago
It has not been my experience that Go is good for almost everything. On the contrary, it seems good at a couple very specific (though very common) niches: network services and cli utilities. But for most of what I do right now - data heavy work - it has not turned out to be very good (IMO). It really is just not better in any way to have to constantly write manual loops to do anything.
- lnenad 2y ago
  I agree with this, there is a reason Python is the king of data.
  - sanderjd 2y ago
    Yeah, but Go is also worse (in my experience) than most, if not all, of the other general-purpose languages I've used, for this niche. For instance, Rust is actually pretty great in this space, despite being very ... not-python, and Java also has decent libraries. Then C++ (and Fortran!) are good for a very different reason than python, "on the metal" performance, which Go also isn't a great fit for.
- ratorx 2y ago
  I think Go is pretty OK as a language for building data pipelines (I’m assuming you meant statistical ones, but the same argument applies to more data transform-y ones). What it is not good for is doing exploratory analysis (which is where Python shines). Manual loops are pretty annoying when the focus is on figuring out which loops to write (exploratory phase). However, they are pretty nice once you’ve figured it out and need write a durable bit of code where your prioritise readability over conciseness (productionisation). Going from Python to <any language> between the exploratory phase and the productionised pipeline is going to be a pain, I don’t think Go is particularly worse than others. At that point it’s all about the classic software tradeoffs (performance vs velocity vs maintainability) and I didn’t think Go is a good choice in many situations.
  - sanderjd 2y ago
    Well I totally disagree that writing manual loops is ever "pretty nice", but I agree that it's not as big an issue in final-version code as it is in exploration. And I'm also in strong agreement that making any language transition between exploration and implementation is problematic. I do think go is worse than most, because I just think it has a mostly cultural allergy to manipulating collections of data as collections rather than element-by-element, but I agree that this is mostly lost in the noise of doing any re-write into a new language. But this is why Python is best in this space. It simply has the best promotion path from experimentation to production. It is better than other "real" languages like go, because it thrives in the exploratory phase, and it is better than purpose-specific languages, like R, because it is also a great general-purpose language. The other contender I see is Julia, which comes more from the experimentation-focused side, while trying to become a good general purpose language, but unfortunately I think it still needs to mature a lot on that side, and it's not clear that it has the community to push it far enough fast enough in that direction (IMO). Even very performance-critical use cases work with python, because the iteration process can follow experimentation -> productionization -> performance analysis -> fixing low-hanging bottlenecks by offloading to existing native extensions -> writing custom native extensions for the real bottlenecks.
mjw_byrne 2y ago
4. Stability and backwards-compatibility. I have never seen a Go version upgrade break anything. Meanwhile I have colleagues who do a thousand-yard-stare if you so much as mention upgrading the version of Python we're using.
- sanderjd 2y ago
  Python upgrades are fine, actually. The python library ecosystem is a bit of a mess in general, which does affect this, but the tools have actually improved to make this more manageable lately.
riku_iki 2y ago
> Go is good for almost everything. Java is good in more areas than go
noisy_boy 2y ago
> Once your project exceeds 100 lines 100 lines in which language? 100 lines in Go will probably have 50 lines of if err != nil :P

kaba0 2y ago

How is it different than, say, java for this generalist purpose?

colonelpopcorn 2y ago
Just from an ergonomic standpoint it's a million times easier to deploy a go binary instead of a whole jvm and a jar file.
- pjmlp 2y ago
  When it is a pure Go application, only as CLI or UNIX server.
Dansvidania 2y ago
java on its own is not a competitor to go, IMO, due to the batteries included "culture" in the go ecosystem. I would need to compare it with, for example, Java + Spring(Boot). I find Go to be simpler and more pleasant to use.
- pjmlp 2y ago
  Where is the GUI battery in Go?
- matwood 2y ago
  I agree with Go being simpler, but modern Java and Spring Boot is also fine. Backend programmers are spoiled with riches nowadays with all the completely workable options we have.
- vips7L 2y ago
  Batteries included but there’s not even a Set[T] in the standard library..
lantry 2y ago
IME, there are two main differences between go and java: 1) go is more "batteries included". Modules, linting, testing, and much more are all part of the standard cli. Also, the go stdlib has a ton of stuff; in java, there is almost always a well-built third party library, but that requires you to find and learn more things instead of just reaching for stdlib every time. 2) golang is "newer" and "more refined". this is pretty subjective, but golang seems to have fewer features and the features are more well-planned. It's a more "compact" or "ergonomic" language. Whereas java has built up a lot of different features and not all of them are great. You can always ignore the java features you don't like ofc, but this is still a bit of cognitive overhead and increased learning time.
- nerdponx 2y ago
  There are surprisingly few languages in this category, especially if you limit consideration to statically typed. Go, C#, Swift? Nim, Crystal? F#? Kotlin? Go is not my favorite language, but it really is exceptional in terms of its effective utilitarian design.
- hughesjj 2y ago
  Eh, imo the go libraries still aren't up to par with out of the box java libraries. Like there's still no Set class, nor the equivalent of Map.keys. yeah they're easy to write but that's still not an included battery. Also, while the cli to add stuff is useful, there's still nothing to the level of maven or gradle for dependency management, and I usually find myself doing some fun stuff with `find -execdir` for module management. Different strokes for different folks though. Java (really, kotlin) still makes a ton of sense for backend to me given how the jvm is architecture independent and you don't have to make tradeoffs/switch to graal if it's a long lived service. Golang is nice, love it, but it's still got a bit to grow. I'm just happy they added modules and generics. I don't think it's a matter of being 'well thought out' as much as it's a simple language that cares a lot about simplicity and backwards compatibility and has iterated ever since. For my the killer app isn't go routines so much as you can produce a binary that's resilient even to shared/dynamically linked libraries in all platforms, which is awesome for portability independent of environment. No more gcc vs clang vs msvc headaches, no more incompatible shared libraries, no more wrong version of jvm or a bad python modules path etc. Oh, also java had like a 15 year headstart on golang, and it wasn't until java 8 that many of my biggest complaints were addressed. And yeah stuff like apache commons +log4j+mockito/junit are pretty much required dependencies, and maven/gradle aren't language native. The best STL is probably python imo but even that doesn't support a proper heap/priority queue inplementation. For data structures specifically I think java/kotlin has the best STL. All of this ignoring .NET or apple platforms.
aaomidi 2y ago
Dependencies in Java are a pain in the ass. Publishing libraries for your own consumption is even harder. Publishing libraries for world consumption means now you also need to be a PKI expert.
conor- 2y ago
As someone who isn't super proficient in Java I usually find Java daunting to get started with full of buckets of "meta" issues like in my other comment. What JVM do I use? Does it matter? Does it matter what version I install, what if I have to install/manage multiple versions? If I want to write a web service can I use vanilla Java stdlib or do I have to use Spring or some framework? If I use Spring, do I have to get into the weeds of dependency injection and other complexity to actually get my app off the ground? With Go, none of those questions exist. I install the latest Go, create a main.go file, I use net/http and I'm off to the races.
- neonsunset 2y ago
  I think it's good that Go, among other well-made toolchains, brought attention to importance of good CLI UX. But it's not something that is unique to Go: dotnet new web dotnet run curl localhost:5050 also 'dotnet watch' for hot-reload.
- pjmlp 2y ago
  Besides what neonsunset points out for .NET world, where alongside C#, we get the pleasure to enjoy F#, VB and C++/CLI, it is relatively easy for Java. When one doesn't know, just like with Go, one picks up the reference implementation => OpenJDK. For basic stuff, the standard library also has you covered in the jdk.httpserver module. By the way, where is the Swing equivalent on Go's standard library?
- simon_void 2y ago
  > What JVM do I use? latest LTS (longterm-support) version, so currently 21, next 25 (late 2025). > Does it matter? new is always better > what if I have to install/manage multiple versions? https://sdkman.io/ https://sdkman.io/ > If I want to write a web service can I use vanilla Java stdlib or do I have to use Spring or some framework? Spring > If I use Spring, do I have to get into the weeds of dependency injection yes, but it's not hard (or I've done it long enough) > other complexity that might just be inherent complexity when have to deal with a webservice. personally I dislike have to configure security So basically go to Spring Initializr (https://start.spring.io/ https://start.spring.io/) pick the latest LTS Java&Maven (or Kotlin&Gradle-Kotlin) and You're off to the races.

cube2222 2y ago

Yeah, this. It's just good enough for 95% of use-cases, while being very productive. Personally, one of the biggest selling points for me is that imo modelling concurrency and asynchronicity via fibers (goroutines), rather than async/await, is just a ton easier and faster to work with. Again, there are use-cases for the alternative (mainly performance, or if you like to express everything in your type-system) but it's just great for 95% of use-cases.

sanderjd 2y ago
I always find it odd when people refer to it as being "very productive". I find all the boilerplate very un-productive to work with. Every time I pick go back up I'm shocked how many manual loops and conditionals I have to write.

conor- 2y ago

Go is the only language I've ever felt highly productive working in. Oftentimes in other stacks I find myself in analysis paralysis on meta things that don't matter: - what design patterns/language features make sense to use - what is the best lib to accomplish X - how do you keep things up to date With Go, the language is so simple that it's pretty difficult to over engineer or write terse code. Everything you need is in stdlib. The tooling makes dependency management and upgrades trivial because of strong backwards compatibility.

justinsaccount 2y ago
Yep.. say you wanted to make a simple http service that needs to * request a json.gz file from another HTTP service * decompress it * deserialize the json, transform it a bit That's net/http (and maybe crypto/tls), compress/gzip, encoding/json. I need to make zero decisions to get the thing off the ground. Are they the best libraries in the world for those things? no.. but will they work just fine for almost every use case.
- chubot 2y ago
  Sounds like curl ... | jq ... to me! Not saying you shouldn't use Go for that problem, in a particular context, but it does drive home how much of programming is glue ... there is combinatorial amounts of glue, which is why JSON, HTTP, compression, etc. end up being part of so many problems
  - dartos 2y ago
    There’s a big difference between building something on curl and jq and building something using a language’s standard library. Everything is just bits at the end of the day. Just about anything can do anything.
mapcars 2y ago
I do programming interviews and I found candidates struggling a lot in doing http request and parsing response json in Go while in Python its a breeze, what makes it particularly hard, is it lack of generics or dict data type?

jayd16 2y ago

I'm asking this earnestly but is Go suitable for native GUI apps (not web)? 3D graphics/Games? Audio processing?

nasretdinov 2y ago
For games potentially Ebiten, I believe it has some audio processing support too.
- runeblaze 2y ago
  Probably not Ebiten for 3d games. To be fair at this point when you are doing somewhat specialist things Go starts to lose its edge. I remember trying to replicate some Numpy code in Go and that was a pain. However that's just because Python is too good at scientific things.
xyproto 2y ago
Yes, because one can either turn off the GC, allocate memory up front (arena style), or call C or Assembly from Go. The performance is likely to be good enough with GC turned on, though, because it is unusually fast.
- jayd16 2y ago
  Turning off the GC isn't the blocker. Plenty of GC languages manage. I'm more interested in how Go handles graphics APIs and binding a render thread or working with GUI threads considering how goroutines are done. Does one need to write non-idiomatic go, avoiding goroutines or is there some trick? For example, GTK isn't thread safe so you can't just use that library without considering that.
  - mjevans 2y ago
    Offhand, I think the general pattern is to bind related external libraries (E.G. a gui stack) into one agent thread and use channels to send it messages.
  - 2y ago

api 2y ago

Go has very little story when it comes to desktop or mobile GUI apps, which is too bad because it would be a very productive language for that kind of thing.

anta40 2y ago
This makes me wonder: why there's less effort on mobile side? For web, well there are plenty of stuffs. Perhaps Go devs are not interested in native solution (like Kotlin/Swift etc) and prefer web stack (JS, React etc)?

actionfromafar 2y ago

My personal Python threshold is 10k lines. After that I tend to loose track of what I am doing and I start to miss static typing and nowadays, an IDE to navigate it. Maybe future Python IDEs can AI scan the codebase and compensate.

JodieBenitez 2y ago
Wait... in what year was this comment written ? ;) There's type hinting and IDEs do navigate it.
- The_Colonel 2y ago
  optional hints Both make them much less useful than in a typical statically typed language. Besides that, the tooling sucked hard not too long ago.
sanderjd 2y ago
Type annotations plus modern IDEs have (in my experience) made this mostly a non-issue. It does require a bit more setup to get passable static analysis set up, which comes "for free" in languages with good compilers (like go!), but it's at least possible now to get to a (IMO) good point. (FWIW, I moved away from python and ruby over a decade ago because of exactly this frustration, but I'm finding modern python to be pretty pleasant.)

danpalmer 2y ago

> When people argue about the validity of these claims, I simply point them to this talk https://go.dev/talks/2012/concurrency.slide#42 https://go.dev/talks/2012/concurrency.slide#42 There's nothing impressive in these slides. This may have been pretty good in 2012, but this code looks very much like the equivalent Swift or Rust.

sapiogram 2y ago
It's better in Swift or Rust. Go channels are the worst thing about the language, even trivial use cases are difficult to get right.

eweise 2y ago

Personally I don't find it great for prototyping. There's just too much boilerplate, which is why I use other languages for fun/personal projects.

pants2 2y ago
Is there much boilerplate aside from err checks and JSON tags? Even then, your IDE / copilot should automatically insert those along with imports and package names.
- lifthrasiir 2y ago
  The requirement to define at least one function by itself is a boilerplate. Also IDE doesn't fully solve the inability to compile and run a partially written program (in fact, Go compiler is even more pedantic than rustc in some aspect), which happens a lot when working with dynamically typed languages and their strongest use cases.
- eweise 2y ago
  Err checks are a big one. I don't want to worry about error handling when prototyping. There are little things like having to prefix methods with the struct name and type, and bigger things like no default arguments and by name parameters, which makes setting up test fixtures cumbersome. Also, functions don't compose well because there can be more than one return value, so you end up just writing more intermediate values.
sanderjd 2y ago
Absolutely, it's my least favorite prototyping environment. It forces me to think about a bunch of stuff I don't want to think about up front.

drdaeman 2y ago

I can totally agree that Go is good enough for most projects, to the extent it's a go-to choice for many. However, it's not always the best tool - frequently it wins just because it allows to prototype quicker. YMMV, but for me, it's not a love relationship, it's a love-hate relationship. > The language is extremely simple. Simplicity is a double-edged sword. It didn't even have basic generics for a long while, and it's painful to remember how bad it was without them. Still doesn't have a lot of stuff anyone would expect from a modern language. > If you know 20% of C you are already a Go expert. Strong disagree. Knowing $language means knowing the patterns and caveats and (sorry for a cliche term, I'm not fond of it, but I don't have a better term so I hope you get the meaning) "best practices". Those are drastically different between C and Go. Especially when it comes to concurrency and parallelism. > The toolchain and the core libraries alone can do 90% of what most people will ever need. This is provably false. Virtually every serious project out there pulls a ton of dependencies, like database drivers, configuration toolkits, tracing and logging libraries and so on. Heck, I think a lot of shops have project templates for this reason - to standardize on the layout and pull the company-preferred set of libraries for common stuff. Core libraries are slowly getting there but so far they don't have very basic stuff like MapSet[T] or JSON codecs for nullable types like sql.NullString, so you gotta pull third-party stuff.

AnimalMuppet 2y ago
"Good enough" plus "I already know it" almost always beats the perfect tool that I don't already know.
- sanderjd 2y ago
  There is obviously truth in this, but I think it is more often the case than many people think it is that it is more efficient to learn the better tool "good enough" than to use the worse "I already know it" tool. For instance, I've seen lots of people not want to learn sql and instead write complicated imperative implementations of relational primitives in the "I already know it" programming languages that are clearly "good enough" (because they are turing complete after all). But sql is usually a much better way to do this, and isn't hard to learn "good enough" to do most things.

ternaryoperator 2y ago

Agreed on all points except #3 re the core libraries. Coming from the Java ecosystem, it was a bit of a shock to see how small the standard libraries are. For example, the minuscule collections library, among others.

Yoric 2y ago

> The author lists multiple reasons for this, but for me the biggest one is the first one: Go is good for almost everything. I'd nuance that claim. I haven't found Go to be _particularly good_ at any specific task I've undertaken, but Go was _good enough_ for many of these tasks. Which makes Go a reasonable general programming language.

sanderjd 2y ago
This is true, but there are a number of _good enough_ languages, and personally I don't think go is top-tier at this use case of being the go-to swiss army knife. I do think it is top-tier at being a good choice for tools in its niche. But not as "default language I reach for when I don't want to waste time thinking about it".
- Yoric 2y ago
  Agreed. For my personal sensibilities, Python or TypeScript are better default languages. Of course, I'm a bit obsessive about quality/safety, so I'm probably going to use Rust for most tasks :)

lenkite 2y ago

Go is not good for data science and ML. It doesn't even have a proper, maintained dataframe library for data-science. R and Python beat it hands on. Rust also beats it now thanks to polars. And mobile ? gomobile is not maintained. Fyne is amateur level on mobile. AFAIK Go has no maintained 3d game engines. Go has its well-established niche for middle-ware services and CLI tools. And that's about it. If your domain is outside this, its best to choose another language.

merlindru 2y ago
Also anything that requires interop/FFI, syscalls, and lower level stuff. It's extremely hard to record your screen on Go, for example. On Rust this is much more doable and there even are crates for it It's not impossible with Go, though. There's an amazing windows impl here: https://github.com/kirides/go-d3d https://github.com/kirides/go-d3d ...but if you look at the code, it's clear that you have to work against the language in some capacity
Lyngbakr 2y ago
Is the reason for the absence of a well-maintained dataframe library lack of demand? It looks like Gota and Dataframe-go are abandoned, while Gonum isn't particularly active. Did these wither on the vine because no one used them?
- deleted 2y ago
  [deleted]
- aragilar 2y ago
  It's likely because it's a pain to call Fortran or C (I'd be suspicious of anyone trying to reimplement openblas in go).
  - Something1234 2y ago
    Why would you be suspicious?

createaccount99 2y ago

Builtins well thought out? Have you seen the bignumber api?

sanderjd 2y ago

It has not been my experience that Go is good for almost everything. On the contrary, it seems good at a couple very specific (though very common) niches: network services and cli utilities. But for most of what I do right now - data heavy work - it has not turned out to be very good (IMO). It really is just not better in any way to have to constantly write manual loops to do anything.

lnenad 2y ago
I agree with this, there is a reason Python is the king of data.
- sanderjd 2y ago
  Yeah, but Go is also worse (in my experience) than most, if not all, of the other general-purpose languages I've used, for this niche. For instance, Rust is actually pretty great in this space, despite being very ... not-python, and Java also has decent libraries. Then C++ (and Fortran!) are good for a very different reason than python, "on the metal" performance, which Go also isn't a great fit for.
ratorx 2y ago
I think Go is pretty OK as a language for building data pipelines (I’m assuming you meant statistical ones, but the same argument applies to more data transform-y ones). What it is not good for is doing exploratory analysis (which is where Python shines). Manual loops are pretty annoying when the focus is on figuring out which loops to write (exploratory phase). However, they are pretty nice once you’ve figured it out and need write a durable bit of code where your prioritise readability over conciseness (productionisation). Going from Python to <any language> between the exploratory phase and the productionised pipeline is going to be a pain, I don’t think Go is particularly worse than others. At that point it’s all about the classic software tradeoffs (performance vs velocity vs maintainability) and I didn’t think Go is a good choice in many situations.
- sanderjd 2y ago
  Well I totally disagree that writing manual loops is ever "pretty nice", but I agree that it's not as big an issue in final-version code as it is in exploration. And I'm also in strong agreement that making any language transition between exploration and implementation is problematic. I do think go is worse than most, because I just think it has a mostly cultural allergy to manipulating collections of data as collections rather than element-by-element, but I agree that this is mostly lost in the noise of doing any re-write into a new language. But this is why Python is best in this space. It simply has the best promotion path from experimentation to production. It is better than other "real" languages like go, because it thrives in the exploratory phase, and it is better than purpose-specific languages, like R, because it is also a great general-purpose language. The other contender I see is Julia, which comes more from the experimentation-focused side, while trying to become a good general purpose language, but unfortunately I think it still needs to mature a lot on that side, and it's not clear that it has the community to push it far enough fast enough in that direction (IMO). Even very performance-critical use cases work with python, because the iteration process can follow experimentation -> productionization -> performance analysis -> fixing low-hanging bottlenecks by offloading to existing native extensions -> writing custom native extensions for the real bottlenecks.

mjw_byrne 2y ago

4. Stability and backwards-compatibility. I have never seen a Go version upgrade break anything. Meanwhile I have colleagues who do a thousand-yard-stare if you so much as mention upgrading the version of Python we're using.

sanderjd 2y ago
Python upgrades are fine, actually. The python library ecosystem is a bit of a mess in general, which does affect this, but the tools have actually improved to make this more manageable lately.

riku_iki 2y ago

> Go is good for almost everything. Java is good in more areas than go

noisy_boy 2y ago

> Once your project exceeds 100 lines 100 lines in which language? 100 lines in Go will probably have 50 lines of if err != nil :P