> 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.

> 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.)

> 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.

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.

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.

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 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.

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.

> .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.

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).

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.

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.

> 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.

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.

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.

> 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...

> 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.

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.

just realized you can use shebang with a go file... sweet.

> 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.

What you've shown is that Go takes 5 times as many lines of code, but this is a trivial example based on boilerplate. Once you scale your codebase up beyond a handful of lines the percentage which is actual boilerplate becomes negligible and this example ceases to be valid.

As an aside, I can't deny that on a per-line or even per-scope basis Python is often more readable. But at the meta level where you're dealing with an entire codebase, which to me is more relevant, the structural aspects come into play and that's where it devolves into pure opinion.

In other words, comparing for readability across a handful of lines is not valuable unless you're only dealing with codebases which are also only a handful of lines.

Of course the main driver of this thread is script files, and for readability Python probably does win as they tend to be short. But I'd argue that as long as something is readable enough (which Go is) then other factors like performance may need to come into the decision.

4. Type hints make python readable, but with as with most scripts people avoid type hints. This makes python actually less readable then go. Additionally python syntax allows for some very convoluted patterns. This is less the case for go. Go syntax forces explicit procedural steps while python you can throw 20 steps into a single 1 line list comprehension.

3. Go compiles so fast it's not that far off from an interpreted language.

2. It's not as big of a scripting language but it's close enough such that I can see justification for it's usage.

1. Yeah but go can be installed pretty quickly from package managers on every linux distro out there.

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.

Why should I make myself suffer with a less expressive language than Python?

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.

Are you asking why alternatives exist in this world?

The best comment here. I wonder the same.

.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/c...

Look at it! And weep!

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.

Funny, I use the fluent extensions from System.Linq a lot, but almost never use actual LINQ syntax.

Yeah, sorry, that's what I meant - Linq in proper-case not caps. Another of Microsoft's annoying naming decisions.

You can write pretty light C# code... I find that it's C# shops I tend not to care much for, not really the language/tools so much.

You're comparing a fully fledged framework to a language, so not apples to apples comparison. At an employer that heavily used golang, they had to reinvent frameworks (dependency injection, web app, RPC, etc.) to standardize how work was being done, and guess what, you ended up having huge stack traces anyway that some people mock ASP.NET or Spring for, not to mention very slow build times. Modifying small parts of code and rebuilding to re run unit tests was so time consuming it's not even funny. I had a faster experience with Scala and SBT, so that's saying something.

> you can write the code with nothing but a text editor and a compiler

Nothing is stopping you from doing the same in other languages. At some point, the benefits of what IDEs offer (refactoring, inspections, integrated debugging, profiling, etc.) almost become necessary when working on large programs.

Funny how all the languages you mentioned compile slower than go (C maybe faster).

Enforcing no exceptions is a pretty big win for me.

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.

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.

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.

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.)