Live data from Hacker News

Deno 1.10 Release Notes

deno.com

31–40 of 157 posts

Re: Deno 1.10 Release Notes

#31
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…

> Ryan is the kind of guy that gets obsessed over ONE THING and goes berserk for 5 years on that topic until he overdose and quit abruptly.

My problem with that statement is: if you knew him personally it's unlikely you'd have said it. And if you didn't, do you have enough samples to be sure he's 'that kind of guy'?

Or are you extrapolating from N=1?

Re: Deno 1.10 Release Notes

#32
post #19
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.

So what? Should we all give up now and stop doing whatever we're doing now, just because we might not succeed? That's how people learn, advance and improve the world around us - through failure and mistakes.

Re: Deno 1.10 Release Notes

#33
post #19
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.

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

Strongly agree this statement , hence I don't see how switching from "npm" to "raw urls" will solve anything...

The problem with Node dependency is bigger than just "npm is not a good package manager"... Honestly in this case just fork node and replace npm with something else...

Here the problem relies on a mixture between poor built-in apis which are buggy a lack of vision with the language , which have been core to the language since it's origin.;.

Deno doesn't seems to address those at all...

Again it's just seems to be "npm is bad , and i want to use typescript natively with web apis"...

I just know very well that Ryan is redoing exactly the same mistakes as Node with the same obsession he had on "EPOLL"[0] back then that will end up in a new fiasco.

[0]https://youtu.be/M3BM9TB-8yA Can't find the specific part where he mentioned "EPOLL"

Re: Deno 1.10 Release Notes

#34
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 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 fit for a lot of people.

Re: Deno 1.10 Release Notes

#35
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…

> Here I don't see how Deno is solving this , all the APIS seems again so barebone.. instead of having 1000+ dependency from NPM you'll have 1000+ dependency from remote URL

With Deno you can already do a lot with only what is provided by the main executable. Here's a subset of the available subcommands:

    bundle: Bundles JS. While it doesn't do everything that webpack does, it already provides enough to deploy SPAs. 
    coverage/test: Builtin test/coverage framework.
    fmt/lint: Builtin lint/formatter.

IMO these provide basic tools that are likely necessary for any JS project, yet with Node.js you need a few hundred NPM deps to achieve the same functionality.

Not to mention the builtin Typescript compiler. Starting a few of years ago, I don't even consider the possibility of creating a Javascript project without using Typescript as the main language. With Deno you have it builtin.

Re: Deno 1.10 Release Notes

#36
post #15
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

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.json format, middlewares, etc). The idea being that the core packages on npmjs.com are the stdlib on top of what Node.js/CommonJs provides.

Re: Deno 1.10 Release Notes

#37

Earlier quoted context omitted.

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.

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

Re: Deno 1.10 Release Notes

#38

Earlier quoted context omitted.

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.

Even as a long time Erlang user, the rise of node.js was just sad to watch. I understand why it happened, but looking from the outside what kind of nonsense they were doing when there are such better solutions was sad.

Re: Deno 1.10 Release Notes

#39

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 rather imagine we'll see a wasm vm/runtime in rust, and a typescript/js to wasm compiler written in typescript...

Re: Deno 1.10 Release Notes

#40
post #26

Earlier quoted context omitted.

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.

I gave it a whirl:

  > git clone https://github.com/denoland/deno.git denoland/deno
  > git clone https://github.com/denoland/rusty_v8.git denoland/rusty_v8
  > cd denoland/deno
  > vi Cargo.toml

  ...
  [patch.crates-io]
  rusty_v8 = { path = "../rusty_v8" }
  ...

  > cargo build --release
  ... as expected same failure - good ...
Make rusty_v8 build.rs aware of freebsd

  > vi ../rusty_v8/build.rs

  ...
  #[cfg(target_os = "freebsd")]
  {
    "freebsd"
  }
  ...
Have a quick squizz to see where this is used:

  > rg "platform\(\)" ../rusty_v8

  build.rs
  157:fn platform() -> &'static str {
  180:    .join(platform());

Attempt to fix... and bang! It's using the platform() result to call a python script that pulls binaries from here:

https://github.com/denoland/ninja_gn_binaries/

And there's no FreeBSD build there. To much yak shaving for idle curiosity on my part.

Post reply on HN