9 ms·

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

18 points by baccheion 11y ago

squiguy7 11y ago
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.
setra 11y ago
Haskell, and Rust tend to be pretty safe.
mtmail 11y ago
The relatively new http://elm-lang.org/ http://elm-lang.org/ (https://en.wikipedia.org/wiki/Elm_%28programming_language%29 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.
- brianwawok 11y ago
  Hah way to beat the system. No runtime error doesn't make sense. Say your database crashes. Something should happen...
  - codygman 11y ago
    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.
  - mmij 11y ago
    Presumably they'd use a Result type, which is just another value.
  - mtmail 11y ago
    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.
  - deadfoxygrandpa 11y ago
    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.
    - brianwawok 11y ago
      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 ;)
- deadfoxygrandpa 11y ago
  Really? I just tried dividing by 0 and it gave me Infinity, not a runtime error.
- twoquestions 11y ago
  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.
codygman 11y ago
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.
WizardlySquid 11y ago
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.
- stonemetal 11y ago
  >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.
  - AnimalMuppet 11y ago
    > >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.
- thrownear 11y ago
  What all languages have you worked with?
bbcbasic 11y ago
Coq. Mathematical proof it works then generates the Haskell. Not exactly a rapid application development tool though.
drallison 11y ago
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.
hacknat 11y ago
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.
dreamdu5t 11y ago
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 http://www.purescript.org and build React UIs using http://alexmingoia.github.io/purescript-pux http://alexmingoia.github.io/purescript-pux
bjourne 11y ago
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/ 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.

18 points by baccheion 11y ago

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.

setra 11y ago

Haskell, and Rust tend to be pretty safe.

mtmail 11y ago

The relatively new http://elm-lang.org/ http://elm-lang.org/ (https://en.wikipedia.org/wiki/Elm_%28programming_language%29 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.

brianwawok 11y ago
Hah way to beat the system. No runtime error doesn't make sense. Say your database crashes. Something should happen...
- codygman 11y ago
  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.
- mmij 11y ago
  Presumably they'd use a Result type, which is just another value.
- mtmail 11y ago
  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.
- deadfoxygrandpa 11y ago
  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.
  - brianwawok 11y ago
    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 ;)
deadfoxygrandpa 11y ago
Really? I just tried dividing by 0 and it gave me Infinity, not a runtime error.
twoquestions 11y ago
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.

codygman 11y ago

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.

WizardlySquid 11y ago

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.

stonemetal 11y ago
>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.
- AnimalMuppet 11y ago
  > >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.
thrownear 11y ago
What all languages have you worked with?

bbcbasic 11y ago

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

drallison 11y ago

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.

hacknat 11y ago

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.

dreamdu5t 11y ago

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 http://www.purescript.org and build React UIs using http://alexmingoia.github.io/purescript-pux http://alexmingoia.github.io/purescript-pux

bjourne 11y ago

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/ 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.