Deno 1.9 • Hacker News Board

Re: Deno 1.9

#201

Post by zkldi » Wed, Apr 14, 2021, 11:53 AM UTC

ARussell wrote: post #199

zkldi wrote: post #88

I'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 depende…

That solution is great! But it sounds like something that could be automated or managed for me.

Re: Deno 1.9

#202

Post by eloff » Wed, Apr 14, 2021, 12:10 PM UTC

de6u99er wrote: post #112

Having read multiple comments Deno looks to me like somethung I want to get into. Is there somewhere a getting started with Deno guide, tackling setup of a d velopment environment and some typical use cases as examples? How would e.g. a company like CloudFlare run Deno instead of v8 for it's serverless infrastructure?

> How would e.g. a company like CloudFlare run Deno instead of v8 for it's serverless infrastructure?

They're both built on v8.

Re: Deno 1.9

#203

Post by jonathanaird » Wed, Apr 14, 2021, 12:35 PM UTC

hannofcart wrote: post #169

syspec wrote: post #107

I have a question, how come people do not use Dart in place of this? It runs on the server, it is a typed language, it's faster than v8 javascript (since that is part of the reason for it's existence to eek out more performance) From what I've seen it can be distributed very as well, and your app is self contained ala Go. --- So my question is, why don't more people use Dart where they would use a "Node + 'Typescript…

I have only seen Dart code in Flutter code bases, and my comment here might be the result of incomplete knowledge. However, from what I can see, Dart seems to resemble the Java way of doing things a lot. Specifically, the over-use of is-a inheritance. Just scrolling through the list of examples in the Flutter samples directory illustrates this point. https://github.com/flutter/samples Use of inheritance seems to be t…

The canonical way of doing things in Flutter is composition NOT inheritance. This is the whole point of Widgets. Inheritance is used in ways that generally make sense and don’t result in huge complex inheritance trees.

Re: Deno 1.9

#204

Post by jessaustin » Wed, Apr 14, 2021, 12:50 PM UTC

joelg236 wrote: post #129

sroussey wrote: post #128

Earlier quoted context omitted.

Wouldn’t this work? import { Oak: {Function1, Function2} } from "./deps.ts";

This isn't valid syntax, no

This is a regression. This was possible with "require" and destructuring assignment.

Re: Deno 1.9

#205

Post by hajile » Wed, Apr 14, 2021, 2:11 PM UTC

jonathanaird wrote: post #203

hannofcart wrote: post #169

Earlier quoted context omitted.

I have only seen Dart code in Flutter code bases, and my comment here might be the result of incomplete knowledge. However, from what I can see, Dart seems to resemble the Java way of doing things a lot. Specifically, the over-use of is-a inheritance. Just scrolling through the list of examples in the Flutter samples directory illustrates this point. https://github.com/flutter/samples Use of inheritance seems to be t…

The canonical way of doing things in Flutter is composition NOT inheritance. This is the whole point of Widgets. Inheritance is used in ways that generally make sense and don’t result in huge complex inheritance trees.

Dart has top-level, first-class functions that don't require wrapping everything in a class. It then proceeds to waste this by wrapping everything up into classes and hoping nobody will use inheritance.

Re: Deno 1.9

#206

Post by kaba0 » Wed, Apr 14, 2021, 2:18 PM UTC

rsp1984 wrote: post #39

I'm not so familiar with web development and don't quite understand where this fits in. I know I can run JS in my browser. I know I can run JS on a web server using node.js. I know I can compile Typescript to JS. So how does Deno fit in and what is the added value? Not trying to be negative, just curious.

Similarly, how does both Node.js and Deno compare to GraalJS? I've been reading about it and find the idea absolutely genius, but I'm sure it doesn't have nearly as much of a userbase as these.

Re: Deno 1.9

#207

Post by goldenkey » Wed, Apr 14, 2021, 2:23 PM UTC

jessaustin wrote: post #204

joelg236 wrote: post #129

Earlier quoted context omitted.

This isn't valid syntax, no

This is a regression. This was possible with "require" and destructuring assignment.

I don't know why you are getting downvoted. I agree. The difference is that ES6 imports are meant to be more optimized and also can allow for async/top-level async modules. I believe part of the additions of ES6 modules made it harder to treat the right hand side like a complete object that can be destructured. In summary, it's not the syntax, it's the difference in feature richness between ES6 and CommonJS importing.

Re: Deno 1.9

#208

Post by goldenkey » Wed, Apr 14, 2021, 2:29 PM UTC

smallnamespace wrote: post #166

systemvoltage wrote: post #156

Earlier quoted context omitted.

Why bother with DRY at all? Just sed all day to replace 24 instances of function foo().

Indeed, DRY is overrated, especially for trivial things like string constants.

How is DRY overrated? Making edits to a codebase shouldn't require any more tools than a text editor. I wouldn't want to live in a house that required powertools for every minor repair, it would be burdensome and indicate poor development practices.

Re: Deno 1.9

#209

Post by goldenkey » Wed, Apr 14, 2021, 2:37 PM UTC

eevilspock wrote: post #149

Twixes wrote: post #147

Earlier quoted context omitted.

With all respect to Ryan Dahl, I'm sure he'd disagree with the "asinine" characterization but would also disagree he's infallible - as evidenced by the creation of Deno after Node

I'm just saying Don't be so quick to judge. Be humble! No one is infallible. That said, creating Deno after Node doesn't imply that Node was a fail or that Deno will be perfect. Obviously not. Consider that someone really smart has reasons for doing (or trying to do) things a certain way. Be humble!

Node is a failure. It's standard library is written ad hoc. Riddled with catch 22s and monkey patches. The development style is just to bolt on more and more variables and branches, endlessly, without any cohesive style.

Example of the "common caterpillar" genus of node quirks and the awful antagonistic responses by the dev team: https://github.com/nodejs/node/issues/25857

Just take a look at a random stdlib source file: https://github.com/nodejs/node/blob/master/lib/readline.js

``` if (input && input.input) { // An options object was given output = input.output; completer = input.completer; terminal = input.terminal; history = input.history; historySize = input.historySize; signal = input.signal; ```

It's junior-level code writing all over the project. That is a failure in my mind, especially when I know the library backing my project has to import all that junk hidden from view.

See (wontfix) fs.promises.readFile is 40% slower than fs.readFile: https://news.ycombinator.com/item?id=26332774

Not to mention the awkward political nature. There is a BLM banner on their front page: https://nodejs.org .The founder of BLM, Patrisse Cullors, just bought 4 mansions, the last for $1.4 Million USD: https://news.yahoo.com/blm-official-calls-investigation-foun...

Node's dev team is not interesting in supporting the community. They are amateurs who are trying to be woke and add "top Node contributor" to their toolbelt of proverbial ego items. Prove me wrong.

Re: Deno 1.9

#210

Post by tengbretson » Wed, Apr 14, 2021, 2:50 PM UTC

folkrav wrote: post #148

eyelidlessness wrote: post #132

Earlier 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?

They operate in a weird gray-zone between being just compile-time types vs. an actual readonly object in the runtime. I don't think I've seen a use case for them yet that wouldn't have been better accomplished with a union type of string literals and using const string literals in the code.