3 ms·

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 i

by kigiri 5y ago

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

rapsey 5y ago
Just because they are attempting to address it does not mean they will succeed.
- HatchedLake721 5y ago
  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.
- valtism 5y ago
  Yes but let’s not get that cynical about it. People are working hard on these problems.
- echopom 5y ago
  > 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 https://youtu.be/M3BM9TB-8yA Can't find the specific part where he mentioned "EPOLL"
  - tarruda 5y ago
    > 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. "epoll" is a Linux API for listening on multiple file descriptors. Different platforms have equivalent APIs, and these are normally core of any scalable non-blocking I/O network program. Can you elaborate why do you think he had an obsession with "epoll"? More importantly, can you elaborate what was the fiasco? Epoll is still used under the hoods by Node.js (through libuv) and many other network servers such as Nginx
  - gadrev 5y ago
    re-[0]: 15:43
  - e12e 5y ago
    > (...) will end up in a new fiasco. Are you saying nodejs is a fiasco?
  - v8dev123 5y ago
    npm maybe bloated but I'd say it's better than pip. pip is insane, you have to set up virtual env (hurts UX) but with node you don't have to.
- noir_lord 5y ago
  If they don't attempt to address it they'll certainly fail.
hnbad 5y ago
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.
- 1_player 5y ago
  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.
  - grumple 5y ago
    I have yet to find a datetime library in any language that was adequate for all purposes I've needed. That's not a particularly damning example in my opinion. I've had to write very weird datetime code in JS, Python, and Ruby. I don't even want to imagine the horrible things you could find in some other languages.
    - throwaway2037 5y ago
      In Java, Joda-Time was a third party library for ages. It was the dominant date-time lib for enterprise development. Then, it was standardised and added to the stdlib: java.time (JSR-310). The Joda-Time project lead, Stephen Colebourne, ran the standardisation process. It was well received by most, even the breaking API changes that SC was adamant were flaws in the original Joda-Time API. I can vouch for it: Both Joda-Time and the java.time libs are excellent. (In my job, I regularly need to perform complex date-time transformations, including time zones.) I have also used Howard Hinnant's C++ date-time lib: https://github.com/HowardHinnant/date https://github.com/HowardHinnant/date It is also very good. (He was the guy behind move semantics in C++ 11.) In Python, the stdlib has a function to get UTC now, that does not include UTC timezone... so it weirdly and surprisingly acts like local time zone! There is endless shit-posting about it. I feel bad for Guido van Rossum et al. To be fair, the original Java date-time lib was horrible, so Joda-Time was created. And JDBC (Java database) dates are still horrible.
tannhaeuser 5y ago
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.
- Octoth0rpe 5y ago
  > 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 dependency graph that is typical of frontend projects these days is a liability.
  - tannhaeuser 5y ago
    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.
- mmbleh 5y ago
  > It's the ecosystem that every contender would love to be. Trying to clarify - do you mean other JS ecosystems? Outside of JS, NPM is usually used as what not to do, not as an aspiration.
  - doteka 5y ago
    Could you share some examples of ecosystems that are 1) vibrant and active 2) have working, open source, ergonomic tooling of a comparable caliber to VSCode, typescript and friends 3) can target almost any platform, including but not limited to server, mobile, desktop and web? I’m trying hard to think of any, Java and Python come closest but both fall short.
adevx 5y ago
Npm together with the ergonomics of JavaScript/TypeScript is what keeps me in the Node.js ecosystem. Never understood the hate for a massive ecosystem of community build libraries that you can contribute to, fork or modify at will.

by kigiri 5y ago

rapsey 5y ago

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

HatchedLake721 5y ago
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.
valtism 5y ago
Yes but let’s not get that cynical about it. People are working hard on these problems.
echopom 5y ago
> 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 https://youtu.be/M3BM9TB-8yA Can't find the specific part where he mentioned "EPOLL"
- tarruda 5y ago
  > 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. "epoll" is a Linux API for listening on multiple file descriptors. Different platforms have equivalent APIs, and these are normally core of any scalable non-blocking I/O network program. Can you elaborate why do you think he had an obsession with "epoll"? More importantly, can you elaborate what was the fiasco? Epoll is still used under the hoods by Node.js (through libuv) and many other network servers such as Nginx
- gadrev 5y ago
  re-[0]: 15:43
- e12e 5y ago
  > (...) will end up in a new fiasco. Are you saying nodejs is a fiasco?
- v8dev123 5y ago
  npm maybe bloated but I'd say it's better than pip. pip is insane, you have to set up virtual env (hurts UX) but with node you don't have to.
noir_lord 5y ago
If they don't attempt to address it they'll certainly fail.

hnbad 5y ago

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.

1_player 5y ago
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.
- grumple 5y ago
  I have yet to find a datetime library in any language that was adequate for all purposes I've needed. That's not a particularly damning example in my opinion. I've had to write very weird datetime code in JS, Python, and Ruby. I don't even want to imagine the horrible things you could find in some other languages.
  - throwaway2037 5y ago
    In Java, Joda-Time was a third party library for ages. It was the dominant date-time lib for enterprise development. Then, it was standardised and added to the stdlib: java.time (JSR-310). The Joda-Time project lead, Stephen Colebourne, ran the standardisation process. It was well received by most, even the breaking API changes that SC was adamant were flaws in the original Joda-Time API. I can vouch for it: Both Joda-Time and the java.time libs are excellent. (In my job, I regularly need to perform complex date-time transformations, including time zones.) I have also used Howard Hinnant's C++ date-time lib: https://github.com/HowardHinnant/date https://github.com/HowardHinnant/date It is also very good. (He was the guy behind move semantics in C++ 11.) In Python, the stdlib has a function to get UTC now, that does not include UTC timezone... so it weirdly and surprisingly acts like local time zone! There is endless shit-posting about it. I feel bad for Guido van Rossum et al. To be fair, the original Java date-time lib was horrible, so Joda-Time was created. And JDBC (Java database) dates are still horrible.

tannhaeuser 5y ago

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.

Octoth0rpe 5y ago
> 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 dependency graph that is typical of frontend projects these days is a liability.
- tannhaeuser 5y ago
  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.
mmbleh 5y ago
> It's the ecosystem that every contender would love to be. Trying to clarify - do you mean other JS ecosystems? Outside of JS, NPM is usually used as what not to do, not as an aspiration.
- doteka 5y ago
  Could you share some examples of ecosystems that are 1) vibrant and active 2) have working, open source, ergonomic tooling of a comparable caliber to VSCode, typescript and friends 3) can target almost any platform, including but not limited to server, mobile, desktop and web? I’m trying hard to think of any, Java and Python come closest but both fall short.

adevx 5y ago

Npm together with the ergonomics of JavaScript/TypeScript is what keeps me in the Node.js ecosystem. Never understood the hate for a massive ecosystem of community build libraries that you can contribute to, fork or modify at will.