11–20 of 100 posts
> Node.js is too easy to get started. This means that the pool of available programmers is not the highest quality. Runtimes like Go or Deno are still havens for the ‘connoisseur’ programmer. wat (Deno seems worth checking out though!)
> Node.js is too easy to get started. This means that the pool of available programmers is not the highest quality. Runtimes like Go or Deno are still havens for the ‘connoisseur’ programmer. wat (Deno seems worth checking out though!)
Earlier quoted context omitted.
It's using SSL, what's the real world concern here? Other than someone might get copy-paste happy and someday install something they don't want.
There's quite a bit wrong with this idea that "It's using SSL [therefore it's safe]", assuming your meaning there. The most obvious case: someone compromises the installation script on the actual real deno server. Right now the webserver there is returning an HTTP/307 to an HTTP/302 to the "current" installation script file. Any compromise of the webserver makes this very dangerous. Contrast that with proper signed p…
Is there a reason Deno is not packaged as a repo in official apt, deb, yum, etc repositories?
> Node.js is too easy to get started. This means that the pool of available programmers is not the highest quality. Runtimes like Go or Deno are still havens for the ‘connoisseur’ programmer. wat (Deno seems worth checking out though!)
"Too easy to get started" is just gate keeping.
> Node.js is too easy to get started. This means that the pool of available programmers is not the highest quality. Runtimes like Go or Deno are still havens for the ‘connoisseur’ programmer. wat (Deno seems worth checking out though!)
This means at the level of their ability to draw in candidates, Deno interest is signal to their hiring pipeline of more quality. The consequence is their hiring pool is also that much smaller. One might say the same thing about Java v Go.
In the current market, unless you're a big company that gets flooded with applications on a daily basis, why would you ever reduce your hiring pool arbitrarily? If you're a 13-person startup with good funding, you want all the candidates you can possibly get. Excluding potentially great engineers because they've never worked with Deno doesn't make any sense.
Earlier quoted context omitted.
You're about to run their software on your computer-- what's the difference with that and running their install script?
How do you guarantee that their install script is non-malicous and was actually provided by them? There's a reason why code signing exists as a security measure.
The security model is a big one for me. If they could extend the permissions system to work for individual dependencies, they could solve one of the biggest security issues facing developers right now. Especially if policies could also be applied to node packages. Are there any plans to move in this direction? It seems like if you can do it for the full app, you should hypothetically have the capability to make it li…
To me, it seems like you'd need a new language.
It is disappointing to see this message as the basics of what the software is on their site ( https://deno.land/ ): Deno is a simple, modern and secure runtime for JavaScript, TypeScript, and WebAssembly that uses V8 and is built in Rust. Only to have that immediately followed by really poor practice of suggesting this as the installation method: curl -fsSL https://deno.land/install.sh | sh This is not strictly relat…
It's using SSL, what's the real world concern here? Other than someone might get copy-paste happy and someday install something they don't want.
2. copy/pasting includes invisible characters that aren't seen until executed
both of these things happen regularly
orthogonally, curl|sh (usually) circumvents the package manager and makes uninstallation difficult
Earlier quoted context omitted.
"Too easy to get started" is just gate keeping.
On one hand, JavaScript being easy makes programming accessible. On the other hand, the state of programming is terrible and getting worse. So you can't say if it's bad or not.
What does this mean? It's an order of magnitude easier to build an app/service/whatever today than it was a decade ago. Having to maintain separate code paths for IE because it doesn't support many of the APIs and CSS features you need was "terrible"; by comparison, engineering today is heavenly.
The security model is a big one for me. If they could extend the permissions system to work for individual dependencies, they could solve one of the biggest security issues facing developers right now. Especially if policies could also be applied to node packages. Are there any plans to move in this direction? It seems like if you can do it for the full app, you should hypothetically have the capability to make it li…
> Or perhaps there are non-obvious blockers that make it too hard? To me, it seems like you'd need a new language.