[jjgreen]

Go puzzles me. It's slower than C/C++/Rust and GCed, so not really suited for performance critical stuff. No OO so not really suited for larger complex applications. So for smaller not-performance-critical programs, why not Python, Typescript etc? It seems that its popularity exceeds its scope, or am I missing something?

[vcryan]

Not seeing how OO makes a language more suited for complex use cases. If you said OO approaches add complexity to any use case, I would agree to that.

[vimsee]

Why does it need to be the best in one single metric when it can be great in many?

It is an order of magnitude faster than Python. So it is well suited for performance in many cases.

It is a lot easier to pick up than C/C++. So it is well suited for smaller programs.

I can see Go as a very good middle-ground.

[shrimp_emoji]

> It is a lot easier to pick up than C/C++.

That's why corporations like Google invent "middle-ground" languages.

Go from Google

Java from Oracle

C# from Microsoft

These companies need some performance, but they can't hire enough C/C++/Rust devs (not enough exist). They're flush with JS/Python devs, but those languages are too slow.

So they invent these abominable "middle-level" languages, with their insane bloat.

For myself, I'm not interested in mediocrity to serve corporate interests, so I don't touch them. :p Extremes only: Python and C; Ruby and Rust; JS and C++.

[hobos_delight]

> Java from Oracle

Oracle acquired Java with Sun Microsystems, it was originally designed for embedded systems and the dream of “write once, run everywhere”.

The idea of a “hardware JVM” always fascinated me, I seem to recall some parallax microcontrollers that could run a subset of jvm bytecode back in the 90s, but never actually got to play with them.

[benterix]

> It is a lot easier to pick up than C/C++.

I would say, "it is a lot easier to pick up than C++" as the language specification is much smaller. I wouldn't be so sure about the comparison to C, though.

[usrbinbash]

The fact that Go doesn't have C's macros alone already makes it a lot simpler.

And please don't get me started on writing concurrent code in C.

[EnergyAmy]

`//go:generate` is far worse than C's macros

[saturn_vk]

That's just a glorified make rule. There's nothing inherently hidden or complex that it generates, unlike macros

[majewsky]

I have written Go professionally for close to 10 years. The only time I encountered go:generate is in yacc parsers deep within libraries. A regular Go developer might go for years without realizing that it even exists. Compare this to C macros.

[rplnt]

It's fast enough for most applications. Python and Typescript are unmaintanable. Everything around them breaks as the time goes by. I'd argue Python is not suitable for anything that spans more than one file or one week. I don't have enough experience wtih Typescript to hate it as much, but I know I spend most of my time fighting with the tooling. Again, unless you are writing a fresh application that is fine to throw away after a year, Typescript is not it.

Go excels in that it is so simple. As the saying goes, you mostly read code, not write it. Go is very easy to understand and review. Which is what you do mostly when working on complex systems in teams. It's extremely easy (and fast) to build and deploy unlike the languages above. That's why companies use go. Not for personal projects, not for drivers, and also probably not for corporate monoliths that require a suit and a tie to contribute.

[jjgreen]

Heh, my brother-in-law is a Java suit-and-tie dev, he was telling me that he'd been working on a project for 18 months, the specifications were almost complete and he'd be starting on the coding soon. Being in the startup space I was slack jawed, it's a half-day planning and then start hacking up the MVP for me. Worth noting that he drives a BMW.

[EnergyAmy]

Go is easy to understand like Brainfuck is. One singular piece is easier to read, but you've just spread the complexity around, making it hard to see the bigger picture.

[Cwizard]

It compiles down to a single binary and is relatively easy to write. I think that is the reason it is such a popular language for CLI tools.

You will never have an issue with missing dependencies or outdated runtime.

[scumola]

Nothing is stopping anyone from compiling C or C++ code into a single static binary too. This argument is bull$%!#.

[dontlaugh]

OOP is generally a bad idea, so lacking it is not a downside.

The bigger problem is the weak and inexpressive type system, which is no better for C or Python.

[madeofpalk]

And still has null pointer exceptions. I could see a role for it in between like rust and python if it had a sane type system.

[Cwizard]

I really like Go but the type system is just a bit too weak in my opinion. It is the biggest issue I have with the language ( and the fact that errors are basically untyped, you can type them but no one does…)

[usrbinbash]

> so not really suited for performance critical stuff.

What "stuff" is that exactly? Because Go is designed primarily for backend services and microservices. Considering how much backend software is powered by Python, Java, or *retching sounds* PHP, I highly doubt that is a major consideration in that area.

And even when performance actually does matter to an extend where it becomes a more pressing issue than network latency, Go code performs incredibly well and is more than a match for most requirements.

> No OO

How do you figure? I can write in a completely object oriented style in Go. Also, OO is not a prerequisite for large complex systems, and quite often strict adherence to it can make code much harder to maintain than it needs to be. Maintaining large complex systems requires, first and foremost, code that is easy to grok and maintain. And regarding that particular area, Go runs circles around any major contemporary language, including Python.

