6 ms·

The problem with Go is that it offers nothing substantial above the existing ecosystems. .NET and Java, both garbage collected, are just as fast or faster with

The problem with Go is that it offers nothing substantial above the existing ecosystems. .NET and Java, both garbage collected, are just as fast or faster with a much larger ecosystem. The only real differences are mild (composition vs inheritance, simpler multithreading, better TDD support, etc). Rust owns the low level space for modern composition based development and manual memory management. C/C++ exists as well. Typescript and Python completely dominate the dynamic space. So... why does Go exist?

mfcl 4y ago
Are you asking why alternatives exist in this world?
rs_rs_rs_rs_rs 4y ago
Go is a great language to replace sysadmin scripts written in python or shellscript. I used to imediately jump to python when a shell script would get a little complicated, now I always pick Go.
- pjmlp 4y ago
  Why should I make myself suffer with a less expressive language than Python?
  - deltasevennine 4y ago
    Suffering is a function of familiarity with the language and the intelligence of the user. Go is good enough such that if you had familiarity with both python and go, usage of either is justifiable in terms of expressiveness and ease of use. Your lack of knowledge about this fact, however, is a symptom of intelligence.
- hitpointdrew 4y ago
  I would hard disagree with this. When bash won't cut it Python is the goto. 1. Python is installed by default of pretty much every linux out distro out there. 2. Go is a bit overkill for something that realistically doesn't need any of the speed/performance benefits you would get in Go 3. No need to compile Python 4. Go is way less readable than Python IMO Go and Rust are fine languages for a lot of things, but sysadmin scripts is not a good use case for either of them.
  - morelisp 4y ago
    > 1. Python is installed by default of pretty much every linux out distro out there. If you can install a Python script you can install a binary, and you won't have missing modules or version compatibility issues. > 3. No need to compile Python Anything on a server better be coming out of your orchestration tools anyway...
  - matwood 4y ago
    > Python is installed by default of pretty much every linux out distro out there. Which Python? Do I need to install pyenv or venv? What about deps? Python is an absolutely disaster every time I try to use it. Golang easily cross compiles (fast enough it doesn't seem like a compilation is happening) to various platforms, I drop the executable there, and it runs.
  - kcartlidge 4y ago
    You're right with half of these, though 4 is as you say purely opinion and 2 depends on the circumstance. It is worth noting however that with `go run main.go` (or similar) you can execute Go without needing to build a binary first so it can behave exactly like a scripting language. And Go builds virtually instantly, meaning for any non-trivial script (and if you prefer Go of course) it's a virtual certainty that given the negligible build time and far better performance a Go 'script' done this way will massively out-perform a Python script. In other words if you don't accept 4 (and I like Python so not a dig) and you have a need for 2 then 3 can become irrelevant and Go is a good choice.
    - tracker1 4y ago
      just realized you can use shebang with a go file... sweet.
    - hitpointdrew 4y ago
      > 4 is as you say purely opinion I mean sort of opinion, it’s a pretty solid fact that there is less TO read, maybe you can argue that doesn’t make it more readable. Go package main import "fmt" func main() { fmt.Println("Hello, World") } Python print(“Hello World”) Seems like a no brainer to know which one would be easier and faster to develop sysadmin scripts in from the above alone.
- booleandilemma 4y ago
  Why would you do scripting with something that isn't a scripting language? Especially with a language that prides itself on being like a modern version of C, of all things.
jonahx 4y ago
> composition vs inheritance This is not a mild a difference in practice. > .NET and Java, both garbage collected, are just as fast or faster with a much larger ecosystem. Go executables don't require a runtime.
- kcartlidge 4y ago
  > Go executables don't require a runtime. Neither do .NET executables. Cross-platform single-file dependency-free. (I really like Go, just clarifying because I really like C# too.)
- WkndTriathlete 4y ago
  > Go executables don't require a runtime. Sure they do, it just happens to be built into every single executable. Something has to manage the GC and coroutines for the application.
karolist 4y ago
Go was created as a simple to pickup language to write fast to run and compile (!), memorysafe and typesafe, easily paralelized code with formatter enforcing consistent style from the get go, free from outside idioms which would possibly need to be unlearned when writing software at Google. They have achieved all of this.
- tracker1 4y ago
  I think the inherent parallelization as probably it's biggest feature... not that you can't use similar patterns in other languages, just that it's in the box and scales really, really well.
asoliveira 4y ago
The best comment here. I wonder the same.
cheriot 4y ago
It's the runtime and tooling. Personally, I've largely stopped using the JVM ecosystem and it has nothing to do with the languages. Start up delays killed applets and have always limited command line tools. Now the same startup limitation is afflicting cloud functions. Memory management has always made running JVM processes in a multi-tenant environment complex (from desktop apps to kubernetes pods). The JVM is great in so many ways, but gets extremely complex if you want to do anything the runtime authors haven't prioritized. Maybe GraalVM will change this? After literally decades of waiting, I'm skeptical. /rant Typescript is still javascript and single threaded. Python kinda has types, but most libraries I used don't. Go's popularity is an indictment of every other language ecosystem. It's not better, just less bad.
oppositelock 4y ago
Alternatives are always good, as is competition. Go applies competitive pressure to others, just as they do to Go. I really enjoy using Go as my main server backend programming language. It's verbose, but simple, and that simplicity makes it easy to maintain. The CSP model of concurrency/parallelism works really well at making multi-threaded applications. In Go, I can pull from a work queue, fan out for parallel processing via multiple threads, fan into a smaller pool for some post-processing, really easily. In the HTTP engine, I can service each request with its own goroutine, which lets me write simple, synchronous, linear code, versus using promises or futures or callbacks in other languages, breaking up the flow. To me, subjectively, it's the best backend language when I'm writing something from scratch and don't need to tie into a pre-existing ecosystem. Go exists because there are lots of people like me.
- hazyc 4y ago
  I'm one of those people. I've programmed in a lot of languages, but it wasn't until I was introduced to Go that programming actually become fun rather than more or less a job. Everything about the language just immediately clicked for me, and suddenly I wasn't thinking about the language, but rather what could I build (and I felt like I could build almost anything at that point). Go is about efficient compilation, efficient execution, and ease of programming.
erik_seaberg 4y ago
Go is popular for the same reason Scala is not. You’re encouraged to crank out a lot of ugly repetitive code because the language is so minimal you aren’t expected to learn a cleaner built-in solution (because there isn’t one). Go’s memory footprint is also quite a bit better than Java, at least until value types land. .NET doesn’t seem to have a lot of traction; I’ve been meaning to reevaluate its improved Linux story but haven’t yet.
- st3fan 4y ago
  You can build wonderful abstractions in Go. Now even more so with generics being part of the language. I don't know where this is 'encouraged' but the language itself cannot do that - only engineering teams or leaders can.
- kcartlidge 4y ago
  > .NET doesn’t seem to have a lot of traction I feel like I'm shilling for C# in this thread (a handful of replies so far) so apologies, but I'm genuinely not being partisan here as I'm a dev using both Go and C# daily. However if you think .NET doesn't have traction I can only assume you are excluding virtually the entire enterprise in favour of start-ups and pure-tech firms. For the second group you may be right. For the first group Go is (relatively speaking) absolutely nowhere in comparison to .NET, which has for years had the enterprise virtually sewn up alongside Java. Outside of enterprise I agree you're probably right, which is a shame as it is approximately the equal of Go in most areas, worse in some and better in others.
  - pjmlp 4y ago
    On my enterprise space, .NET has indeed not much traction outside Windows. even with .NET Core as many key products are yet to be UNIX friendly. However when we go for UNIX solutions, Java is the alternative, Go is not even part of the picture unless we are talking about devops tooling (which nowadays is becoming trendy to rewrite in Rust anyway).
sergiotapia 4y ago
.NET and Java are hardly competition. If you're the suit'n'tie engineer that is Corpo through and through you might not notice the baggage but from the outside looking in, both of those stacks have this sheen about them that is just too much architecture. Too many factories of factories of generators of memoized factories. Hell I even tried Kotlin, and got pretty far but it didn't take long to get smeared with some Java stuff. Compare that to Go thats lean and you can write the code with nothing but a text editor and a compiler -- it's very compelling for non-Corpo engineers. It's why I use Elixir and Nim - I can use both stacks with a simple text editor and terminal. They are built with that perspective. I don't have to fiddle around with MavenASPNetResource.xml digging into 14 different nested folders. With all due respect to the thousands of man hours that went into these technological marvels, I just don't have it in me to dive into this kind of stuff again: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/configuration/?view=aspnetcore-6.0#combining-service-collection https://learn.microsoft.com/en-us/aspnet/core/fundamentals/c... Look at it! And weep!
- kcartlidge 4y ago
  You're right. Go is simpler, cleaner, and lower level. But as with anything, when you have the experience even the linked-to code is second nature and not an issue - it's boilerplate, yes, but it is simple stuff that is both obvious and clear to those within the ecosystem and simply represents a different approach. Personally whilst I use Go daily I think Linq in C# is far superior to anything in Go, but it doesn't stop me using Go as well as C# because each has its own approach and each is a better fit for specific needs.
  - tracker1 4y ago
    Funny, I use the fluent extensions from System.Linq a lot, but almost never use actual LINQ syntax.
    - kcartlidge 4y ago
      Yeah, sorry, that's what I meant - Linq in proper-case not caps. Another of Microsoft's annoying naming decisions.
throw_m239339 4y ago
> So... why does Go exist? Because it does offer an alternative to C/C++ for some projects that need to be fast while learning the language requires very little investment. And I say that as someone that has been criticizing Go for a decade. Go has its place. It's absolutely faster than both Python and Node.js as a HTTP Server,produces faster tooling for linux/PC , it's easy to distribute programs written in Go... It is not serious alternative to Enterprise Java development, but neither are Python nor Typescript. However, I don't think Go's opensource ecosystem is comprehensive compared to Python's or Node.js and it is ironically due to how rigid the language used to be which impaired code generalization since it made polymorphism difficult before Generics. It also didn't have an actual package system for years. The Go team has had hard time understanding that in the past.
lacasito25 4y ago
Funny how all the languages you mentioned compile slower than go (C maybe faster). Enforcing no exceptions is a pretty big win for me.
- bornfreddy 4y ago
  You mean renaming exceptions to panics? Or reinventing them through wrapping? (which, admittedly, does have a benefit of possibly clearer stack trace) Go didn't get rid of exceptions, it just made them more awkward.
- za3faran 4y ago
  golang has exceptions (panics). I've worked on large golang projects. Linking takes a very long amount of time. Languages like Java or C# have a much faster compile then run unit test cycle. Even full compilation, it's hard to prove that golang is faster in any significant manner, and could very well be slower.
debug-desperado 4y ago
I think at the end of the day it was about forcing CSP-style concurrency on the majority of Google services. You can make a pretty good argument that CS programs don't do a great job at teaching multithreaded programming (even though it's pretty dang straightforward on the JVM and CLR). Race conditions are often painful to track down. Exceptions are also tough to get right, and many services require several hardening updates because of missing catch blocks or overly thoughtless "catch and log" behavior. Multi-return, despite the verbosity, may be a win on the operations side here. Like you, I wish Google was more ambitious with their language design though. Honestly I'd rather stick to the JVM, especially with Virtual Threads now in preview.
- zozbot234 4y ago
  Go does not force CSP-style concurrency. There's a lot of Go code that uses shared memory with concurrent tasks, even leading to possibe data races and violations of memory safety. (In fact, purely sequential Go is memory safe.)

