Live data from Hacker News

Lisk: Blockchain development in JavaScript

blog.lisk.io

41–50 of 110 posts

Re: Lisk: Blockchain development in JavaScript

#41
post #36

Earlier quoted context omitted.

> Security should be your first priority, Do you bother folks writing blockchain implementations in C, which is at least as hard to deliver secure code in? Just curious if you're consistent in your unfair standard or if this is an even more unfair standard than a literal reading of the text.

The problem isn't that they wrote the blockchain in JavaScript, it's that the language they chose for user-written contracts and dapps (out of all the languages in the world, mind you) was JavaScript. Meaning that in the future, if this project really takes off (suspend disbelief here), an entire generation of blockchain apps that transfer money back and forth will be built on JavaScript when they didn't have to be .…

So you prefer the state of affairs with a language with arguably less safety than C _and_ many more amateurish implementation errors?

I wish Etherium had chosen Javascript. It'd have started from a better place.

Re: Lisk: Blockchain development in JavaScript

#42
post #36

Earlier quoted context omitted.

The problem isn't that they wrote the blockchain in JavaScript, it's that the language they chose for user-written contracts and dapps (out of all the languages in the world, mind you) was JavaScript. Meaning that in the future, if this project really takes off (suspend disbelief here), an entire generation of blockchain apps that transfer money back and forth will be built on JavaScript when they didn't have to be .…

So you prefer the state of affairs with a language with arguably less safety than C _and_ many more amateurish implementation errors? I wish Etherium had chosen Javascript. It'd have started from a better place.

I totally agree with you about Solidity.

If you're interested in developing a better language for smart contracts, check out Viper (https://github.com/ethereum/viper). Although development is kind of slow right now because Vitalik is the only one who merges pull requests.

Re: Lisk: Blockchain development in JavaScript

#43
post #42

Earlier quoted context omitted.

So you prefer the state of affairs with a language with arguably less safety than C _and_ many more amateurish implementation errors? I wish Etherium had chosen Javascript. It'd have started from a better place.

I totally agree with you about Solidity. If you're interested in developing a better language for smart contracts, check out Viper ( https://github.com/ethereum/viper ). Although development is kind of slow right now because Vitalik is the only one who merges pull requests.

I'm not sure I trust that team at all.

Quite frankly, I think Etherium is a shameless powergrab by a bunch of folks who's sole positive contribution to the medium is growing it.

It's a tribute to the essentially unskilled & uninformed investors and inventors in many parts of the blockchain ecosystem that Eth has been allowed to grow at all. It's a great idea for the owners of Eth and a terrible idea for everyone, everyone, EVERYONE else (except maybe certain classes of miners).

I've got 0 interest in contributing my time to a system that will only be used to extract wealth from other people's good ideas while simultaneously welding them to a release calendar that keeps them at the back of the pack of blockchain software. If I wanted to pitch in with that, zcash is way more competent anyways.

You don't standardize to a platform at the beginning of a boom. You standardize to protocols. And that is, by the way, exactly what every competent programmer is doing; standardizing on the protocols laid out by bitcoin as they develop their own chains and experiment with new, cheaper ways to sustain a digital currency.

Re: Lisk: Blockchain development in JavaScript

#44
post #12
post #5

Earlier quoted context omitted.

Would you please stop posting unsubstantive comments to HN?

I see what I'd consider "unsubstantive" comments left alone on HN in pretty much every thread, so if you could, please define "unsubstantive".

Moderation works by random sample so it obviously isn't going to be consistent. But if you post like that repeatedly, you're eventually going to get asked not to.

Whatever the definition of unsubstantive is, snarky generic dismissals are certainly included.

Re: Lisk: Blockchain development in JavaScript

#45
post #40
post #36

Earlier quoted context omitted.

The problem isn't that they wrote the blockchain in JavaScript, it's that the language they chose for user-written contracts and dapps (out of all the languages in the world, mind you) was JavaScript. Meaning that in the future, if this project really takes off (suspend disbelief here), an entire generation of blockchain apps that transfer money back and forth will be built on JavaScript when they didn't have to be .…

Paypal, Walmart are doing just fine handling huge amounts of transactions in JS. Majority of security breaches are via targeted emails with attachments and have very little to do with language services are written in.

Not sure what is making everyone upset Paypal is doing 1.7 billion transaction per quarter (100 billion + in volume). 80%+ of breaches at companies are via email as a vector.

Re: Lisk: Blockchain development in JavaScript

#46
post #36

Earlier quoted context omitted.

> Security should be your first priority, Do you bother folks writing blockchain implementations in C, which is at least as hard to deliver secure code in? Just curious if you're consistent in your unfair standard or if this is an even more unfair standard than a literal reading of the text.

The problem isn't that they wrote the blockchain in JavaScript, it's that the language they chose for user-written contracts and dapps (out of all the languages in the world, mind you) was JavaScript. Meaning that in the future, if this project really takes off (suspend disbelief here), an entire generation of blockchain apps that transfer money back and forth will be built on JavaScript when they didn't have to be .…

Maybe it's one of the best ones because it is one of the most accessible programming languages on the planet.

Re: Lisk: Blockchain development in JavaScript

#47
post #36

Earlier quoted context omitted.

The problem isn't that they wrote the blockchain in JavaScript, it's that the language they chose for user-written contracts and dapps (out of all the languages in the world, mind you) was JavaScript. Meaning that in the future, if this project really takes off (suspend disbelief here), an entire generation of blockchain apps that transfer money back and forth will be built on JavaScript when they didn't have to be .…

Maybe it's one of the best ones because it is one of the most accessible programming languages on the planet.

* Most accessible language in the planet -> any script kiddie can write dapps right away without even bothering to study what the risks are and what is happening under the hood

* dapps manage real money in real time

* end users aren't able to evaluate the quality of the dapps they entrust their money to

* what could possibly go wrong?

Re: Lisk: Blockchain development in JavaScript

#48
post #22
post #13

> ...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...We chose JavaScript because it runs literally everywhere, is extremely popular & widespread, and has huge companies like Google or Microsoft working on its s…

I agree. I don't understand why people say things like "You can create bugs and make mistakes in any language." That's not the issue. The issue is how likely someone is to make mistakes in that language, and whether the way the language is designed makes it easier to shoot yourself in the foot.

Please read "The Shocking Truth about static Types" by Eric Elliott, which includes links to studies on bug density by programming language. JavaScript is in the middle of the pack, and programs built on JS are on average less buggy than C++ and Java. https://medium.com/javascript-scene/the-shocking-secret-abou...

Re: Lisk: Blockchain development in JavaScript

#49
post #14
post #9

Earlier quoted context omitted.

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.

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.

Re: Lisk: Blockchain development in JavaScript

#50
post #13

> ...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...We chose JavaScript because it runs literally everywhere, is extremely popular & widespread, and has huge companies like Google or Microsoft working on its s…

why would they not use Typescript and only "eventually move to it". The primary focus of blockchain languages should be safety and security. even something like Facebook's https://github.com/BuckleScript/bucklescript or https://reasonml.github.io/guide/what-and-why would be a great starting point since it is built on top of an Ocaml -> javascript toolchain
Post reply on HN