> Even though JavaScript is a weakly typed language it doesn’t mean that it is inherently insecure. Yes, the programming language used plays an important role, but at the end of the day it is the developers obligation to write secure code in the first place.
Sorry, but I just don't agree. Javascript is a popular language, and has an important role to play in frontend development, but for financial transactions and critical contract code, the lack of safety almost guarantees catastrophic bugs and vulnerabilities will be made in production code. Maybe this is fine for hobby projects, but if you are talking about moving billions of dollars around in the real global economy, I don't see it being done safely in Javascript. I like that projects such as Tezos are integrating formal verification of smart contract code, that seems like the right way forward.
Not just that. One thing that worries me a lot about JS in this context is numbers: JS was designed to make it easy to use numbers and convert to/from strings without caring about the precision and exact internal representation. Which is perfectly fine for UI code and the like, but a terrible idea when you're transacting money.
I have good news for you! There's a BigInt proposal [0], and it's already in stage 3 of the process. Now they're asking for feedback and waiting for implementations.
Well, there are plenty of number libraries like BN.js that univocally convert from/to buffers and have unlimited precision. Numbers are the least of my worries with JS security code.
The point is that you have to know you need to use those libraries to have exact computations. Lisk chose javascript to make dapps available to the masses. How many javascript programmers do you think even know what a number on a computer really is? The risks of summing floats? Etc. etc.
I'm one of probably the larger JS fans, and even love working with NodeJS (don't shoot me please) -- but I totally agree with you. I would certainly not trust myself, I really wouldn't trust somebody else trying the same.
I don't see a huge problem using some JS blockchain library for some non-critical application if it somehow added to the end product, but something so highly critical... no thanks.
Except for the part about Tezos. I haven't looked into it.
Sorry, but I just don't agree. Javascript is a popular language, and has an important role to play in frontend development, but for financial transactions and critical contract code, the lack of safety almost guarantees catastrophic bugs and vulnerabilities will be made in production code. Maybe this is fine for hobby projects, but if you are talking about moving billions of dollars around in the real global economy, I don't see it being done safely in Javascript. I like that projects such as Tezos are integrating formal verification of smart contract code, that seems like the right way forward.