> It seems that its popularity exceeds its scope

Considering how widespread it is by now, I highly doubt that.

[amelius]

The same can be said about Rust: its popularity exceeds its scope, because 99% of applications I see that are written in Rust are better off written in a GCed language.

[frankjr]

Except when you actually enjoy things being fast. For example, HTTPie easily adds 0.5-1s delay to every request because it's written in Python, especially on the first invocation. xh (https://github.com/ducaale/xh), on the other hand, starts immediately because it's written in Rust. I very much like this trend.

[benterix]

Yeah, I agree on that. In the nineties, basically the only general purpose language was C, with C++ growing in pains (and then extending uncontrollably) and Java promising to get better but having its own issues at that time. So people who needed to get their job done (efficiently) just used C, like Torvalds.

At that time, this new Python language was a curiosity. It was nice that you could easily replace dozens of C code with one line of Python but everybody was aware it's too slow. However, this window shifted with time. The perceptions of "fast" and "slow" changed for various reasons such as network delays so Python became acceptable in many areas it would be dismissed otherwise. To the point it became the no. 1 language now.

But we are not in the 2000s anymore. We do have powerful, batteries-included languages that are faster than Python. So I expect with time, large parts will be rewritten. However, the area related to scientific computing will stay with Python, just like Fortran programs continue to be used today.

[jkbr]

I don’t know when you last tested the start-up time, but we significantly improved it in HTTPie CLI 3.0 [0]. Now it’s still slower by ~0.1s.

    $ time http --version
    3.2.2

    real 0m0.113s
    user 0m0.087s
    sys 0m0.020s



    $ time xh --version
    xh 0.18.0
    -native-tls +rustls

    real 0m0.007s
    user 0m0.002s
    sys 0m0.002s

[0] https://httpie.io/blog/httpie-3.0.0#speed-ups

[frankjr]

> Now it’s still slower by ~0.1s

Not for me. Printing HTTPie's version takes longer than to finish a real http request with xh. I suspect it's because I'm testing it on a relatively old server where the differences are even more pronounced.

[link redacted]

I'm using HTTPie 3.2.1 because Arch doesn't have the latest version available but based on the release notes that shouldn't make a difference.

[jkbr]

Gotcha. Would you mind checking if you happen to have PyOpenSSL installed inside the Python environment HTTPie runs from?

[frankjr]

I did not have it installed. Installing it did not make a difference. If it's of any help, here's a profile generated using cProfile. [link redacted]

[amelius]

Python is not a good comparison. It's improving but its runtime system is very slow compared to a modern concurrent GCed system.

[brigadier132]

Except when you suddenly do need performance and predictable latency but all your software is written in python. Its always funny how these performance requirements just creep up on you like that.

[ycuser2]

C# is GCed but has 'unsafe' blocks.

[neonsunset]

Yup, and (monomorphized) struct generics, first-class SIMD vectors and ability to transparently work with memory ranges because Span<T> can also wrap T* + Length from unmanaged code, which lets you directly plug whatever data you got from C/C++ dependency into most CoreLib APIs.

In this regard, Go is far inferior as a systems programming language.

[pjmlp]

Alonside value types, manual memory allocation if needed.

Not all GC based languages are made alike.

[amelius]

Yeah what we really need is a GCed language that allows you to implement parts in no-GC mode. And ideally where you can iteratively migrate GCed parts to no-GC parts when required.

Anyway, Python is not a good comparison, as performance is not one of its main qualities.

[rapsey]

I went from Erlang to Rust and frankly I would not say Erlang is more productive, despite being a very high level language. When building a non-trivial system one should think about total cost of ownership.

A Rust program is by default going to be CPU and memory efficient. It is not likely to negatively surprise you in production with weird bottlenecks and unexpected behavior.

The time invested in producing a solution which is statically typed, pays of in spades when it is time to refactor or change something (which is pretty damn often if it is your product). Refactoring a Python/Erlang/Elixir/C/PHP solution is a major PITA and fraught with new bugs.

The time spent optimizing solutions in high level languages when they are falling on their face in production is generally ignored and extremely common. You do not have to be github to face performance problems in Ruby.

[jjgreen]

As fast as C but with correctness, Rust kind-of owns that space (not a big fan personally).

[narinxas]

what about Zig?

I think they're a strong contender... it's somehow simpler than Rust

then again the correctness guarantee may be weaker??

[pjmlp]

Still no story for UAF, and the community is against shipping binary libraries.

[fallat]

zig has less memory usage correctness guarantees but its type system is good too.

[usrbinbash]

> Rust kind-of owns that space

True. But it's a pretty small space to be in. And there are good reasons for that:

a) The only correctness Rust can, mostly, guarantee, is that there won't be unexpected data races or memory bugs. While this is proudly announced often and loudly, it also isn't the most common problem in code...logic bugs...against which the rust compiler can do as little as any other language.

