Ask HN: What programming languages produce code most/least prone to bugs? | Hacker News Reader

Ask HN: What programming languages produce code most/least prone to bugs?

18 pointsbaccheion21 comments

The relatively new http://elm-lang.org/ (https://en.wikipedia.org/wiki/Elm_%28programming_language%29) claims "no runtime errors" and the number of compile time checks of variable types and values is really strict/amazing/well-documented.

That said I tried diving a value by 0 and that threw a runtime error.

Hah way to beat the system.

No runtime error doesn't make sense. Say your database crashes. Something should happen...

It shields you from a lot. For example if you create an array x of size 100 and in some other piece of code you write x[101] it throws a compile-time error and the error is human readable and explains what's wrong. It's a good approach overall.

I think it's better communicated as "compile-time guarantees that no runtime errors are unaccounted for".

Though, that effectively means no runtime errors depending on your definition of runtime error.

Well, in Elm you would have to explicitly handle the possiblity of a database crash and what to do with it. It wouldn't be a runtime error, it would just be another code path.

So that was the promise of checked exceptions in Java, and it was TERRIBLE. It turned into

try { } catch Exception ex { //won't happen }

I am sure elm does better, but at first glance it scares me ;)

Presumably they'd use a Result type, which is just another value.

Really? I just tried dividing by 0 and it gave me Infinity, not a runtime error.

Is Elm being actively worked on anymore? The last blog post was November of last year, and if my reading of Github is correct the last compiler update was February.

Also, builtwithelm.co is broken.

Languages such as Haskell which move more logic into the type system are safer.

A big reason for this is that the errors are more often than not at compile time.

I'm the real world this means you deal with a bug after trying to compile, rather than an intern 8 months later trying to fix a runtime error, who is struggling to understand the codebase, much less make a good bugfix that also takes backwards compatibility into account.

This is an extremely loaded question. With that being said I think it's obvious that any languages with weak typing and a dynamic runtime will be more prone to hidden errors. Compilers are getting much more impressive in how they can catch common errors for static languages.

So those languages that try and protect the programmer the most will generally produce better code.

Essentially every language claims to be that one. Python, Haskell, Scheme, Java, Erlang, Rust .. There is no true answer yet.

MY answer though is Factor (http://factorcode.org/). Why? Because the length of the source code is about half the length of the equivalent program in Python or Scheme. And I'm absolutely sure (although it is an unproven belief) that the shorter the code, the less bugs there will be hiding in it.

WizardlySquid's comment below was greyed out, probably in error. I have fetched it out of limbo because the point being made is cogent and important.

WizardlySquid 1 hour ago [dead]

Languages don't create bug, people create bugs and there will always be bugs. Instead of looking for the new hotness just study your chosen language more, carefully research your problem, spend more time designing your system to be fault more tolerant and test the system to find the bugs you do have. If we're talking only about languages introducing bugs it's best to have a mature language that works best for your problem and that you are proficient at.

I agree. Programming languages are tools. They help structure problem solving. They provide convenient notations. They have hidden gotchas (sometimes). Some languages may be a better match to a particular problem than another. Programming languages are not a substitute for thought, careful design, and analysis. Language flame wars, endless comparisons, strong assertions of language goodness, and anecdotal tales of greatness are fun to read, sometimes provocative, but in the end remain (for me) unconvincing.

Haskell, and Rust tend to be pretty safe.

I'm surprised Rust hasn't been mentioned. Its borrower memory management pattern, and its requirement of declared mutability prevent most of the most severe security bugs that C, et al, fall prey to.

>Languages don't create bug

No but they allow certain classes of bugs to be written.

>people create bugs and there will always be bugs.

To true, but I take that to a completely different place. Some languages require super human amounts effort to avoid bugs that are easily machine checkable, or the language could offer tools that don't even make such situations possible. Picking a safer language allows you to spend some of your bug avoidance effort in a more profitable way.

> >Languages don't create bug

> No but they allow certain classes of bugs to be written.

True. And, for some categories of bugs, there are other languages that do not allow those categories of bugs to be written. But be careful not to read too much into that. Those languages may also allow other categories of bugs to be written, or to be written more easily.

Do not assume that avoiding the previous generation of bugs means that your code is safe.

What all languages have you worked with?

Coq. Mathematical proof it works then generates the Haskell. Not exactly a rapid application development tool though.

Try PureScript! It's type-checked and purely functional (no crashes or runtime errors) and compiles to JavaScript. You can use it reasily with webpack too. I'm using it in production and it's amazing. Check out http://www.purescript.org and build React UIs using http://alexmingoia.github.io/purescript-pux

Reply on news.ycombinator.com