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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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
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.
21 comments
[ 3.5 ms ] story [ 65.1 ms ] threadSo those languages that try and protect the programmer the most will generally produce better code.
That said I tried diving a value by 0 and that threw a runtime error.
No runtime error doesn't make sense. Say your database crashes. Something should happen...
Though, that effectively means no runtime errors depending on your definition of runtime error.
try { } catch Exception ex { //won't happen }
I am sure elm does better, but at first glance it scares me ;)
Also, builtwithelm.co is broken.
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.
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.
> 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.
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.
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.