Live data from Hacker News

Deno 1.9

deno.com

151–160 of 245 posts

Re: Deno 1.9

#151
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…

Because Typescript eventually won that race? (The race to be a fine, typed and sane counterpart to Javascript). Somehow Typescript convinced people from the Javascript side of the fence that they could mix both and eventually upgrade from it. While Dart also tried the same feat, it failed doing so. Nowadays Dart is only being considered to anything because the team behind it are top-notch and implemented themselves a…

> Because Typescript eventually won that race? (The race to be a fine, typed and sane counterpart to Javascript).

Dart is doing fine, I'm not sure what race you're talking about?

> If you want to use Flutter go for Dart, but picking Dart to anything outside Flutter will just alienate the developer crowd as giving even Typescript is some sort of a niche language in terms of adoption, nevermind forcing people to learn Dart

Dart is incredibly similar to Javascript/Typescript. You can learn it over a weekend + lookups in Google whenever you see a difference.

Your points are extremely weak.

Re: Deno 1.9

#152

Earlier quoted context omitted.

node actually invented a lot of wheels. node was first with promises (a couple major iterations!), streams, uhh I dunno what else. file access (we're just getting that now in the browser after some old ill supported early attempts). modules. the web reinvented many of these wheels.

Node didn’t introduce the Promise API. Although it definitely instigated it. Node, with its async IO model, was just littered with callbacks. There were a zillion different approaches to async APIs that could ease that. Promises were, well, the most promising. But years of iteration and competing standards came and went before Node adopted them as the preferred API. And they did so right along with browser vendors an…

I was referring to node I still largely think kris kowal building the "Q" promise library is what made promises interesting, what surfaced the idea that we might want to first-class our completeablea/futures. I know kris had some specific inspirations but I forget what.

pains me somewhat to this day that promises ultimately became somewhat un-value like, that handlers don't get to see what it was resolving. all the chain/spawn discussion, the functional promise folk: they got rolled by those insisting we had to target only the lowest rings of the developership, and that allowing more potent systems was unacceptable. wish I could find those es-discusa threads, for the powerful sorrow of the afteath, what we are stuck with, in it's so lites form, haunts me. especially as we double back a decade latter & invent controllers & signals toanage our promises. which we would have had for free.

way off topic now. forgive me my late night ramblings.

[1] https://github.com/nodejs/node-v0.x-archive/blob/v0.1.30/Cha...

Re: Deno 1.9

#153

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…

>Maybe I'm a bit masochist, but I can't say I feel a lot of compassion for people using experimental features in missing-critical production code.

To be fair, decorators are an experimental feature in name only at this point. A lot of libraries force you to use it, including Microsoft's own tsyringe and the beyond popular TypeORM. NestJS is a reasonably popular framework that will codegen services with decorators in them. As the OP of this thread said, the toothpaste is out of the tube now.

Re: Deno 1.9

#154

Earlier quoted context omitted.

> 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…

>Maybe I'm a bit masochist, but I can't say I feel a lot of compassion for people using experimental features in missing-critical production code. To be fair, decorators are an experimental feature in name only at this point. A lot of libraries force you to use it, including Microsoft's own tsyringe and the beyond popular TypeORM. NestJS is a reasonably popular framework that will codegen services with decorators in…

Fair point.

Re: Deno 1.9

#155

Earlier quoted context omitted.

And yet it is the most popular programming language in the world.. So maybe you're not exactly right. In the end it's not about what coders need it's what they want .

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.

Re: Deno 1.9

#156

Earlier quoted context omitted.

The problem the deps.ts pattern solves is that your project has several dozen modules that all import a particular version of a dependency, and now you need to update them all to a new version of that dependency. (If your project only has one module, then you don’t have this problem and don’t need this solution.)

Why not just use sed?

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

Re: Deno 1.9

#157
post #150

I wish deno files had a different file extension. Editor gets confused often switching between front end typescript and deno typescript.

For frontend TypeScript I assume you mean TypeScript that doesn't use JS modules but extensionless modules, the TypeScript folks sadly have decided to not bring compatibility here ATM.

Re: Deno 1.9

#158
post #121
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…

How come more people don't use ReasonML in place of this? It runs as OCaml on the server, it is a typed language, it's faster than v8 JavaScript. Or F#? Not a fan of the functional? Then maybe Kotlin? Nim? No? There are a ton of great languages out there, many arguably better than TS in many ways. But for a language to be popular, being great is not enough. I'm not sure what it is that makes TS so popular, but I am p…

Well in this case, the Dart VM and V8 are a made by the same people. That's why I asked.

Re: Deno 1.9

#159
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…

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 those imports are downloaded?

Re: Deno 1.9

#160
post #81

What exactly does deno promise when it comes to package management?

Not sure why this got downvoted, but I have the same question. Most of my projects run behind a corporate firewall, where our NPM repository is proxied. Will Deno eventually offer something?

As far as I understand, you can import packages from anywhere, which is obviously a major concern for anyone behind a corporate firewall

Post reply on HN