Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is an argument from edge case capabilities that completely ignores maintenance costs + development time. Seems very naive to me.


Totally agree. If the argument is strictly more power is always better, then C++ would always win. Why doesn't it? Exactly what you reference, dev time and maintenance.

Go was designed for simplicity. Of course it's not the fastest or most feature rich. It's strong suit is that I can pop open any Go codebase and understand what's going on fairly quickly. I went from not knowing any Go to working with it effectively in a large codebase in a couple weeks. Not the case with Java. Not the case with most languages.


That wasn't the argument though, you are attacking a strawman. The argument was much more nuanced if you bothered to read it.

Essentially it boils down to this. If I am writing -systems- software and I'm going to choose between Go or Java then the list of things I pointed out are the main differentiating features along with raw throughput which matters for things like databases which need to be able to do very fast index/bitmap/etc operations.

Go is great for being simple and easy to get going. However that is completely worthless in systems software that requires years of background knowledge to meaningfully contribute to. The startup cost of learning a new codebase (or entirely new programming language) pales in comparison to the requisite background knowledge.


> Go is strictly less useful than Java because it has strictly less power.

Literally sentence one, so calling my argument straw-man is dishonest.

> Essentially it boils down to this. If I am writing -systems- software and I'm going to choose between Go or Java then the list of things I pointed out are the main differentiating features along with raw throughput which matters for things like databases which need to be able to do very fast index/bitmap/etc operations.

All true. In my experience though, the long tail of maintenance and bug fixes tend to result in decreasing performance over time, as well as a slowing of new feature support.

All of that being said, these are all fairly pointless metrics when we can just look at the DBs being adopted and why people are adopting them. Plenty of projects use Go because of Go's strengths, so saying "that is completely worthless in systems software" is verifiably false. It's not worthless in any software, worth less maybe, but not worthless.


It's not. If you are building a database or other "systems" software these are very relevant capabilities.

Also development time of Java may be slightly longer in the early stages but I generally find refactoring of Java projects and shuffling of timelines etc is a ton easier than Go. So I think Java wins out over a longer period of time even if it starts off a bit slower.

It's far from naive. I have written a shitton of Go code (also a shitton of Java if that wasn't already apparent).


You may not personally be naive, but i was talking about your analysis, not you.

>Also development time of Java may be slightly longer in the early stages but I generally find refactoring of Java projects and shuffling of timelines etc is a ton easier than Go. So I think Java wins out over a longer period of time even if it starts off a bit slower.

I think this topic is far too large to be answered in this brief sentence. I also think it deserves a higher allocation of your words than what you spared for java's capabilities :)

But yes, I see now that you are interested purely in performance in your argument and definition of systems software, in which case what you're saying may be true.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: