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

Deno 1.10 Release Notes

deno.com

Post reply on HN
Print view View original

71–80 of 157 posts

Re: Deno 1.10 Release Notes

#71

Post by jmull »

Cthulhu_ wrote: post #17
otabdeveloper4 wrote: post #5

Earlier quoted context omitted.

V8 is written in C++, not Rust.

I'm pretty confident we'll see a JS engine written in Rust at some point in the future, it'll just take a very long time to get parity with V8 and will likely introduce its own slew of issues.

I don't know about a JS engine written in Rust. Well, I'm sure it will be attempted (no doubt it's being done right now), but I don't see a path to success.

Like you say, it would take a long time for a Rust JS engine to reach parity with V8. But long-running projects need real use-cases to succeed... they drive support and provide direction/feedback. How much will a half-baked Rust JS engine be adopted when a mature, stable V8 or SM is available? Will the projects that do so be successful themselves? A pure Rust JS engine might be destined to peter-out well before becoming viable.

A better approach (though less satisfying) might be to convert an existing engine incrementally. But even there, there probably needs to be continuous, compelling benefits along the way to justify the increased complexity and large amount of additional work. Imagine release after release where the main item in the release notes is "rewrote another subsystem in Rust"... followed by a bunch of bugs in the previously stable subsystem. I know SM has some Rust bits, but I'm not sure how far that is really going to go.

Re: Deno 1.10 Release Notes

#72

Post by runarberg »

hackerbrother wrote: post #55
echopom wrote: post #8

Still not tempted by Deno to be honest. All the problem that currently exist in Node are being ported to Deno straight up. The built-in apis provided by Node.JS are almost non-existent... hence most of them are buggy and quiet tedious to use , it's why the community has created thousands of packages to resolve those issues. Here I don't see how Deno is solving this , all the APIS seems again so barebone.. instead of…

It might catch on, it might not. Not everyone has to like it. I personally do like it a lot. I think of it as Node.JS with a better organized core (with the benefit of hindsight), use of browser APIs whenever possible, and built in Typescript. I think it might catch on once we have some mature MySQL, Express.js, etc libraries. I know seeing popular tools be rewritten from scratch is tiresome, but I don't think it's u…

> use of browser APIs whenever possible

Correct me if I’m wrong, but isn’t Node.js aligning more and more with the browser APIs. For example if you `import { URL } from 'url'` you get the WHATWG standard URL object (it is also available as a global object). Node.js now has EventTarget and event listeners aligned with the DOM Event API. `crypto` is now a global object with the same API as the Web Crypto API. You have ArrayBuffer and Blob in Node.js just like in the browser.

What is it that Deno is doing differently then node here?

Re: Deno 1.10 Release Notes

#73

Post by Macha »

caspervonb wrote: post #54

Uhm, so this submission was edited and renamed to Deno 1.1, but this is release version 1.10 as in version one dot ten.

For context, this 11-month old github release https://github.com/denoland/deno/releases/tag/v1.1.0> is the Deno 1.1 release notes, not the linked post here which is for the 1.10 release notes.

Re: Deno 1.10 Release Notes

#74

Post by osrec »

whalesalad wrote: post #70
caspervonb wrote: post #54

Uhm, so this submission was edited and renamed to Deno 1.1, but this is release version 1.10 as in version one dot ten.

Isn’t that the normal behavior of JavaScript numbers? Just do your own thing sometimes? Heh.

While it may be, in this case, we're dealing with strings.

Re: Deno 1.10 Release Notes

#75

Post by klibertp »

polytely wrote: post #37
nesarkvechnep wrote: post #27

Earlier quoted context omitted.

Try Elixir and thank me later.

Elixir's standard library is so pleasant to use. Coming from the JavaScript world it is such a breath of fresh air,

Elixir's stdlib is great. It's small, based on a just a handful of concepts, but thanks to how powerful the concepts are it covers a lot of use cases. Every module contains pretty much everything you'd ever need to work with the concept that module implements, be it a String, an Enumerable, a Stream, or anything else in the stdlib.

But, Elixir is cheating. It can stay clean and compact in part because it sits on top of 30 years of development of Erlang stdlib. Erlang stdlib is messy, spread across multiple applications and modules, with module interfaces inconsistent with each other, not to mention parts of it still include compatibility layers for Erlang/OTP version so old that they didn't have lambdas yet. But, the functionality is there, which enables Elixir to have a small, focused stdlib - because when something is missing, you can just grab an Erlang equivalent.

This is similar to what Clojure does on the JVM. JS doesn't have the luxury of sitting on top of a battle tested stdlib, and trying to cover all the functionality of such stdlib is what results in incomplete and unstable APIs and reliance on so many external packages.

Re: Deno 1.10 Release Notes

#76

Post by BenoitEssiambre »

golergka wrote: post #48
echopom wrote: post #8

Still not tempted by Deno to be honest. All the problem that currently exist in Node are being ported to Deno straight up. The built-in apis provided by Node.JS are almost non-existent... hence most of them are buggy and quiet tedious to use , it's why the community has created thousands of packages to resolve those issues. Here I don't see how Deno is solving this , all the APIS seems again so barebone.. instead of…

> 1000+ dependency from NPM I've been working with Node in hobby projects since around 2012, been paid for it since 2016, and still don't understand why is that such a problem. Compared to other language ecosystems, each of those dependencies is smaller and more atomic. If anything, it's closer to the "unix way" of small tools that do one thing and doing it well, rather then developing huge mega-libraries. Since thes…

At least if they would have cleaned up the unnecessary promises from the async/await implementation: https://es.discourse.group/t/callback-based-simplified-async...

Re: Deno 1.10 Release Notes

#77

Post by runarberg »

1_player wrote: post #69
ranguna wrote: post #34

Earlier quoted context omitted.

I personally like to have a few dependencies in my projects and a simple runtime vs having a monster of a language with a huge amount a unrelated and specialised APIs (java) and still need to install some additional dependencies. I think the barebone nature of nodejs and javascript is what makes it great. If you don't like it, don't use it, there are other languages and runtimes out there and node is a really good fi…

I don't. I'd rather trust the tens of thousands of developers working on the core language and core stdlib, than on a dependency some random guy in Albania maintains on his spare time. Or in the case of the JS ecosystem, you might only use established dependencies, which in turn use dozens more which in turn use dozens more, and the probability that there's a dependency some random guy in Albania maintains very quick…

If you have a problem with library written and maintained by a random guy in Albania you have the option of not using it. If a functionality is so niche that you can only find one fit in the entire npm ecosystem, I doubt this functionality will ever make it to the standard lib of a non-node runtimes.

Personally I like dependencies written and maintained by a random guy in Albania on their spare times. And I would use it when making fun stuff at home. I might even open an issue or a pull request. Dealing with a random guy in Albania sounds way more fun then dealing with a language committee in Silicon Valley.

Re: Deno 1.10 Release Notes

#79

Post by tannhaeuser »

Octoth0rpe wrote: post #62
tannhaeuser wrote: post #36

Earlier quoted context omitted.

Excuse me, but what's this "bad ecosystem in npm" you're talking about? Every single JS lib, pipeline tool, framework is on npmjs.com (react, webpack, bootstrap, expressjs, and 100'000s others). It's the ecosystem that every contender would love to be. And the lack of a "stdlib" is exactly how and why npm started over ten years ago, via the community-driven CommonJs initiative (JSCI, connect/express.js, the package.j…

> Every single JS lib, pipeline tool, framework is on npmjs.com (react, webpack, bootstrap, expressjs, and 100'000s others). It's the ecosystem that every contender would love to be. This is only a strength if you accept that those libs (and their dependencies, and their dependencies' dependencies, and so on...) are adequately scanned for malicious behavior. If you don't accept that, then the incredibly deep dependen…

While that's true, this is really orthogonal to the argument. Especially since Deno's API is also anemic, as complained about elsewhere in this thread.

Re: Deno 1.10 Release Notes

#80

Post by sam_goody »

Node is amazing, but it was Electron that really made Node something that every school kid had to learn.

As long as Electron has no plans to support Deno, it will be WAY behind in traction.

/useless prediction

Post reply on HN