Hacker News Reader

Comment by native_samples | Hacker News Reader

"This is encouraging news for a language already known to be unusually both fast and easy"

Hmm it's not known for that, is it? Go is known to be quite slow due to a weak compiler and a GC that optimizes for latency over throughput. And is Go really easier than a language like Java or in the dynamic world, JavaScript? It sure does seem to have a lot of weird edge cases and potholes to trip over.

Anyway I see a bunch of comments saying generics shouldn't make anything faster. They can make code go faster in combination with specialization and value types. It's one of the reasons C++ can go very fast whilst still supporting higher level abstractions, albeit at the cost of generated code size. It's also the reason they're adding value types and specialized generics to the JVM. I don't know if Go is doing C++/Rust style specialization or not, but it at least has the potential to do so.

View on HN

> Hmm it's not known for that, is it?

It’s a hugely generalised statement so the real answer is “it really depends on your context”

Is it fast compared to other easy to learn languages? Definitely. Is it fast compared to other systems languages? Lol no. But is it fast to compile compared to other systems languages? Generally, yeah.

Is it easy to learn compared to other systems languages? Very much so. Is it easy to write complex low level systems logic? No. Is it easy to write dynamic code? No.

The problem with generalised statements against general purpose languages is that the scope is so wide that people will cherry whatever context they want to suit whatever argument (for or against) they choose.

> Is it easy to learn compared to other systems languages? Very much so.

I think this is debatable and depends on your background.

If you come from a Java/C background then many things are unintuitive e.g. error handling, dynamic interfaces, package/library management, whitespace parsing, style enforcement etc.

Golang is easy to learn right now because it's basic like say Java 1.2. But since it likes to ignore what other languages do I wouldn't say it's an inherently easy language.

Even then, it's remarkably easy to read Go programs. This is very important.

I do code reviews for Go every day and it is easy but also frustrating and tiresome.

The ridiculously antiquated error handling and the absence of modern FP constructs e.g. filter/map means that 1 line of Scala/Swift/Rust/Java etc code = 10 of Go.

> e.g. filter/map means that 1 line of Scala/Swift/Rust/Java etc code = 10 of Go.

Honestly, fuck this noise. I hope this never makes its way to Go. Densely packing logic is not inherently better. I've done enough Scala/Rust/Java reviews and those are frustrating and tiresome.

On the contrary I hope generics in Go mean that bug hives of mutation in loops get replaced ASAP with higher order functions. I for one have plans to work through several code bases and do just this starting the second Go 1.18 lands.

the lack of filter/reduce and other higher order functions is precisely what keeps me out of go. I don't want to be restricted to what I learned about programming in my first year. Go forces me to code like a first year college student.

This was one of my huge struggles with Go before I just out and out gave up. So much 'good' Go code at my office was just CS101 spaghetti.

not to mention, you don't gain much performance for it either. I can understand c or zig's choice of tradeoffs with simplicity being paramount when you're going close to the metal but for go's performance, Elixir, which is my daily driver, gives me comparable performance while giving me higher order functions, built in message passing, parallelism and actual error handling tools.

Compared to GenServers, Tasks and Agents, go-routines and javascript async are toys, like fischer price vs fischertechnik.

Go feels like a bunch of unneeded compromise for people needing to work with junior programmers.

That said, if I needed a quick and dirty low level application for controlling an OS process or a lambda function on the cloud, I could see go's benefits. I could certainly build a poc faster than I would be able to in rust and the overhead of the runtime/startup is much smaller than elixir.

There's nothing "antiquated" about Go's error handling. It expresses a position that you might not agree with -- that errors are no less important than happy path code -- but that's not right or wrong, it's just a position.

Go is incredibly hard to read. There's no intentional. Everything from error handling to flow control to business logic all looks exactly the same. On top of that naming conventions and package constraints tend to absurdly long and verbose (and therefore hard to read) programs for what should be trivial.

Obviously false (shrug)

> If you come from a Java/C background then many things are unintuitive e.g. error handling, dynamic interfaces, package/library management, whitespace parsing, style enforcement etc.

I’d argue that doesn’t make Go hard to learn, that makes Go hard to adapt to for people who are used to and like Java. Ie You’ve still learnt the language of Go even if you haven’t warmed to its idioms.

But semantics aside, your comment here beautifully illustrates my point about how generalised statements can be skewed to suit any argument. Take your last paragraph where you used the term “easy” in a multitude of ways, each carefully selected to promote your existing opinion of Go:

> Golang is easy to learn right now because it's basic like say Java 1.2. But since it likes to ignore what other languages do I wouldn't say it's an inherently easy language.

This isn’t an impartial point you’re making. It’s an opinionated one. Which is fine in itself because you’re entitled to opinions but it does demonstrate the pointlessness of arguing about generalised statements where everyone is going to infer their own context based on their own biases. Ie Bob might find language X “easy” under a different context than Sally finds it difficult. But those context are not equivalent despite the adjective they’ve used being the same.

Yes I saw that internally at Google in early days of Go, people often said that Go is going to replace either Java, or C++, depending on context. So I felt like it's going to take a niche somewhere in between those two..

Go isn't even easy to learn compared to high level languages let alone system language. It is the only language I ever gave up on after 3 months of struggle I concluded I'd rather work with anything else.

You’re conflating “easy to learn” with “easy to program for” sigh. And that wasn’t even the point of the post so you got that part wrong too. In fact did you even bother to read the thread before jumping in with that post?

The point wasn’t whether Go is easy or not, it’s that “easy” means different things to different people (like here where you conflate “easy to learn” with “easy to use” thus “easy” meant something different to you vs the rest of the English speaking population). So arguing about a generalised term with zero context is stupid. Just as stupid as the editor wars of the 90s and Linux DE wars of the 00s. I guess some people just like to browbeat their peers into believing personal preference isn’t a thing.

Wow, which language did you find easier to learn than Go? HTML doesn't count.

This is going to sound weird but I picked up both Rust and Erlang far faster than Go.

Edit: my point isn’t that others shouldn’t enjoy it but it being easy is not universal or to be taken as given.

>Hmm it's not known for that, is it? Go is known to be quite slow due to a weak compiler and a GC that optimizes for latency over throughput. ?

Lol what ? Go is generally 'the' tool me and quite a few of my friends reach for when they want todo some heavy-lifting without getting bogged down in the weeds of things. Sure you millage may vary.