mfcl 4y ago

Are you asking why alternatives exist in this world?

rs_rs_rs_rs_rs 4y ago

Go is a great language to replace sysadmin scripts written in python or shellscript. I used to imediately jump to python when a shell script would get a little complicated, now I always pick Go.

pjmlp 4y ago
Why should I make myself suffer with a less expressive language than Python?
- deltasevennine 4y ago
  Suffering is a function of familiarity with the language and the intelligence of the user. Go is good enough such that if you had familiarity with both python and go, usage of either is justifiable in terms of expressiveness and ease of use. Your lack of knowledge about this fact, however, is a symptom of intelligence.
hitpointdrew 4y ago
I would hard disagree with this. When bash won't cut it Python is the goto. 1. Python is installed by default of pretty much every linux out distro out there. 2. Go is a bit overkill for something that realistically doesn't need any of the speed/performance benefits you would get in Go 3. No need to compile Python 4. Go is way less readable than Python IMO Go and Rust are fine languages for a lot of things, but sysadmin scripts is not a good use case for either of them.
- morelisp 4y ago
  > 1. Python is installed by default of pretty much every linux out distro out there. If you can install a Python script you can install a binary, and you won't have missing modules or version compatibility issues. > 3. No need to compile Python Anything on a server better be coming out of your orchestration tools anyway...
