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

21–30 of 157 posts

Re: Deno 1.10 Release Notes

#21

Post by austincheney »

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…

> all the APIS seems again so barebone..

What is an example of something you are hoping for?

Re: Deno 1.10 Release Notes

#22

Post by spamalot159 »

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…

I am trying to expand my horizons from only node to other frameworks. I've seen so much hype around Deno so I looked into it the other day and I feel the same as you. It doesn't seem different enough from Node from a user standpoint. I also agree that the package system seems messy. For right now I'm going to steer clear and get out django and rails.

Re: Deno 1.10 Release Notes

#23

Post by oblio »

cztomsik wrote: post #20
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…

deno is definitely better in the sense that it's way more compatible with browser and I think that's really big thing in the long run (but nodejs could do that too, eventually) regarding 1000+ deps, yes that's a bad thing but it's not really about language, it's rather about people. when node started, usual number of dependencies was low. I know because I was there and I was making fun of maven and how it pulls half…

If the standard library would be richer you'd just ignore half a million of those packages. They'd just die a quiet death.

Re: Deno 1.10 Release Notes

#24

Post by hnbad »

kigiri wrote: post #15
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…

But the bad ecosystem in npm is one of the main reason he made deno, that's what deno/std is for. While not stable yet, they are working to address this very issue Zig is looking great but also, solving a different problem

Deno has passed 1.0. Having the standard library still be "not stable yet" doesn't spark much confidence in me for something meant to replace node.

Re: Deno 1.10 Release Notes

#25

Post by 1_player »

hnbad wrote: post #24
kigiri wrote: post #15

Earlier quoted context omitted.

But the bad ecosystem in npm is one of the main reason he made deno, that's what deno/std is for. While not stable yet, they are working to address this very issue Zig is looking great but also, solving a different problem

Deno has passed 1.0. Having the standard library still be "not stable yet" doesn't spark much confidence in me for something meant to replace node.

Yes, I would have wanted to see a decent stdlib to be a goal for 1.0.

I recently wrote a 10 line script that had to work with date arithmetic *, and while importing URLs is pretty cool, it still was the same shit of spending 80% of the time it took to write the code browsing and evaluating multiple third party date libraries to find one good enough for my use case. So in practice the only improvement Deno had over Node in that example was that I didn't have to run `npm install`. Yay, great.

*: adding two dates together, converting to and from UTC, given a Date find the next midnight. And as expected the most popular JS library couldn't even get one of these simple tasks correct, there's a bug report open since 2017. Incredible stuff from this ecosystem.

Re: Deno 1.10 Release Notes

#26

Post by josephg »

CraigJPerry wrote: post #13
otabdeveloper4 wrote: post #5

Earlier quoted context omitted.

V8 is written in C++, not Rust.

Sure, although the rust v8 bindings don’t appear to support FreeBSD as i just found out when i tried to install deno on FreeBSD 13: > cargo install --locked deno Compiling rusty_v8 v0.22.2 error[E0308]: mismatched types --> /home/craig/.cargo/registry/src/github.com-1ecc6299db9ec823/rusty_v8-0.22.2/build.rs:157:18 | 157 | fn platform() -> &'static str { | -------- ^^^^^^^^^^^^ expected `&str`, found `()` | | | implic…

That looks like a pretty simple problem. Deno probably doesn’t work on FreeBSD simply because nobody has done the work of making it compatible yet. Rust, V8 and nodejs all run great on FreeBSD.

If you care about FreeBSD support, I bet the community would be delighted to receive some pull requests patching the problem.

Re: Deno 1.10 Release Notes

#27

Post by nesarkvechnep »

spamalot159 wrote: post #22
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…

I am trying to expand my horizons from only node to other frameworks. I've seen so much hype around Deno so I looked into it the other day and I feel the same as you. It doesn't seem different enough from Node from a user standpoint. I also agree that the package system seems messy. For right now I'm going to steer clear and get out django and rails.

Try Elixir and thank me later.

Re: Deno 1.10 Release Notes

#28

Post by valtism »

rapsey wrote: post #19
kigiri wrote: post #15

Earlier quoted context omitted.

But the bad ecosystem in npm is one of the main reason he made deno, that's what deno/std is for. While not stable yet, they are working to address this very issue Zig is looking great but also, solving a different problem

Just because they are attempting to address it does not mean they will succeed.

Yes but let’s not get that cynical about it. People are working hard on these problems.

Re: Deno 1.10 Release Notes

#29

Post by dajonker »

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.

Parts of the Firefox JS engine (SpiderMonkey) are written in Rust (although nothing really significant I believe).

Re: Deno 1.10 Release Notes

#30

Post by tehbeard »

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…

What about Deno's API is still so barebone?

Are you comparing Deno to PHP? Should Deno have all the various database drivers baked in? SDKs to call out to Salesforce/Stripe/Zoom? Should I pay a performance penalty for my app because you need to be able to read XML and make SOAP calls and want a tool that does that out of the box? Would you be happy to take a hit if the roles were flipped and I wanted Excel read/write?

I will not say Deno's perfect, I am still concerned/uneasy enough about how the whole dependency tree resolves for complex dependencies and is managed to not want to try it in production right now, but w.r.t to the ecosystem I'd say it's as good if not better than Node's, albeit smaller, given the focus on building a stdlib within this ecosystem for common usecases (http middleware, database drivers, common file formats etc)

> everything set at "read/write" because they need to read one file from your ".env" folder or perform an arbitrary post install process...

the CLI args allow for tighter scoping that, and atleast the topic of sandox by default is being discussed and the painpoints/edge cases are coming to light, rather than the node/npm model of execute as user and done.

Post reply on HN