Hacker News Reader

Comment by bfrog | Hacker News Reader

Liking Go has nothing to do with being a quality software engineer. Go itself is probably the least software engineering friendly language out there. The goal of a computer language is to express your thoughts and instructions into something a machine can understand. Full stop. Go is absolutely terrible at letting you the human express what you want the machine to do. It has compile time type checks, but then fails to provide the hatches needed to work with types sanely. It has the ability to call out to large bodies of C code, but not without significant costs. It compiles fast, which is good, because your going to write a lot more code to do the same things you'd do in other languages, even other compiled languages.

View on HN

Yeah the type system is absolutely horrid. Just try to use any other type size than int, int64, float64 then you will be in a lot of pain casting every time you use them.

It's so silly for example that math.Min/Max only works on float64, it won't work with float32 without casting, or integers (although for ints is highly discouraged, because casting to float could cause you to get a different number, it is encouraged to just do if statement yourself)

It is a horrible language, only popular because it came from Google. It's biggest benefit was that it supposed to be easy to pick up, but it also demonstrates that the simplicity doesn't help at all with a significant code base, you still have to spend the same amount of time to learn it as in any other language.

> Go itself is probably the least software engineering friendly language out there

My experience with software engineering went from "the language (type system, grammar, syntax, etc) is super important!" to "the language is one of the least important considerations in choosing a language". The more important features are tooling and ecosystem.

I don't want to have to learn a new configuration language or imperative DSL just to add project dependencies or setup tests. I don't want to have to learn yet another documentation framework for generating documentation from code comments. I don't want to have to spend lots of time setting up CI/CD pipelines to build my source code and documentation packages and publish them to their respective repositories. I don't want to have to worry about whether my users or fellow developers have the right versions of dependencies or the runtime installed on their system. I don't want to have to make unmaintainable Dockerfiles because it's the only way to have performant builds in the happy path. I want to minimize time wasted during code review on comments about style or programming paradigms. Similarly I don't want to waste time waiting for code to compile.

If the language is type safe in 95% of cases, that's good enough--people still make lots of money writing lots of 100% untyped JS and Python and Clojure and so on--the extra 5% would be nice to have but I'm not going to trade tooling, ecosystem, and developer velocity for it.

Basically, as I become more experienced, I begin to understand the difference between programming and software engineering (my heart is in programming, but software engineering pays the bills). Go is a great language for software engineering, but most of its criticism seems to be directed at programming concerns.

> Go is a great language for software engineering

Is it though? While tests in go are not terrible, to be a truly effective software engineer (vs just a programmer or dev) you want a very good test and documentation story, and there are languages out there with far, far, better tests and documentation primitives than Go.

I think the point is that Go gets like a 90% score in most categories. You can get languages that score 100% in performance or testing or documentation, but they tend to trade off 60+% in several other important categories.

Further, I contend that Go has excellent documentation primitives, notably that it doesn't have any sort of markup or documentation package management. I've never seen a better language in this regard.

Can you name a few? Genuine question. I've only really written a lot of tests in Python and Go, and I really dislike the python tests I've had to write. I don't think it's so much the language itself, but that python is so flexible with the mocking you can do that it enables code that is really tedious to test. With Go you have much more limited ability to mock things, so there are added constraints for code to be testable.

Similarly, with documentation, I really like that the godoc toolchain has resisted all the markup and annotation syntaxes that you see in Java. And I like that Go's convention of using a public URL as the module import path helps enable sites like godoc.org.

I find the language itself slightly more than mediocre. But I really like the toolchain and the restraint of the maintainers.

Must be a matter of preference but this is exactly what I hate about godoc. I'd love to use markdown or any other structure, really. Just a wall of plain text is sometimes good, but most of the time bad idea for readability. And the idea of starting each godoc comment with function/variable name is terrible. YMMV.

Testing wise, elixir is fantastic. I have a relatively large codebase where I run what are effectively full on simulations of the system in sharded-by-test partitions of state to verify correctness and robustness of the code. There are about 60 of those that run concurrently with the unit tests and the whole thing closes in 10 seconds.

Docs for elixir are pretty, too: here's a library that I wrote. The doc system is extensible enough that I could patch in docstrings from another language and also hyperlink (the </> buttons link to github) the GitHub code across languages (the `zig structs` section in the sidebar is autogenerated by parsing zig code) https://hexdocs.pm/zigler/Zigler.html

My joke is that you want to write documentation that's pretty and html-responsive enough that you can read it on the can between coding sprints.

> With Go you have much more limited ability to mock things, so there are added constraints for code to be testable.

I agree Go makes things more difficult to mock, but it's also the language I've used where it's easiest to avoid mocks and test the real thing. We have tests for REST and RPC services that... just make a service. There's relatively little boilerplate to make a gRPC or HTTP service with some basic expectations/fake data attached and just run your real client against that real fake server. ("Relatively" meaning, less than the equivalent mocks in Java, for a substantially more realistic test outcome.) And once you have this fake server, it's probably useful in multiple projects, while mock setup tends to be suite- or even case-specific.

Reply on news.ycombinator.com