Someone who thinks all bugs will go away if the code is just rewritten in the hipster niche language de-jour, is probably a 0.1x developer. They may work hard but don't solve any real problems for the business and leave a mess to future maintainers who have to spend time debugging the forgotten hipster languages of yesteryear.

Do you think the developers who rewrote everything in Dart or CoffeeScript a few years ago were actual 10x productive for the business in the long run?

They specifically said runtime errors. Elm is designed in such a way that runtime errors do not occur. Obviously logic errors etc. are still possible.

So what happens if you divide by 0 in Elm?

For integer division, you get 0 as a result. For floats, it is the Infinity value used by standard implementations.

The integer solution is not great, but is mathematically consistent despite what many believe (it’s true in most proof assistants, for example).

You claim something is "hipster" without having any clue whats it about. May I say the word hipster means nothing. It could mean popular: but Elm is not popular.

Maybe time to study some of that "hipster stuff".

I'd say Elm was very interesting to learn. I gained some programming wisdom from writing stuff in Elm (and in a previous experiment, Haskell).

I'm not knocking Elm at all, I think it is a very interesting language.

I'm saying it is not very productive to rewrite a buggy and brittle JavaScript app in another language because you think that will make the errors go away.

A productive developer would figure out why the code is buggy and brittle and fix the root cause. If you don't understand the root cause, the same or similar bugs will surely show up in a rewrite.

If you do the rewrite as a learning exercise or CV building, great for you! But probably not for the business.

It’s just an objective fact that an Elm rewrite eliminates all runtime errors. Turing complete languages aren’t required to have ways of panicking at runtime, it’s a choice language designers make.

No. Exceptions and errors are different things. An error is when something goes wrong due to a bug or unexpected condition. An exception is a signal in the runtime when an error condition have been detected. If an error does not generate a signal (like an exception or panic) then we call it an logical error. Logical errors are generally worse than errors which cause exceptions, since they may go undiscovered longer and are harder to debug.

Take divide by zero. Dividing by zero is an error so there must be a bug or insufficient validation in the code if it happens. Some languages throw an exception if you divide by zero. You immediately know where something went wrong, and the program does not continue with invalid data.

JavaScript does not throw an error but returns Infinity. So you don't discover the bug immediately, but at least the final output will be clearly invalid since arithmetic operations on Infinity will yield Infinity or NaN.

Apparently in Elm, dividing an integer by zero results in zero. So not only will the program continue with invalid data, it will not even be clear that the result is invalid. The error is still there, but instead of a runtime exception you have an extremely insidious logical error which you might never know is there.

Lets say you have a banking app and the user can take out a loan. The user select the size of loan and the number of months for paying back, and the app calculate the monthly installments by division. But you forgot to validate the input to disallow 0! So the user selects 0 months. A Python app would throw an exception here. Unfortunate, but no harm done. The JavaScript app will state installments of Infinity size. Unfortunate, but most likely the error will be discovered soon. It is unlikely to pass through the backed without causing a crash or validation error somewhere before the database (for example JSON will not allow Infinity).

But Elm will happily give the user 0 installments of $0, in other words a free loan. Nobody notices anything is wrong until you realize you are bankrupt.

Bottom line: Converting runtime exceptions to logical errors is a very bad trade.

I'm a great fan of static typing by the way. But it is important to understand that it does not prevent logical errors, only pretty trivial typos and type-mismatch errors which you will discover in unit testing anyway.

I'm not knocking Elm in particular here, just pointing out that believing Elm (or any language really) can eliminate all runtime errors is very dangerous thinking.

Mistreating division by zero is a logical error as you say, not a runtime error. No one has made any claims in this thread about logical errors, other than my earlier statement that Elm does not preclude them. The things which have been referred to as runtime errors for decades are not present in Elm, that’s really the only point here. In order to make that guarantee, there’s a couple of potholes where logical errors may crop up, it’s a worthwhile trade to many people.

Runtime errors means errors which occurs at runtime as opposed to compile time. Logical errors are a subset of runtime errors. Se for example https://en.wikipedia.org/wiki/Runtime_(program_lifecycle_pha...

This is the common definition.

Defining runtime errors as just being exceptions is clearly absurd - that would mean languages like C or assembler cannot have runtime errors!

To be fair, the grandparent said 'runtime errors', not 'bugs'. And it is a stated goal of the Elm language that runtime exceptions thrown from the compiled Javascript should be impossible. As far as I know, they have succeeded in that goal.

How this relates to 10x or not I don't know - I'm not sure the discussion is a productive one without further context.

It might be that for some tasks, Elm really does provide a huge benefit in productivity. In that case, it's probably fair to call a developer that selects and uses the tool correctly a 10x developer - provided they are able to evolve the culture of their company so that others can take advantage of it.

For other tasks, or in other contexts, Elm might be a hinderance. If it's lacking an indispensable library, or if the company culture is not ready to accept it as a core language, it won't help anyone to rewrite in Elm.

As always, one of the key things that makes a good (even 10x) developer is the ability to select the right tool, and to wield it gracefully.

I'm sure Elm is a great language, but thinking it eliminates runtime errors is ridiculous. Of course it might eliminate exceptions, but exceptions are not errors, rather they are (sometimes) signals than an error have happened.

Yes, this only holds for some definition of errors. Run time program errors due to type mismatch, nulls and exceptions are non-existant.

Pretty cool!

The question is, why was these run time error not caught by unit tests? Probably because there wasn't any tests - which means the code likely have numerous logical errors. Static typing is great, but it will not prevent against logical errors. So without testing you will have bugs in any language you rewrite in.

This is wrong. Rewriting your code in Elm (or other niche language) doesn't make you a 10x developer.

Same way rewriting your code in Rust doesn't make you a 10x developer for removing memory safety issues.

A 10x more productive developer is more productive within an ecosystem against others who are also in that same ecosystem. It's not fair to compare a C developer to a Rust developer in terms of developer skill. But maybe productivity you could. Like how Python is more productive than C++ but you don't call the Python developer a 10x developer.

You did not get my comment. I wanted to say that in choosing lang+tooling is a great place to make the 10x difference.