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

What the Hell Is a Deno?

breadth.substack.com

Post reply on HN
Print view View original

21–30 of 151 posts

Re: What the Hell Is a Deno?

#21

Post by ChristianBundy »

irjustin wrote: post #20

My gripe with npm was the lack of a lock file. - Yarn helped solve that, but because of its backwards compatibility to node_modules, you could not have different versions sitting side-by-side. - Node_modules could have a different version installed vs lock file and no one would know without looking. It seems Deno is able to solve the side-by-side versions and distributing the 'lock' to the file itself. The Deno team…

Does package-lock.json not fill this void? It's been a thing for a few years IIRC.

Re: What the Hell Is a Deno?

#22

Post by fearingreprisal »

For me this is a case of "too little, too late". I've been burned too much over the years by the Node ecosystem to risk investing any further interest in it now, even if it has marginally improved.

I have worked extensively with Typescript, which I consider to be the minimum viable solution within the Node ecosystem. Typescript shouldn't even be seen as a 'nice-to-have. It should be seen as a required remedy for some of the mistakes of a terribly engineered language. Javascript should never have been considered a serious language for back-end development. Node.js to me seems like someone's 'Frankenstein's monster'-esque experiment that escaped its captivity and wreaked wide-scale havoc on the surrounding world.

Re: What the Hell Is a Deno?

#23

Post by osrec »

fearingreprisal wrote: post #22

For me this is a case of "too little, too late". I've been burned too much over the years by the Node ecosystem to risk investing any further interest in it now, even if it has marginally improved. I have worked extensively with Typescript, which I consider to be the minimum viable solution within the Node ecosystem. Typescript shouldn't even be seen as a 'nice-to-have. It should be seen as a required remedy for some…

Terribly engineered because it's not type checked, or for some other reason?

Re: What the Hell Is a Deno?

#24

Post by hombre_fatal »

fearingreprisal wrote: post #22

For me this is a case of "too little, too late". I've been burned too much over the years by the Node ecosystem to risk investing any further interest in it now, even if it has marginally improved. I have worked extensively with Typescript, which I consider to be the minimum viable solution within the Node ecosystem. Typescript shouldn't even be seen as a 'nice-to-have. It should be seen as a required remedy for some…

This doesn't make sense to me.

Javascript is a breath of fresh air after writing async code in almost every other ecosystem from Go to Java to Python to Swift. Pretty much any async code snippet in those languages can be improved by porting it to Javascript.

Async/await + the ubiquitous Promise make it my go-to choice for writing anything networked. Especially over the other popular dynamically typed languages.

Re: What the Hell Is a Deno?

#25

Post by rough-sea »

irjustin wrote: post #20

My gripe with npm was the lack of a lock file. - Yarn helped solve that, but because of its backwards compatibility to node_modules, you could not have different versions sitting side-by-side. - Node_modules could have a different version installed vs lock file and no one would know without looking. It seems Deno is able to solve the side-by-side versions and distributing the 'lock' to the file itself. The Deno team…

https://deno.land/manual/linking_to_external_code/integrity_...

Re: What the Hell Is a Deno?

#27

Post by thawaway1837 »

The security stuff for NodeJS is really frustrating. If anything, NodeJS is more secure than something like the JVM or C++. If I include a 3rd party package in the JVM, I have absolutely no guarantee that it will work well, much like in Node. In fact, in Node, I can actually read the source code and see what the package is, running is doing. In nearly every other environment, you may simply have access to a binary, with maybe some interface info.

So why do people not throw the same kind of fit about nearly every other programming environment as they do for Node/NPM? And frankly why do those other environemnts not have the ridiculous security breaches we have seen in Node/NPM land?

The real problem with Node/NPM i suspect is a lack of a standard library. Simply having a standard library would have greatly reduced dependency and package hell. Further, a standard library would mean people would be more willing to write a little more code rather than include a new dependency.

Re: What the Hell Is a Deno?

#28

Post by thelazydogsback »

hombre_fatal wrote: post #24
fearingreprisal wrote: post #22

For me this is a case of "too little, too late". I've been burned too much over the years by the Node ecosystem to risk investing any further interest in it now, even if it has marginally improved. I have worked extensively with Typescript, which I consider to be the minimum viable solution within the Node ecosystem. Typescript shouldn't even be seen as a 'nice-to-have. It should be seen as a required remedy for some…

This doesn't make sense to me. Javascript is a breath of fresh air after writing async code in almost every other ecosystem from Go to Java to Python to Swift. Pretty much any async code snippet in those languages can be improved by porting it to Javascript. Async/await + the ubiquitous Promise make it my go-to choice for writing anything networked. Especially over the other popular dynamically typed languages.

Well, if so I don't think it was true until recent JS versions. And I'm not sure you're picking very good languages for your async comparison. (Python? yikes.) Long-standing async support in C# or newer support in Kotlin, or almost any language with real co-routines will fair better than JS. As for as promises go, using CPS with or without Promise wrappers seems pretty old hat.

More to the point I think, is that Node (and Deno, FWICT) lack general native or green thread support for true multi-processing without serialization to separate clusters, so you are forced to use async and timers for long-running or parallel work.

Re: What the Hell Is a Deno?

#30

Post by knome »

hombre_fatal wrote: post #24
fearingreprisal wrote: post #22

For me this is a case of "too little, too late". I've been burned too much over the years by the Node ecosystem to risk investing any further interest in it now, even if it has marginally improved. I have worked extensively with Typescript, which I consider to be the minimum viable solution within the Node ecosystem. Typescript shouldn't even be seen as a 'nice-to-have. It should be seen as a required remedy for some…

This doesn't make sense to me. Javascript is a breath of fresh air after writing async code in almost every other ecosystem from Go to Java to Python to Swift. Pretty much any async code snippet in those languages can be improved by porting it to Javascript. Async/await + the ubiquitous Promise make it my go-to choice for writing anything networked. Especially over the other popular dynamically typed languages.

I dislike javascript for much the reason you love it.

Promises just mean having to manually build and manipulate cooperatively multitasking green-threaded call-stacks. It was a dirty necessity following the inability of the earlier callback patterns to manage the level of complexity people were attempting to express in the language.

Post reply on HN