Just realized that de-no is reverse of no-de
Actually, it's not :)
According to the official Deno releases it's:
"node".split("").sort().join("")
Which makes the pun even wittier.
Deno 1.9
191–200 of 245 posts
Re: Deno 1.9
#192Earlier quoted context omitted.
Overall this is true. And beyond that the TypeScript team is heavily involved in TC39, and quite a lot of TC39 proposals are specifically designed to be enhanced by TS. That said... There are a few longstanding incompatibilities/footguns. And they’re likely to remain due to widespread use, even though most are controversial. Off the top of my head: - access control annotations (`private` which is compile time only vs…
> enums [...] everybody but me hates them Hmm, what did I miss, why do people hate them exactly? > And sure it’s marked “experimental” but it’s used a lot and almost guaranteed to be a future conflict. Putting that toothpaste back in the tube is gonna make a lot of people feel a lot of pain. Maybe I'm a bit masochist, but I can't say I feel a lot of compassion for people using experimental features in missing-critica…
> Hmm, what did I miss, why do people hate them exactly?
In my experience, enums are far less type safe and convenient (usage in switch for instance, combined with a linter) than union types.
Re: Deno 1.9
#193Earlier quoted context omitted.
You do something like this export * as Oak from "https://deno.land/x/oak/mod.ts"; export * as Postgres from "https://deno.land/x/postgres/mod.ts"; Then you do this: import { Oak, Postgres } from "./deps.ts";
> Do you namespace them yourself, or export an object under the name of the library (and therefore give up destructuring?) I know you can do this, but then you can't do import { Function1, Function2 } from "oak"; You could do import { Oak } from "./deps.ts"; const { Function1, Function2 } = Oak; But that is still an awful workaround.
Perhaps you could do:
import { Function1, Function2} from "https://deno.land/x/oak/mod.ts";
Or perhaps you could do
// deps/oak.ts
export * from "https://deno.land/x/oak/mod.ts";
import { Function1, Function2 } from './deps/oak';
Re: Deno 1.9
#194I have been programming computers since 1988, so I have seen a lot of things come and go. Not often has there been a just relationship between quality and popularity. Never has that been so stark as with Node.js. So many mistakes, mistakes that have been made before. Such a mind boggling lack of purpose. There has never been a need for Node.js - except to play with the cool kids that programme Javascript on the clien…
Node wasn't about bringing JS to the server. The purpose of Node was to bring asynchronous I/O to the web - and it absolutely crushed it.
Re: Deno 1.9
#195Earlier quoted context omitted.
If dependencies are imports from URLs, how does one audit their dependencies? If a server gets hacked those TS can be replaced with malicious versions. In npm we at least know that a package is immutable once published, someone could publish a malicious version as a newer release but a current release. Does demo generate some type of file that keeps a hash of all downloaded imports to verify against the next time tho…
> In npm we at least know that a package is immutable once published, someone could publish a malicious version as a newer release but a current release. This is only true as long as you trust NPM. If they were hacked or taken over by a malicious actor, packages could be modified unbeknownst to you.
No they could not. Because your package-lock.json contains integrity hashes that are verified during installation.
Re: Deno 1.9
#196Earlier quoted context omitted.
It's a Node.js alternative. Deno glue code around V8 is written in Rust. It tries to be as close to the browser API as possible, using ES-Modules instead of CommonJS and doesn't require a package manager. Also, it compiles TypeScript automatically.
> Deno glue code around V8 is written in Rust. The C++ V8 api is very reasonable to be used in a safe way. So i dont see this as a good point unless of course for people that wan to write some parts that need to be optimized in Rust. Don't deal with NodeJs that much, but is a lot of node functionality in C++ modules? and if so they are presenting a lot of security bugs in a way that Rust might see appealing? Because…
> Deno glue code around V8 is written in Rust.
Maybe this is not the best way of putting it. They use Rust for all the system bits including networking, so it's not like they just wrote some JS to V8/C++ glue code in Rust.
Re: Deno 1.9
#197Deno's interactive permission prompt is still easily bypassed by nicely asking terminal to confirm it:
https://github.com/denoland/deno/issues/9750#issuecomment-79...
Direct link to asciinema: https://asciinema.org/a/9rvK8ANJK0WnQc9nsrFKdC7ir
Re: Deno 1.9
#198Earlier quoted context omitted.
It's the most popular PL because it ships in every browser out there, and so you have to use it to do any front-end work. It doesn't really say anything about the quality of the language or its ecosystem.
I agree with you its quality but what i'm saying is that didn't matter. And to counter on the browser bit, Rust/Go/C/etc can be compiled into Webassembly and yet its not thriving. Similarly on the backends Javascript is thriving too.
wasm is still a very niche thing in terms of scenarios that it can cover. Things will be very different once there's a full-fledged native wasm browser API that is at least equivalent in power to what JS gets today.
On the backends, it seems that the only reason why JS even made a foothold there is because it was on the front-end first, and because it had its performance optimized there (V8 etc) first. Node specifically pitched "same language for both front-end and back-end" back in the day.
JS is kind of like C - it just has an immense first mover advantage by now, to the point where it's very hard to move forward from it. I hope wasm will be the holy grail in that regard... eventually.
Re: Deno 1.9
#199I'd love to use deno, but I really don't understand the point deno's module/package system. The standard practice of deps.ts/dev_deps.ts as described in the docs[1] just seems absolutely asinine to me. Importing everything into one scope and then re-exporting from one file just seems like an awful hack. What do you do if two libraries have functions with the same name? Do you namespace them yourself, or export an obj…
You could opt to improve upon the standard practice, right? I have only played with Demo a little, but the deps file seems only like a convention rather than a strict rule.
Why not instead create a deps directory, and keep in it one file per dependency? Inside each file, you re-export the library from URL.
This way you can import from files rather than URLs elsewhere in your code, and it should be clear which dependency is being imported from the file name itself.
Re: Deno 1.9
#200I'd love to use deno, but I really don't understand the point deno's module/package system. The standard practice of deps.ts/dev_deps.ts as described in the docs[1] just seems absolutely asinine to me. Importing everything into one scope and then re-exporting from one file just seems like an awful hack. What do you do if two libraries have functions with the same name? Do you namespace them yourself, or export an obj…
You realize Deno is founded by Ryan Dahl, who founded Node 12 years ago, don't you? Perhaps you should be less quick to label anything about it "asinine" or even "awful hack".
I do! And I think node has a lot of flaws (Ryan seems to agree).
I do not understand why deno has gone for this route. It seems primed to produce a package manager eventually, and it seems like a bad idea to leave package manager creation down to whoever makes the first decent tool (which is mostly why npm is the standard for node.)