3 ms·

I write Java for a living. In my opinion the largest source of bugs and general misery is the complexity of our codebase which, in my opinion, is sourced to Jav

I write Java for a living. In my opinion the largest source of bugs and general misery is the complexity of our codebase which, in my opinion, is sourced to Java community philosophies in Clean Code. There is far too much abstraction, and far too much emphasis on making sure code does everything/is flexible as opposed to making sure code does the thing it is meant to do. As a result the amount of the codebase any one can understand is much smaller and people make bandaid fixes rather than deep fixes. Having a shallow deeply understandable code base is crucial in my opinion, and having APIs that are extra complicated and hard to use makes it much harder to use them well/make changes. The book "A Philosophy of Software Design" has been formative for me.

Yoric 5y ago
Yes, that is a common complaint against Enterprise-style Java code. It's funny because when I started Java (shortly before 1.0, iirc), Java was the clean new language on the block and it was so much more readable than just about everything else used in the industry! I understand how go can feel like fresh air after suffering from Enterprise-style Java. In my experience, the largest sources of bugs and general misery in C++ code is that the language is way too complex, that both the language and its libraries are full of footguns, and that debugging these footguns requires heroism and burnouts. In fact, that's almost the same complaint I have against JavaScript, except there is a strong veneer of "don't worry, it's simple". Which is unfortunately a lie, as can be confirmed by anyone who had to read the actual specs of the language. All in all, I favor no-surprises-at-runtime because I have been bitten waaaaay to often by surprising behavior in production despite what felt like comprehensive unit and integration testing. That's in both C++, JS and Python. Hence me being really happy at Rust's guarantees.
azth 5y ago
"Enterprise code" can be written in any language. My employer invented an entire web framework in golang and we routinely see stack traces up to 80 lines or more even. A lot of the need to write such a framework was from golang's shortcomings.

Yoric 5y ago

Yes, that is a common complaint against Enterprise-style Java code. It's funny because when I started Java (shortly before 1.0, iirc), Java was the clean new language on the block and it was so much more readable than just about everything else used in the industry! I understand how go can feel like fresh air after suffering from Enterprise-style Java. In my experience, the largest sources of bugs and general misery in C++ code is that the language is way too complex, that both the language and its libraries are full of footguns, and that debugging these footguns requires heroism and burnouts. In fact, that's almost the same complaint I have against JavaScript, except there is a strong veneer of "don't worry, it's simple". Which is unfortunately a lie, as can be confirmed by anyone who had to read the actual specs of the language. All in all, I favor no-surprises-at-runtime because I have been bitten waaaaay to often by surprising behavior in production despite what felt like comprehensive unit and integration testing. That's in both C++, JS and Python. Hence me being really happy at Rust's guarantees.

azth 5y ago

"Enterprise code" can be written in any language. My employer invented an entire web framework in golang and we routinely see stack traces up to 80 lines or more even. A lot of the need to write such a framework was from golang's shortcomings.