Hacker News Reader

Choosing a language before you even have an app matters. Changing the language your app is already written in or tacking on a microservice so you can use a 2nd language.... not such a good idea. I chose php 8 years ago because I already knew it. Would I write my app in a different language today if I could? Probably. Should I do that now, when I have very few bugs (basically none of which are related to my language choice) and no performance issues? Probably not. Have I been tempted because shiny? Yes. Delivering actual value to customers is what matters and there hasn't been anything I couldn't solve with a bit more PHP. Rewriting the whole app would probably kill my business.

Concentrating on NPEs and stuff like sum times is misunderstanding the problems with software quality to the point of misunderstanding the magnitude of impact of different flaws.

Working tightly with QA for over ten years by now, I can assure you that NPEs are exceptionally rare in bug reports filed by QA. No matter if that's a common problem in the language the application is written in (eg. Java or C++) or virtually nonexistent (eg. Kotlin or Haskell).

Here are some examples of more common bugs:

* Misunderstanding of the desired functionality (eg. giving admin permissions to regular users).

* Not being able to predict all valid input forms (eg. user names with accented characters).

* Forgetting to handle errors coming from multiple levels below the immediate level that's being worked with (eg. dealing with SSL-related problems in HTTP client / server communication).

* Simply forgetting to implement some uncommon bit of functionality (usually related to cleanups, deletion etc.)

----

Currently in-use programming languages have roughly the same ability to deal with these, as I call them, "macro-problems" of programs. All of them are equally ill-equipped and unprepared for them. Tightening the type system or chasing after nulls is working at a resolution that's too fine. At this resolution programmers usually still have a good chance of figuring out the problems without the aid of types or similar automation.

NPE safety and sum times deal with issues that developers face on the day to day, long before the product ever gets used by end users in the first place.

NPE issues are also very very difficult to chase down.

I'm talking about QA, not end-users.

"very very difficult" on what scale? How many "verys" before it gets really hard?

Again, the proof is in the pudding. You take a language that doesn't make any special efforts to protect against nulls (eg. Java), and you take Kotlin that does, and the difference in the number of problems associated with NPEs is barely noticeable.

Perhaps some automation offered by Kotlin for dealing with NPEs makes developers' experience more pleasant / easier, but the Java side just isn't hard enough to make this a substantial benefit.

And, just to not be misunderstood: I'm not saying that automation in how to deal with missing values is bad, not at all! It's good. But, strategically, there are much bigger problems / juicier targets than NPEs. If you compare this to health, then NPEs are a headache, while misunderstood requirements are a cancer. It's great if you can treat both, but if you have limited resources, then cancer gets a priority treatment.

> But if you make the choice of Java (boring) over Kotlin (shiny new), you’re possibly signing up for a curse of chasing NPEs

You are also choosing

-to let your team choose their own IDE

- easy to debug

- frameworks that works out of the box

- and continue to work regardless of Kotlin versions (since one doesn't use Kotlin)

- to no have to deal with a number of "interesting" ways to write code

I like Kotlin. But it is more nuanced than some people would like to have us believe.

Personally I think I have spent far more time over the last three or four years hand holding Kotlin and cleaning up "clean code" than I have saved by less NPEs.

Agreed, also, imo boring implies that failure modes are well understood or at least documented and have a bigger community to rely on when you eventually hit them.

Eh, I would argue Kotlin is solidly boring right alongside Java now. It's still "mostly" Java if you are using it in the same places you can use Java.

I'm with you generally though. Yes choose boring tools, JVM, PostgreSQL, etc. But also write boring code using boring architectures deployed on boring platforms.

Definitely. The only real downside to going with Kotlin nowadays is hiring developers; it's reasonably easy to find Java developers who want to try Kotlin, but hard to hire people experienced in Kotlin.

I think the reason it resonates with people is that a common failure mode in technology is picking the wrong tech for the problem, and this often happens because engineers like to learn and pick things they are unfamiliar with so that they get that buzz. Most of the value in this article can be boiled down to telling engineers to not make tech decisions based on the brainy feelgoods. It's like telling people to eat their vegetables. Boring, straightforward advice, but a good path to a healthier body.

> But if you make the choice of Java (boring) over Kotlin (shiny new), you’re possibly signing up for a curse of chasing NPEs, which Kotlin would have caught at compile-time. Or if you choose C++ over Rust, same general idea.

But isn't the point that if you run into this much issue for the initial choice, you are now ready to use an innovation token and switch to a different one?

> Some semblance of safety needs to be bolted on separately, and at large scale they will cost your company $$$ vs. a more performance-friendly language (the latter doesn’t matter so much if you are a tiny startup with no users yet).

At that point with all the financial resources, they can consider to rewrite/migrate. Thus, at the start, chose boring technology.

Even at a big company, retraining or hiring people proficient in Rust will probably cost more than continuing to use C++ codebase and people.

Interestingly enough, the concern in the early stages is actually not at all about hiring people, it's about personal motivation and technology fit. We dropped C for Rust in a systems language context and technologically it was a fantastic choice. I guess some of the benefits of a language switch could have been realised with C++, but since my proficiency with C++ was a few small incremental changes relative to C, I was going to have to learn a lot in either case. Rust held far more appeal and in hindsight has helped us provided fantastic stability in our software whilst developing very rapidly.

> Interestingly enough, the concern in the early stages is actually not at all about hiring people, it's about personal motivation and technology fit.

Is this in regards to running a startup? In that case, I have little to add. But my initial understanding would be, the startup needs to be able to reach product market-fit as quickly as possible. Which is where using a boring technology (to the founders/founding team) would reduce distractions/unknowns.

> but since my proficiency with C++ was a few small incremental changes relative to C, I was going to have to learn a lot in either case.

Isn't this premise aligned with the philosophy written in the article? 1. You needed to learn something new (so no longer boring, and prime for innovation token) 2. You needed to use something different for a systems language context (innovation token time)

> But if you make the choice of Java (boring) over Kotlin (shiny new)

New doesn't mean exciting. Programming languages are boring – even new ones. If you see a programming language attracting a lot of excitement, beware, but otherwise whatever you're comfortable with will be fine.

Kotlin counts as boring now (imo)