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

131–140 of 151 posts

Re: What the Hell Is a Deno?

#131

Post by brabel »

hombre_fatal wrote: post #117
brabel wrote: post #115

Earlier quoted context omitted.

If you think async/await is the holy grail of networking, you're up for a surprise in the next few years. The problem with async/await: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y... A solution proposed by none other than Java (available as an experimental feature in JDK 15): http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.h... This seems to me to obsolete async/await, quite honestly.

Don't fall into the trap of thinking that just because you've found a blog post that could enumerate the downsides of something that the alternatives don't have the same trade-offs. I've responded to that ancient blog post many times on HN by now. Since you must think that blog post is pretty good criticism of async/await, here's a little challenge for you: which language do you think doesn't have an equivalent of th…

> Don't fall into the trap of thinking that just because you've found a blog post that could enumerate the downsides of something that the alternatives don't have the same trade-offs.

I've been using async/await for a long time and I thought it was great, but since I started using JDK15 virtual Threads, I feel like it's way superior in every way. If you have some trade offs you would like to mention, please do.

> which language do you think doesn't have an equivalent of the "red vs blue" problem?

Any language that distinguishes between async and non-async functions will have this problem. I believe one language that works around that is Erlang, as Erlang seems to do everything async (but it's not visible to users, but I am not sure). The proposed Java virtual Threads solve that problem as well. You should open your mind to new ways of doing things, this is by no way a solved problem as you so strongly seem to believe.

Re: What the Hell Is a Deno?

#132

Post by brabel »

osrec wrote: post #16

I like the concept of Deno, and especially love the shift away from NPM. NPM was probably the main reason I never fully embraced node.js. I truly hated the bloat of the modules folder, and the impending fragility the dependencies would bring. I like the idea of a standard library. This will hopefully only improve with time. It sort of brings the ease of use factor of PHP to a server side JavaScript environment. I'll…

Deno is great ! It makes it possible for us to write TypeScript and execute it really fast, without a build system to worry about!

The only thing that, to me, is a big problem, is that, even though you have types in your TS code, you're basically throwing them away at runtime, wasting huge opportunities for optimisation that even the V8 can't recover. If V8 had support for strictly typed TS code, can you imagine how fast it could get it to run?! I think that's the next stage in the evolution of JavaScript/Node/Deno: Node -> Deno -> Done.

Re: What the Hell Is a Deno?

#133

Post by osrec »

brabel wrote: post #132
osrec wrote: post #16

I like the concept of Deno, and especially love the shift away from NPM. NPM was probably the main reason I never fully embraced node.js. I truly hated the bloat of the modules folder, and the impending fragility the dependencies would bring. I like the idea of a standard library. This will hopefully only improve with time. It sort of brings the ease of use factor of PHP to a server side JavaScript environment. I'll…

Deno is great ! It makes it possible for us to write TypeScript and execute it really fast, without a build system to worry about! The only thing that, to me, is a big problem, is that, even though you have types in your TS code, you're basically throwing them away at runtime, wasting huge opportunities for optimisation that even the V8 can't recover. If V8 had support for strictly typed TS code, can you imagine how…

I'm no expert on compilers/interpreters, but wouldn't the added overhead of type checking cause things to slow down (genuine question)?

Re: What the Hell Is a Deno?

#134

Post by jdlshore »

brabel wrote: post #115
hombre_fatal wrote: post #24

Earlier quoted context omitted.

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.

If you think async/await is the holy grail of networking, you're up for a surprise in the next few years. The problem with async/await: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y... A solution proposed by none other than Java (available as an experimental feature in JDK 15): http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.h... This seems to me to obsolete async/await, quite honestly.

I skimmed the Loom article and I don't see how it obsoletes async/await. It seems primarily focused on performance.

But that's not the problem that async/await solves for me. I like JS concurrency because shared-memory concurrency is very hard to program correctly. By using a single-threaded event loop with async/await, I know exactly when it's possible for the contents of memory to change out from under me: only when I `await`. This makes it much easier for me to reason about the correctness of my application.

Given that Node.js makes it easy to spin up processes on multiple cores (e.g., with a library like worker-farm), I get full CPU utilization without the safety and liveness problems that shared-memory threads have. This is very nice.

Re: What the Hell Is a Deno?

#135

Post by WorldMaker »

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…

Deno's existence is partly based on the idea that Typescript would need to be a first class citizen in whatever Node's successor will be.

Re: What the Hell Is a Deno?

#136

Post by thelazydogsback »

hombre_fatal wrote: post #106
thelazydogsback wrote: post #28

Earlier quoted context omitted.

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…

I'm not being unfair when I enumerate the most popular languages for comparison. When people crap on Javascript, they presumably prefer another language. And C#/Kotlin aren't exactly the top picks. Kotlin has BYOB coroutines which are hard to work with. People don't use them. Going with the C# approach where async behavior looks sync was a bad move. I predict Kotlin's coroutines will never be a centerpiece abstractio…

Re:Kotlin, I'm not a JVM expert/fan, so I'll take your word for that. As for the lower-level coroutining, isn't the point that this will allow you/library-writers to abstract over these and provide the higher-level abstractions that you want to use?

Regarding "C# approach where async behavior looks sync", I don't follow you here. C# is very explict with async's returning Task where with Go's lack of "colored" fns, for example, you don't really know when you code is async or not.

Re: What the Hell Is a Deno?

#137

Post by thelazydogsback »

tannhaeuser wrote: post #62
thelazydogsback wrote: post #28

Earlier quoted context omitted.

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…

Well the async/evented execution model, and omitting synchronize, complex "happens-before" semantics, and shared memory a la Java (which JavaScript and V8 lacks) is the entire point of node.js and libuv. I agree that it doesn't fit typical complex business logic with expectations of some level of isolation, but then node.js isn't a good fit for these kind of problems. Node.js is based on CommonJS, and there are/were…

> Complaining about this on node.js is complaining about your own decision to use node.js really

Yes - but there isn't much choice in the mainstream. Sure, I'd rather use .net core/Kestral, but if you want back-end JS/TS then Node is it, unless your org let's you experiment w/Deno or other.

Re: What the Hell Is a Deno?

#138

Post by sholladay »

bufferoverflow wrote: post #121
sholladay wrote: post #66

I am the author of Pogo, a web server framework for Deno that has friendly APIs and is secure by default. It supports React out of the box and has the best documentation of all the frameworks. GitHub: https://github.com/sholladay/pogo Video tutorial: https://www.youtube.com/watch?v=Fe4XdAiqaxI

> "and is secure by default" Extraordinary claims require extraordinary evidence.

I think you misunderstood me. I simply meant that the default configuration optimizes for security. For example, Deno and other frameworks listen on `0.0.0.0` by default, which is convenient for development but is not worth the security concerns, in my opinion. Instead, Pogo uses `localhost` unless you explicitly override that setting, meaning much less risk of accidentally exposing your server publicly. This is not some revolutionary feature, it's just attention to detail that I think you'll notice cumulatively.

Additionally, I would like to pay for a thorough security review when we have more features and users. I doubt any of the other frameworks will do that as it's extremely rare in OSS. Of course, that means very little until it actually happens. But know that my intention is to deliver the first Deno framework that I would personally feel comfortable using in production.

Re: What the Hell Is a Deno?

#139

Post by sholladay »

AbuAssar wrote: post #85
sholladay wrote: post #66

I am the author of Pogo, a web server framework for Deno that has friendly APIs and is secure by default. It supports React out of the box and has the best documentation of all the frameworks. GitHub: https://github.com/sholladay/pogo Video tutorial: https://www.youtube.com/watch?v=Fe4XdAiqaxI

any plans to support angular out of the box too?

Not at the moment, but I'm open to suggestions. Angular uses some custom syntax, right? Deno supports JSX natively, which makes it easier to support React. Do you know if there is a way to use Angular's syntax in Deno? What would the server need to do to make Angular development more convenient?

Re: What the Hell Is a Deno?

#140

Post by danenania »

rahulete wrote: post #34
danenania wrote: post #6

Deno definitely looks interesting! All the examples I’ve seen so far are using the ‘deno’ command to run .ts or .js scripts. Can it also package standalone binaries like go/rust—-to make a cli tool, for instance? If so, how do permissions work in that scenario? Does the user need to grant permissions on every invocation or is there some way to whitelist a script/binary?

Packaging to standalone executable is being worked on https://github.com/denoland/deno/issues/986

Nice! Will be interesting to see how permissions work in that case.
Post reply on HN