4 ms·

I think I disagree. I think its ok to make the 1% use case require extra work to debug (it was probably hard anyways) rather than making the 99% pay a tax on ev

I think I disagree. I think its ok to make the 1% use case require extra work to debug (it was probably hard anyways) rather than making the 99% pay a tax on every use of the API to save them. But this is perhaps also where the question becomes more of a question of values and use cases than something generalizable. I don't think Go is the ideal language for writing code that demandingly low-level.

Yoric 5y ago
Interesting. I come from the opposite point of view, i.e. that surprising behavior should be avoided like the plague, using combinations of type-checking or linting or dynamic detection (in debug builds). I wonder why our points of view on this are so different. May I ask what your background is? Perhaps you come from more dynamic languages than I do? Until a few years ago, I used to write C++ and JavaScript for a living and OCaml for fun.
- philosopher1234 5y ago
  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

Interesting. I come from the opposite point of view, i.e. that surprising behavior should be avoided like the plague, using combinations of type-checking or linting or dynamic detection (in debug builds). I wonder why our points of view on this are so different. May I ask what your background is? Perhaps you come from more dynamic languages than I do? Until a few years ago, I used to write C++ and JavaScript for a living and OCaml for fun.

philosopher1234 5y ago
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.