Nice, I deno about this.
Deno 1.0
321–330 of 598 posts
Re: Deno 1.0
#322Earlier quoted context omitted.
No one is questioning the utility of URLs. Using URLs to specify dependencies right in the import statement is a horrible idea.
How is it any worse than using names from a namespace controlled by “npmjs.com”: if you’re concerned about build stability, you should be caching your deps on your build servers anyways.
I've never used npm or developed any javascript before but it sounds equally horrible.
Not decoupling the source of the package (i.e., the location of the repository whether it is on remote or local) and its usage in the language is a terrible idea.
from foo import bar
# foo should not be a URL. It should just be an identifier.
# The location of the library should not be mangled up in the code base.
Re: Deno 1.0
#323Earlier quoted context omitted.
True, but that's what people using Go have been doing for years without complaining much, so I guess it works fine for most workload. And before npm fixed things after the left-pad incident, the npm builds where not reproducible either (as demonstrated by the said left-pad incident).
> True, but that's what people using Go have been doing for years without complaining much, so I guess it works fine for most workload. I hate to break it to you but dependency management has been a massive issue in golang until the devs formally adopted go mod. Only Google seemed okay with checking in their dependencies to version control. Everyone else was doing crazy hacks like https://labix.org/gopkg.in
It created a hugely fractured open source ecosystem as well.
Re: Deno 1.0
#324This is interesting. Can you ship the Deno runtime with your runtime code? That's the thing that kills me about Javascript; having to assume the consumer has a runtime setup.
Re: Deno 1.0
#325Earlier quoted context omitted.
That might work for some projects, but can quickly blow up the size of the repo. I don't think it it is an unsolvable problem. For example, other solutions could be using a mirror proxy to get packages, instead of directly from the source, or pre-populating the deno dir from an artifact store. It would be nice to have documentation on how to do those though.
A better solution is something like https://vfsforgit.org/
That's not necessarily better. For one thing, it doesn't support Linux yet. For another, afaik, Azure DevOps is the only git hosting service that supports it.
Even if it was better supported, I wouldn't want to start using it just so I can include all my dependencies in git. Of course if you are using something like vfs for git anyway, then increasing the repo size is less of an issue. It still feels wrong to me though.
Re: Deno 1.0
#326Earlier quoted context omitted.
Yes, I think I'd probably settle for solution number 2. I still don't understand how this is better than NPM, and how Deno solves the horrible dependency management of Node, but maybe if I actually build something with Deno I'll get some answers.
From the post: > [With NPM] the mechanism for linking to external libraries is fundamentally centralized through the NPM repository, which is not inline with the ideals of the web.
> which is not inline with the ideals of the web
Subjective.
> Centralized currency exchanges and arbitration is not in line with the ideals of the web! - Cryptocurrency
Nek minute. Besides, let's get real here; they will just end up centralized on GitHub. How exactly is that situation much different than npm or any other language ecosystems library directory being mirror-able?
Re: Deno 1.0
#327I'm drawn to the simple beauty of the deno.land website.
Re: Deno 1.0
#328> In Deno, sockets are still asynchronous, but receiving new data requires users to explicitly read() Interesting. If I understand correctly, they're essentially using pull streams[0]/reactive streams[1]. I compiled a few resources on this topic when I was digging into it a while back[2]. I've found the mental model to be very elegant to work with when needing backpressure in asynchronous systems. As for the dependen…
I would call it: "They are essentially using the plain async conversions of regular system calls and Stream (e.g. known from Java/.Net) APIs"
All the reactive streams stuff still had been push streams, just with some backpressure bolted on. The issue was that without async/await, you always end up with some kind of callback model, which then again results in a push model.
Whereas with async/await you can just mostly model IO like any kind of synchronous IO.
Re: Deno 1.0
#329I feel explicit location imports are a step backwards. Node ecosystem is moving toward workspaces and Yarn Plug'N'Play style manifest lookups for deps. The de-coupled import from where physically the dependency is being satisfied from seems desirable and it is a common next-level pattern in project and dependency management across language ecosystems.
Sure, I guess you could shim it somehow like is happening in the node ecosystem but then.. I'm not sure what the stock situation brings to the table TBH.
Re: Deno 1.0
#330Nice. seems Deno is an anagram of Node.