Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lisk: Blockchain development in JavaScript

blog.lisk.io

Post reply on HN
Print view View original

31–40 of 110 posts

Re: Lisk: Blockchain development in JavaScript

#31

Post by protomikron »

jsnathan wrote: post #26
flunhat wrote: 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'm curious: could any of the recently known smart contract bugs have been prevented through the use of a stricter type system? I tend to think of type systems more as a hindrance myself. I mean, they can certainly help you catch bugs before the code even runs - but which of those bugs would you not catch during the testing phase anyway? I'm genuinely curious: what types of bugs does a stricter type system catch that…

> I'm genuinely curious: what types of bugs does a stricter type system catch that a reasonable test suite probably would not?

Edge cases that you do not hit in your test cases.

One could also argue that a distributed computing platform coupled to a money system may not need to be Turing complete. State-of-the art type systems are capable of proving non-trivial properties of code which could be handy in the crypto world.

Re: Lisk: Blockchain development in JavaScript

#32

Post by kevinmannix »

52-6F-62 wrote: post #20
keypusher wrote: post #2

> 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 cr…

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 pa…

I really don't think liking Node is a cross to bear

Re: Lisk: Blockchain development in JavaScript

#33

Post by syndev »

jsnathan wrote: post #26
flunhat wrote: 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'm curious: could any of the recently known smart contract bugs have been prevented through the use of a stricter type system? I tend to think of type systems more as a hindrance myself. I mean, they can certainly help you catch bugs before the code even runs - but which of those bugs would you not catch during the testing phase anyway? I'm genuinely curious: what types of bugs does a stricter type system catch that…

Sure, that could totally work. Part of the benefit a type system provides is that those checks are provided for you automatically, every time.

Re: Lisk: Blockchain development in JavaScript

#34

Post by kingmanaz »

jsnathan wrote: post #26
flunhat wrote: 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'm curious: could any of the recently known smart contract bugs have been prevented through the use of a stricter type system? I tend to think of type systems more as a hindrance myself. I mean, they can certainly help you catch bugs before the code even runs - but which of those bugs would you not catch during the testing phase anyway? I'm genuinely curious: what types of bugs does a stricter type system catch that…

Assuming stricter typing does prevent smart contract bugs, something like Ada or Spark would seem to be good fit for cryptocurrency development given their track record creating highly-reliable systems:

https://en.wikipedia.org/wiki/SPARK_(programming_language)

That being said, I spent some time with Ada several years ago and did not enjoy the language; very verbose and anal. If the impression is widespread, such a language could end up hurting a blockchain project by drawing less contributors.

Re: Lisk: Blockchain development in JavaScript

#35

Post by KirinDave »

flunhat wrote: 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…

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

Re: Lisk: Blockchain development in JavaScript

#36

Post by flunhat »

KirinDave wrote: post #35
flunhat wrote: 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…

> 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. If they chose C as the language for smart contracts/dapps/whatever I would be ragging on them just the same. They had options, and choose the one of the worst ones.

Re: Lisk: Blockchain development in JavaScript

#37

Post by spraak »

kevinmannix wrote: post #32
52-6F-62 wrote: post #20

Earlier quoted context omitted.

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 pa…

I really don't think liking Node is a cross to bear

Many other people seem to think so... So I assume the poster above (like myself) have encountered that sentiment before

Re: Lisk: Blockchain development in JavaScript

#38

Post by jorblumesea »

> We chose JavaScript because it runs literally everywhere, is extremely popular & widespread, and has huge companies like Google or Microsoft working on its speed and security across a wide range of devices.

What about WASM? Seems like if we're future thinking "things that can run everywhere" just about any language can be compiled into a web assembly target and used. WASM is supported in most major browsers except IE.

Re: Lisk: Blockchain development in JavaScript

#39

Post by latchkey »

> we are planning an eventual transition to TypeScript

Just switch today. That's kind of silly to write a whole bunch of untyped code and then move to types. Especially since you can do it over time with TS.

All these tests that something is a string... why not let a compiler do that for you?

https://github.com/LiskHQ/lisk/blob/development/test/api/acc...

Re: Lisk: Blockchain development in JavaScript

#40

Post by qaq »

flunhat wrote: post #36
KirinDave wrote: post #35

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

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.
Post reply on HN