Comment by TheAceOfHearts | Hacker News Reader

Comment by TheAceOfHearts | Hacker News Reader

A few days ago I was reading through a few Wikipedia article related to assembly, and I found out Go has its own assembler [0]:

> Some others self-hosted native-targeted language implementations (like Golang, Free Pascal, SBCL) have their own assemblers with multiple targets. They may be used for inline assembly inside language, or even included as a library, but not always suitable for standalone application - no command-line tool exists, or only intermediate representation used as a source, or support for targets very limited.

Despite receive so much criticism, Go seems to be doing pretty well at carving out its own place. It's nice to see a language pick certain categories of problems and just focus on that. I haven't had any chance to write something serious in Go, but I've had to dig through a few projects and it's always refreshingly simple to read and understand. Really wish I could say the same thing about C++.

[0] https://en.wikipedia.org/wiki/Comparison_of_assemblers#As_pa...

> I've had to dig through a few projects and it's always refreshingly simple to read and understand. Really wish I could say the same thing about C++.

That's just not a design goal of C++. Different languages have different priorities and appeal to different folks. Personally, while writing C++ can be frustrating at times and the language still has too many arbitrary restrictions for my taste, every time I go through a Go codebase I feel glad I haven't had to write any Go myself. The amount of mindless, repetitive boilerplate one has to write because the language tries to be "simple" at the expense of abstraction, genericity and expressiveness looks intolerable to me.

But, clearly, there are people that enjoy writing Go and that's great. More diversity in language design can only be a good thing.

There is certainly some of that. Personally, I find that the Go language can be quite limiting, but there are often workarounds for the problems. That said, workarounds aren't a good excuse for failing to have first-class support for various use cases, and sometimes Go simply doesn't have a suitable workaround. These are my criticisms for Go the language. Go the ecosystem is top-notch; there's virtually no learning curve, and almost everything Just Works. Testing, benchmarking, and profiling are all supported out of the box. No project metadata files or build script files to learn or maintain. Everyone's code looks the same (`gofmt`), and the constraints imposed by the language make for boring, super-easy-to-read code, even if it is tedious for the writer. No special documentation syntax to learn--docs are just comments. http://godoc.org is bar-none the best documentation site for any language I've used (everything is in one place, clean layout, easy to navigate, etc). Even if code isn't well documented, documentation tools can use the static type structure of the program to give you enough information to piece together how to use a library.

Depending on the application, the utility of the ecosystem often outweighs the constraints of the language. But inevitably, Go will have to improve as a language before some other language's ecosystem improves and eats Go's lunch.

> Depending on the application, the utility of the ecosystem often outweighs the constraints of the language.

This is the one part where I generally tend to disagree. Basic language constraints are immutable, whereas ecosystem pain points can be fixed if people care enough. Everything you cited is true, the Go people seem to have done a great job at making the ecosystem convenient to use, but language issues are the one thing users can't fix on their own. The C++ ecosystem is fragmented, everyone has their own preferences and we'd all like to see it improved, but individual developers (as well as organizations, just look at Google's internal ecosystem) find a way to make it work well. If there's a dealbreaker in language design, on the other hand, there's just nothing you can do.

I absolutely agree; this is why I prefixed with "Depending on the application". If your application doesn't run into the prohibitive language issues, then you can benefit from the ecosystem with minimum drawbacks.

It's also worth noting that these "prohibitive language issues" can be solved with code generation in the worst case, and while this is often unjustifiably tedious, it's still far simpler than basic C++ project management (maintaining CMake, integrating an editor into your project, setting up testing, cross compiling, dealing with templates and compiler errors, etc). And I say all of this as a former C++ developer. If you can make C++ work in the basic cases, Go's worst case is still far nicer for all but the most performance-demanding applications.

I'm biased due to the performance constraints I work with and actually liking templates for the most part (apart from a few silly restrictions on specialization), but here's how I've solved some of those pain points for myself. I can't stand CMake, but quite enjoy using Meson (though small projects are just fine with a simple build script in bash or whatever you prefer). Error messages and editor integration are largely fixed by the Clang ecosystem, which have also enabled some excellent editor plugins (I use EasyClangComplete for Sublime, there are equivalents for every major editor now). When I care about Windows compatibility, I also use VS2017, which is a great improvement over previous versions and doesn't impose major constraints in terms of standard compliance any more. Perf and VTune satisfy all of my profiling needs.

Overall, I feel like the ecosystem utility / tooling situation has improved hugely over the past few years, to the point where it's comparable to any other language out there, though at the expense of requiring some user effort in choosing tools and getting a bit used to them. That's just my personal opinion, though, YMMV.

This seems reasonable. It's been more than a few years since I got out of the C++ game, and I never really kicked the tires on Meson. I'm truly happy to hear that things are improving for C++; I really liked the language (complex as it was), but I couldn't get anything done because of the ecosystem.

Please report the limitations you have to offer, so Golang2 can get better!

https://github.com/golang/go/wiki/ExperienceReports

Well damn. Someone added my 2014 article to the "generics" section. I didn't even know this wiki page existed.

> The amount of mindless, repetitive boilerplate one has to write because the language tries to be "simple" at the expense of abstraction, genericity and expressiveness looks intolerable to me.

After wasting half a day staring at a totally nonsense generic class definition in Java spanning more than ten lines of code (after having worked in with Java for many years) I do not want any programmer to be clever any more, except he or she has so much social (and code) proof, that I will be delighted to learn something in such an exercise.

For the rest - I might add as a hyperbole - even Golang is too expressive.

Well, let's try to remember criticism isn't a bad thing. Both directly, and the fact that if nobody is doing it then nobody cares.

Reply on news.ycombinator.com