And in your view Go might be slow (compared to) ? But Go is definitely NOT slow for any sort of general computing. Faster than NodeJS, (ok i'm cherry picking now) mostly on par or with C# or Java depending on your benchmark-magic of choice. Super easy to do multicore and concurrency with it and definitely faster to compile than Rust.

Does it have warts or not the best language ? Absolutely ! But it's definitely not know to be "quite slow" and having a "weak compiler" ?? To be honest in this is the first time I've heard that exact claim "quite slow" :/

Of course it's faster than JavaScript. I meant slow compared to comparable languages like C++ or Java (statically typed with high effort compilers).

It's not slow compared to Java or C++ !?? LOL show me benchmarks where is slower and I will show you benchmarks where it's faster !

>> Go is known to be quite slow

I understood it was comparable to Java or C#, both of which are extremely fast - both in terms of execution speed and more so in terms of developer productivity.

The benchmarks I’ve seen generally back that up

https://plummerssoftwarellc.github.io/PrimeView/report?id=da...

9th overall - faster than c++ for example in Dave Plummers primes benchmark. I quite like that benchmark because it’s really just a bunch of memory operations, a decent view of the compilers ability to generate decent code. Although my concern with this benchmark is that not all languages got the same optimisation effort. Looking at git commits, it seems like rust got almost more optimisation effort than every other language combined.

Also i don’t like the unfiltered view of that benchmark - lisp comes out fastest language of all but that’s because languages like c++ and Rust can only really pre calculate results at compile time (constexpr etc) - whereas that lisp implementation is doing everything before compilation. Unfair because other languages don’t have a programmable precompilation reader phase.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

In the area of java, Swift etc i don’t like these benchmarks at all though. The c# one for example often relies on c libraries or vector intrinsics etc so it’s not really like for like.

https://www.techempower.com/benchmarks/#section=data-r20&hw=...

Between java and c#

> … not really like for like…

Except when it is: this C# program seems to have been transliterated from the Java program —

mandelbrot C# .NET #5

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

mandelbrot Java #2

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

And in the listing —

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

That highlights my point pretty well - you've chosen one of the c# impls that doesn't use anything more than a few compiler hints but it's slower than the java solution.

However if you look at the overall results, c# is about 25% faster on mandlebrot, and when you peek under the covers - https://benchmarksgame-team.pages.debian.net/benchmarksgame/... - you find it's using AVX vector instructions.

Not like for like in the summary view which is why i think those results are misleading.

> … slower than the java solution.

4.10s Java #2

4.11s C# .NET #5

----

> … overall results, c# is about 25% faster on mandlebrot…

You say "overall results" but the webpage says —

"Always look at the source code.

These are only the fastest programs."

Your missing the point, javascript is easier but in the class of languages go is in, its a day and night difference.

rust, c/c++, java etc. Compared to these languages, go is much easer to learn and use. Java can be put the side, the real comparison is with c/c++ and rust.

By taking some trade offs on the performance side, go has a much better UX than rust/c.. Literally open up a few tabs, go to github and compare a page of go code vs rust vs c/c++..

Go is fast.

Generally speaking, you can expect a well-written Go program to be no more than 50% slower than well-written C. Normally the Go program will only be 5% or 10% slower.

Saying this another way, a carefully written C program that takes 100 seconds to run can be converted to Go and might take 150 seconds to run, in a bad case. In a typical situation the Go program will take 110 seconds to run.

Of course, a bad programmer can make anything slow.

I'm not sure how you get from 50% slowdown to fast. That's my point - in the space of ahead-of-time compiled, statically typed languages Go produces code that runs significantly slower than other languages. Even if you include JITCd languages it's not that fast. It's an intentional choice, so I really don't even know why this is proving controversial - Go's designers were always crystal clear that their priorities are:

1. A fast AOT compiler (which therefore, cannot spend much time optimizing things)

2. A low latency GC (which therefore, sacrifices throughput)

3. Ease of use (which therefore, means avoiding complicating the language with optimization related features)

Not included: raw performance.

Because there's a point where additional performance doesn't matter.

Using C instead of Go is a mistake for all but the most performance critical applications. Use C for small pieces of code that need maximum performance. Use Go everywhere else.

If you're writing a compiler, use Go: it's easily fast enough and very programmer-efficient. If you're writing SIMD convolution code, use C. For example, here is my compiler (written in Go) that generates AVX-512 neural net convolution code in C: https://NN-512.com

For almost all purposes, Go is a better choice than C. Go is almost always fast enough by a wide margin, and the resulting program is easier to write and higher quality.

> I'm not sure how you get from 50% slowdown to fast.

A mere 50% slowdown over C given Go's ergonomics? That's amazing.

Although, you and the parent are talking about different things. He didn't say "Go is 50% slower than C" he said well written Go is up to 50% slower than well written C. I'd expect average Go code to be 100%+ slower than average C code, which is likely what you're talking about.

> That's my point - in the space of ahead-of-time compiled, statically typed languages Go produces code that runs significantly slower than other languages.

That's not the space Go is in. You forgot a huge factor - memory management. Go has a GC and therefore is not anywhere near the same space as C/Rust/C++. Thus, such comparisons are inherently flawed - Go isn't competing on speed with C/Rust/C++, but with Java/C#.

>I'd expect average Go code to be 100%+ slower than average C code

Sorry to nitpick, but that means the Go code will never complete.

I didn't forget memory management, point 2 in my list is about the tradeoffs involved in GC. What you and 37ef_ced3 are giving me here is a list of reasons why it's OK for Go to be slow or at least slower than C++, which is fine. Go inhabits a particular point in the design space and it balances performance against other factors - great. My beef was with the statement that Go is known to be "unusually both fast and easy". It's not known for that. It's known to be a sort of middle-ground jack of all trades. If someone told me they were using Go because it was fast, I would think they didn't know much about programming languages, or I'd have to read a lot of context into what they were saying (maybe they only had experience with Python before, as is the case for many Go programmers).

I don't think your point is controversial, its just missing context.

Having a language that can hold its own weight in the AOT, statically typed world while also having the UX thats comparable to javascript is insane.

Rust, C/C++ is a last resort, your'd only touch it if you absolutely need it.

To have a language with better UX than Java, C#, Python etc. that greatly expands how far you can go without resorting to C/C++ is super kewl!

> Go is known to be quite slow due to a weak compiler and a GC that optimizes for latency over throughput.

I don't know how you're measuring "slow" but from where I sit in the software ecosystem Go is typically one of, if not _the_, fastest language available. It's entirely correct to optimize for latency over throughput, for my use cases.

It's been a long time that I developed in Go, but at the time I though it was a better python. As easy as python, but faster. At least for backend stuff.

Does it have a lot of weird edge cases? Probably yes. I'm no expert in Go, but I don't think it has more or less than any other language.

Reply on news.ycombinator.com