Hacker News Reader

Comment by bugfix-66 | Hacker News Reader

For example, I work at a company (a company you hear about daily here on Hacker News) that has a compiler generating linear algebra kernels.

The compiler is a huge assemblage of C++ templates, stitched together with a little Python.

The generated code is in an assembly language for a highly parallel machine, and needs to be heavily optimized down to the cycle.

But the compiler itself does NOT need to be so minutely tuned. It needs to be maintainable and it needs to allow easy development of complex code generators.

Go would be a great choice for the compiler.

Instead, we struggle with C++ templates, CMake'ing our code slowly and with absurd complexity, modifying the compiler slowly and with great difficulty...

View on HN

Honestly, it sounds like C++ is just a poor choice for this project, since you are not so interested in performance and you are a lot more interested in developer speed. It is not an example as to why Go is a good replacement for C++ in almost every project. This is a case where you could replace C++ with any business-logic-oriented programming language and you would be happier. It just so happens that your language of choice is Go (and presumably the tech lead's language of choice is C++ for some unknowable reason).

Also, you should not discount compiler speed completely. You, yourself, were upset at the speed of a compile process. All of your users are going to be waiting to get things done while the compiler is running, so you might want to do some math as to how much a 10% slowdown would cost in developer salaries. The makers of gcc, LLVM, and clang spend a lot of effort on improving the speed of their compiler to make sure that you have minimal time waste.

Honestly Go would be a bad choice as well, wouldn't it? It's not like it has much in the way of abstractions.

Sounds like you have a code-quality problem more than a language problem. In that situation, switching languages probably would not help you much.

Get a handle on your code quality, and put the language features to work to solve problems for you. Then Go will increasingly look pitifully inadequate.

I've read all of your comments and I commend you trying to illuminate these people. Some of them seem to be living in the 1990s, spewing the usual hocuspocus about programming languages, the kind of thing you hear once and it becomes a myth. It's like people don't want to reevaluate their choices, and it's insane we keep using this god-forsaken language when we have much better tooling, as you said.

Reply on news.ycombinator.com