Hacker News Reader

Comment by gct | Hacker News Reader

I want to like Go but it's just too much of a mess of a language, and the power it gives you isn't enough to justify it. C++ is at least fast. You can see this in the proposal for generics[0], where they have to tap dance around the fact they didn't consider generics in the language from the beginning.

[0]: https://go.googlesource.com/proposal/+/refs/heads/master/des...

View on HN

> it's just too much of a mess of a language

This is vapid criticism, and it's only going to invite language flame wars. There's certainly room to criticize Go, but just saying it's "a mess" isn't contributing anything to the conversation.

Just a minor note on Go vs C++.

C++14 specification: 1354 pages.

Go specification: 50 pages.

And brainfuck is 340 lines: https://github.com/brain-lang/brainfuck/blob/master/brainfuc...

Not sure why this is downvoted. It pretty clearly demonstrates the point that there is a such thing as being too simple, and that simplicity for its own sake is not a virtue.

R5RS is 40 pages and you can do so much more in that language.

for c++ spec, many are due to back compatibility. if you stick to modern c++ for new projects, it's much concise with much less pages.

Can you link to such a document (one that details the spec for only recent versions of C++)?

Are there any web frameworks you particularly like in C++?

Just want to add that Go is ready for webdev pretty much out of the box, you don't need a framework to work with HTTP requests, routing, basic auth etc. There are things like gin/mux that makes it more convenient, but absolutely not necessary.

The language has barely changed since 1.0.

Small compromises in generics doesn’t make it a mess.

It's also weird to use C++ to support the argument that Go's generics are too bolted-on (as though C++ generics resemble a holistic upfront design). I like C++ and everything, but I've also used it and thus know better.

You're not wrong, mistakes were obviously made with C++ (and Rust for that matter).

As in http://yosefk.com/c++fqa/

The whole point of Golang is that it is easy to read, contribute to, and maintain. This is because it is less expressive, and you have less freedom when you write code. In turn this can make writing code harder, but that's the trade off you have to take if you want to make reading code easier.

I firmly believe that people have managed to write amazing and large applications without generics, and the addition of generics will simply kill one of the biggest feature of Golang: simplicity.

Could you elaborate on what power it give? After working on several projects in a golang monorepo, it's exceedingly weak at modeling, which results in verbose code that is also thin - meaning that it takes a lot to write to say a few things. You can see the for loops and if conditions in front of you, but it's difficult to extract the underlying logic its trying to convey.

The code bases were a complete mess to work on, and even new projects are suffering because of it - no lessons learned can fix it because the language is so weak.

I said it _doesn't_ give you enough power to justify the baggage, apologies if I wasn't clear. Iteration/modeling is one of my gripes in fact. The only way to copy a map is a for loop, really?

Sorry about that. You wrote that the power it gives you does not justify the mess of the language. I agree that the language is messy, but that it also lacks any power whatsoever worth speaking about :)

This isn't really fair. Despite requiring overly verbose code with lots of repetition and boilerplate, it is still quite powerful.

Could you list some of its powerful features? The only thing that gets a passing mention is goroutines, and even they are not implemented in a great manner.

Portable binaries, good cross-compilation support, easy to make shared libraries for use in, say, Python code for easy performance gains, goroutines and channels (they are a mixed bag).

Apart from these, the language does make it easy for novices to write performant one-offs similar to how Python enables them to write slower one-offs. I personally hate writing in it, but I will when I think it makes my life easier.

> Portable binaries, good cross-compilation support,

Nothing to do with the language. Other platforms provide the same features.

> goroutines and channels

Extremely verbose and also error prone. C#'s Tasks are much better abstractions for example.

> the language does make it easy for novices to write performant one-offs

Nothing to do with the language itself, it's just that it's compiled not interpreted like Python.

Tooling is an important part of a language.

It is, and Java/C# and gang have superior tooling.

Engineers who complain about that are usually the ones who want to write extremely clever solutions that nobody will be able to understand nor maintain after they have left.

>You can see the for loops and if conditions in front of you, but it's difficult to extract the underlying logic its trying to convey.

That's what abstraction is for. Do you not use functions or something? Do you not group related ones in packages, and pay attention to how they model your domain?

What you're pointing out seems more like bad programming practice than a bad language. Even PHP doesn't have this problem.

Reply on news.ycombinator.com