b) Rust can only give these guarantees because it is ALOT more complex than C. That means harder to read, harder to write, harder to learn. And developer time matters. Alot. If I can already ship features, while my competition is still stuck in onboarding, it won't matter if my code has the odd memory bugs...those can be fixed...I will already have the market to myself.

[rapsey]

> a) The only correctness Rust can, mostly, guarantee, is that there won't be unexpected data races or memory bugs. While this is proudly announced often and loudly, it also isn't the most common problem in code...logic bugs...against which the rust compiler can do as little as any other language.

A powerful type system helps quite a lot with logic bugs actually.

[usrbinbash]

> A strong type system helps quite a lot with logic bugs actually.

A static type system does, and all the languages that Rust has to compete with in its space, have one.

[rapsey]

Go's type system is much less expressive and it has null pointers. An entire giant class of bugs.

[ignoramous]

This talk by Rob Pike answers some of your questions: https://go.dev/talks/2012/splash.article

[ryandvm]

Go is:

* Easier/safer than C

* Less dangerous than Javascript (statically typed and a good standard library)

* Much faster than Python

I think it's an excellent middle ground, compromise language. It's the centrist candidate of programming languages. Not the best at anything, but on average better than most.

[scruple]

I'd add that it also ships with an incredible toolset alongside the installation, has a fully featured standard library, cross compiling is typically painless, and you get a single binary executable out the other side.

[conor-]

> So for smaller not-performance-critical programs, why not Python, Typescript etc?

I can compile my go application down to a single, static binary that can run in a distroless container. The packaging/deployment simplicity of Golang appeals to me much more than Python, TypeScript, etc.

Also the developer tooling is first class and sustained backwards compatibility is top-notch. I can pretty much always upgrade the version of Go 1.x I target and have 0 worries in the world. Meanwhile in Python and JS land, the dependency management problems are a nightmare.

[lm28469]

It's really nice to use though, I never liked python and its environment, coming from C go feels like home to me, it's simple and it just works. I never had headaches to setup and run things like I had with python and js.

Performance is good enough for most jobs, we're not all working on the bleeding edge, a lot of jobs are more akin to code monkeying basic CRUD

[mauvia]

IME people recommended it for being more batteries-included in terms of webservice stuff and some multithreading/scaling stuff, as well as having multiplatform support and libraries being compiled into the executable.

The language also seems to be built for the kind of people who think C has no downsides and everyone should write everything as explicitly as possible, which are an audience that normally doesn't get aimed at.

[pjmlp]

Docker (originally written in Java until Go advocates took over), and k8s are what made it popular.

Now it is kind of unavoidable in DevOps space for some cenarios.

My only complaint is their approach to language design.

Inferno with Limbo, Android, Windows Phone, show that there is GC hate, and shipping products to millions of users.

[elp]

If Docker was in Java it would have been still born / Java universe only.

I don't get the GC hate. If its done properly (like Go) its invisible for 99% of applications and dramatically simplifies things like business logic that don't need to be that complicated or fast.

The real culprit is usually Java's slow startup and memory bloat from the JVM.

[pjmlp]

Nah, that is what anti-Java folks wish for.

Java is so bad that Kubernetes + WASM containers is basically redoing application servers 20 years later.

[bitshiftfaced]

> No OO

Are you referring to Object Oriented programming? And if so, why not?

[Fire-Dragon-DoL]

You just cited C, how's not having oop a requirement for big apps?

Also, unless inheritance is what you mean by oop, it supports the other usecases of oop

[ecmascript]

I don't use Go since it's from Google but I wouldn't say that Go / Java can't be used for performance critical stuff?

There are a lot of values that goes into "performance critical stuff". For me, it can mean a chat app / money transfers etc that is performance critical but is is of course not as critical as in flight software or other system control software where GC could mean deaths.

[jjgreen]

I meant speed-critical by that, sorry if that was unclear. I see opinions like "1/3 the speed of C" bandied around, not bad but means a big model run takes three days rather than one.

[dagw]

"1/3 the speed of C"

Of course C can be is 1/3 of the speed of C, if the C is written by two different people. An average Go programmer might very well produce faster code than an average C programmer, if Go has better tools for doing normal things fast in an easy and obvious way

[pjmlp]

Are weapon targeting systems and battleships speed critical enough?

https://www.ptc.com/en/products/developer-tools/perc

[k__]

K8s is it's lifeline.

[cultavix]

Exactly. This is exactly my thought, my only reason for learning Go Lang at all, was/is because of Kubernetes and much of the tooling around it.

[jjgreen]

Interesting -- thanks for that

[dirteater_]

No OO?

[usrnm]

Go is basically a very specialized language for writing small network services that are supposed to run on Linux. If this isn't your use case, then don't use go, but if it is, then golang is nice. Mostly the runtime and tools, not the language itself, though