- matwood 4y ago
  > Python is installed by default of pretty much every linux out distro out there. Which Python? Do I need to install pyenv or venv? What about deps? Python is an absolutely disaster every time I try to use it. Golang easily cross compiles (fast enough it doesn't seem like a compilation is happening) to various platforms, I drop the executable there, and it runs.
- kcartlidge 4y ago
  You're right with half of these, though 4 is as you say purely opinion and 2 depends on the circumstance. It is worth noting however that with `go run main.go` (or similar) you can execute Go without needing to build a binary first so it can behave exactly like a scripting language. And Go builds virtually instantly, meaning for any non-trivial script (and if you prefer Go of course) it's a virtual certainty that given the negligible build time and far better performance a Go 'script' done this way will massively out-perform a Python script. In other words if you don't accept 4 (and I like Python so not a dig) and you have a need for 2 then 3 can become irrelevant and Go is a good choice.
  - tracker1 4y ago
    just realized you can use shebang with a go file... sweet.
  - hitpointdrew 4y ago
    > 4 is as you say purely opinion I mean sort of opinion, it’s a pretty solid fact that there is less TO read, maybe you can argue that doesn’t make it more readable. Go package main import "fmt" func main() { fmt.Println("Hello, World") } Python print(“Hello World”) Seems like a no brainer to know which one would be easier and faster to develop sysadmin scripts in from the above alone.
booleandilemma 4y ago
Why would you do scripting with something that isn't a scripting language? Especially with a language that prides itself on being like a modern version of C, of all things.

jonahx 4y ago

> composition vs inheritance This is not a mild a difference in practice. > .NET and Java, both garbage collected, are just as fast or faster with a much larger ecosystem. Go executables don't require a runtime.

kcartlidge 4y ago
> Go executables don't require a runtime. Neither do .NET executables. Cross-platform single-file dependency-free. (I really like Go, just clarifying because I really like C# too.)
WkndTriathlete 4y ago
> Go executables don't require a runtime. Sure they do, it just happens to be built into every single executable. Something has to manage the GC and coroutines for the application.

karolist 4y ago

Go was created as a simple to pickup language to write fast to run and compile (!), memorysafe and typesafe, easily paralelized code with formatter enforcing consistent style from the get go, free from outside idioms which would possibly need to be unlearned when writing software at Google. They have achieved all of this.

tracker1 4y ago
I think the inherent parallelization as probably it's biggest feature... not that you can't use similar patterns in other languages, just that it's in the box and scales really, really well.

asoliveira 4y ago

The best comment here. I wonder the same.

cheriot 4y ago

It's the runtime and tooling. Personally, I've largely stopped using the JVM ecosystem and it has nothing to do with the languages. Start up delays killed applets and have always limited command line tools. Now the same startup limitation is afflicting cloud functions. Memory management has always made running JVM processes in a multi-tenant environment complex (from desktop apps to kubernetes pods). The JVM is great in so many ways, but gets extremely complex if you want to do anything the runtime authors haven't prioritized. Maybe GraalVM will change this? After literally decades of waiting, I'm skeptical. /rant Typescript is still javascript and single threaded. Python kinda has types, but most libraries I used don't. Go's popularity is an indictment of every other language ecosystem. It's not better, just less bad.

oppositelock 4y ago

Alternatives are always good, as is competition. Go applies competitive pressure to others, just as they do to Go. I really enjoy using Go as my main server backend programming language. It's verbose, but simple, and that simplicity makes it easy to maintain. The CSP model of concurrency/parallelism works really well at making multi-threaded applications. In Go, I can pull from a work queue, fan out for parallel processing via multiple threads, fan into a smaller pool for some post-processing, really easily. In the HTTP engine, I can service each request with its own goroutine, which lets me write simple, synchronous, linear code, versus using promises or futures or callbacks in other languages, breaking up the flow. To me, subjectively, it's the best backend language when I'm writing something from scratch and don't need to tie into a pre-existing ecosystem. Go exists because there are lots of people like me.

hazyc 4y ago
I'm one of those people. I've programmed in a lot of languages, but it wasn't until I was introduced to Go that programming actually become fun rather than more or less a job. Everything about the language just immediately clicked for me, and suddenly I wasn't thinking about the language, but rather what could I build (and I felt like I could build almost anything at that point). Go is about efficient compilation, efficient execution, and ease of programming.

erik_seaberg 4y ago

Go is popular for the same reason Scala is not. You’re encouraged to crank out a lot of ugly repetitive code because the language is so minimal you aren’t expected to learn a cleaner built-in solution (because there isn’t one). Go’s memory footprint is also quite a bit better than Java, at least until value types land. .NET doesn’t seem to have a lot of traction; I’ve been meaning to reevaluate its improved Linux story but haven’t yet.

st3fan 4y ago
You can build wonderful abstractions in Go. Now even more so with generics being part of the language. I don't know where this is 'encouraged' but the language itself cannot do that - only engineering teams or leaders can.
kcartlidge 4y ago
> .NET doesn’t seem to have a lot of traction I feel like I'm shilling for C# in this thread (a handful of replies so far) so apologies, but I'm genuinely not being partisan here as I'm a dev using both Go and C# daily. However if you think .NET doesn't have traction I can only assume you are excluding virtually the entire enterprise in favour of start-ups and pure-tech firms. For the second group you may be right. For the first group Go is (relatively speaking) absolutely nowhere in comparison to .NET, which has for years had the enterprise virtually sewn up alongside Java. Outside of enterprise I agree you're probably right, which is a shame as it is approximately the equal of Go in most areas, worse in some and better in others.
- pjmlp 4y ago
  On my enterprise space, .NET has indeed not much traction outside Windows. even with .NET Core as many key products are yet to be UNIX friendly. However when we go for UNIX solutions, Java is the alternative, Go is not even part of the picture unless we are talking about devops tooling (which nowadays is becoming trendy to rewrite in Rust anyway).

sergiotapia 4y ago

.NET and Java are hardly competition. If you're the suit'n'tie engineer that is Corpo through and through you might not notice the baggage but from the outside looking in, both of those stacks have this sheen about them that is just too much architecture. Too many factories of factories of generators of memoized factories. Hell I even tried Kotlin, and got pretty far but it didn't take long to get smeared with some Java stuff. Compare that to Go thats lean and you can write the code with nothing but a text editor and a compiler -- it's very compelling for non-Corpo engineers. It's why I use Elixir and Nim - I can use both stacks with a simple text editor and terminal. They are built with that perspective. I don't have to fiddle around with MavenASPNetResource.xml digging into 14 different nested folders. With all due respect to the thousands of man hours that went into these technological marvels, I just don't have it in me to dive into this kind of stuff again: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/configuration/?view=aspnetcore-6.0#combining-service-collection https://learn.microsoft.com/en-us/aspnet/core/fundamentals/c... Look at it! And weep!

kcartlidge 4y ago
You're right. Go is simpler, cleaner, and lower level. But as with anything, when you have the experience even the linked-to code is second nature and not an issue - it's boilerplate, yes, but it is simple stuff that is both obvious and clear to those within the ecosystem and simply represents a different approach. Personally whilst I use Go daily I think Linq in C# is far superior to anything in Go, but it doesn't stop me using Go as well as C# because each has its own approach and each is a better fit for specific needs.
- tracker1 4y ago
  Funny, I use the fluent extensions from System.Linq a lot, but almost never use actual LINQ syntax.
  - kcartlidge 4y ago
    Yeah, sorry, that's what I meant - Linq in proper-case not caps. Another of Microsoft's annoying naming decisions.

throw_m239339 4y ago

> So... why does Go exist? Because it does offer an alternative to C/C++ for some projects that need to be fast while learning the language requires very little investment. And I say that as someone that has been criticizing Go for a decade. Go has its place. It's absolutely faster than both Python and Node.js as a HTTP Server,produces faster tooling for linux/PC , it's easy to distribute programs written in Go... It is not serious alternative to Enterprise Java development, but neither are Python nor Typescript. However, I don't think Go's opensource ecosystem is comprehensive compared to Python's or Node.js and it is ironically due to how rigid the language used to be which impaired code generalization since it made polymorphism difficult before Generics. It also didn't have an actual package system for years. The Go team has had hard time understanding that in the past.

lacasito25 4y ago

Funny how all the languages you mentioned compile slower than go (C maybe faster). Enforcing no exceptions is a pretty big win for me.

bornfreddy 4y ago
You mean renaming exceptions to panics? Or reinventing them through wrapping? (which, admittedly, does have a benefit of possibly clearer stack trace) Go didn't get rid of exceptions, it just made them more awkward.
za3faran 4y ago
golang has exceptions (panics). I've worked on large golang projects. Linking takes a very long amount of time. Languages like Java or C# have a much faster compile then run unit test cycle. Even full compilation, it's hard to prove that golang is faster in any significant manner, and could very well be slower.

debug-desperado 4y ago

I think at the end of the day it was about forcing CSP-style concurrency on the majority of Google services. You can make a pretty good argument that CS programs don't do a great job at teaching multithreaded programming (even though it's pretty dang straightforward on the JVM and CLR). Race conditions are often painful to track down. Exceptions are also tough to get right, and many services require several hardening updates because of missing catch blocks or overly thoughtless "catch and log" behavior. Multi-return, despite the verbosity, may be a win on the operations side here. Like you, I wish Google was more ambitious with their language design though. Honestly I'd rather stick to the JVM, especially with Virtual Threads now in preview.

zozbot234 4y ago
Go does not force CSP-style concurrency. There's a lot of Go code that uses shared memory with concurrent tasks, even leading to possibe data races and violations of memory safety. (In fact, purely sequential Go is memory safe.)