Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deno Joins TC39

deno.com

Post reply on HN
Print view View original

151–158 of 158 posts

Re: Deno Joins TC39

#151

Post by munificent »

moron4hire wrote: post #148
munificent wrote: post #136

Earlier quoted context omitted.

TypeScript is an optionally typed language. It's core to the design of the language that the static type system is purely statically typed and doesn't come into play at runtime. You could argue that that's not the best kind of language for users. I wouldn't disagree. I work on Dart which used to be optionally typed but now has a fully sound type system with runtime checks. But that's orthogonal to whether browsers sh…

That's a strangely puritanical viewpoint. I wouldn't say it's core to the design of the language . I'd say it's a key design decision for the development of the compiler , but those are two different things. Also, I don't understand what you mean by "it wouldn't be TypeScript". Languages change. They change all the time. Did adding nullish coallescing before it became availalbe in JavaSciprt? It's also not true that…

> I wouldn't say it's core to the design of the language.

It is absolutely core to the language. TypeScript's core value proposition is that you can take vanilla JavaScript and use it from TypeScript without any overhead, incrementally migrate to TS, or maintain a heterogeneous codebase as long as you want.

If you take away seamless zero-overhead JS interop, the language you have is radically different from TypeScript. To the degree that any language has any identity at all, that would be a pretty fundamental change in its identity. Like taking objects from Java or pointers from C.

To the best of my knowledge, no one has figured out how to have a language that allows mixing dynamic and static typing without either massive runtime overhead or giving up soundness. You basically have three options:

1. Allow dynamic types to flow into statically typed code

2. Soundness inside the statically typed code

3. Tolerable runtime overhead when using dynamic code from static code

But you only get to pick two. TypeScript, Dart 1.0 and other optionally typed languages give you 1 and 3 at the expense of 2. Dart 2.0 and other statically typed languages give you 2 and 3 at the expense of 1. Gradually typed languages like Typed Racket give you 1 and 2 at the expense of 3 (and are rarely used in practice because of it).

You're asking for TypeScript to just add 2. People have been trying to figure out how to get all three for decades but no one has succeeded yet [1].

[1]: https://blog.acolyer.org/2016/02/05/is-sound-gradual-typing-...

Re: Deno Joins TC39

#152

Post by SiVal »

AaronO wrote: post #22
SiVal wrote: post #12

Earlier quoted context omitted.

Will there be a Deno equivalent of Electron?

Aaron@Deno here, we've been exploring something with the Tauri team but don't have a concrete release on the roadmap since we're focusing on other priorities. I believe an Electron alternative is an important part of the Deno stack, so hopefully we'll ship a first iteration next year.

Thanks, Aaron. I think people who have been using Node for years are skilled at the old Node ways and have huge inertia in their skills, their own code, and others' Node code. For them, the ideal platform would be Node plus some upgrades. I'm guessing they would rather extend their inertial frame of reference than leave it behind.

Then there are others of us who have been saying no to Node and legacy JS for years. We have no such legacy to maintain and no intention of ever creating any. But some of us (at least I) would reconsider platforms built from scratch on a new TypeScript foundation rather than layered on a pre-ES6 foundation. That would include a Deno-based Electron. You might have more luck converting people who don't use Node than getting Node users to abandon their legacy.

The state of cross-platform desktop apps is terrible. All attention is on mobile, and desktop OS makers have almost zero interest in supporting cross-platform desktop apps. (MS cares a little more than zero, Apple less than zero and barely tolerates their own Mac-only developers.) Only something browser/Chromium based seems realistic for the next few years.

On the server, there are a lot of alternatives to Node that are considered better by (and very popular with) large segments of the market. Deno will be one of them, I think. But for cross-platform desktop apps, Electron would be rejected completely if the alternatives weren't so bad and unlikely to get better. A better Electron, despite its inherent problems, could end up more popular than server-side Deno. Just a thought.

Re: Deno Joins TC39

#153

Post by spankalee »

munificent wrote: post #150
spankalee wrote: post #142

Earlier quoted context omitted.

This is also why Deno running TypeScript directly is a bad idea.

The difference is a that a developer has a lot more control over what version of Deno their server-side app runs on than they do what version of a browser their client-side app runs on.

This isn't really true in the wider ecosystem. Yes, the app developer does, but the library developer does not. As Deno adopts newer versions of TypeScript and config options libraries can fail to compile. This is compounded by the lack of a package manager so that references to specific versions and CDNs are hardcoded into dependents.

All with essentially no benefit over running plain JS with associated typings.

Re: Deno Joins TC39

#154

Post by spankalee »

Soremwar wrote: post #144
spankalee wrote: post #142

Earlier quoted context omitted.

This is also why Deno running TypeScript directly is a bad idea.

They don't though. They transpile it behind the scenes

Same thing with the same problems. The difference being that Deno isn't going to have the same no-breaking-changes policy that the web does.

Re: Deno Joins TC39

#155

Post by moron4hire »

munificent wrote: post #151
moron4hire wrote: post #148

Earlier quoted context omitted.

That's a strangely puritanical viewpoint. I wouldn't say it's core to the design of the language . I'd say it's a key design decision for the development of the compiler , but those are two different things. Also, I don't understand what you mean by "it wouldn't be TypeScript". Languages change. They change all the time. Did adding nullish coallescing before it became availalbe in JavaSciprt? It's also not true that…

> I wouldn't say it's core to the design of the language. It is absolutely core to the language. TypeScript's core value proposition is that you can take vanilla JavaScript and use it from TypeScript without any overhead, incrementally migrate to TS, or maintain a heterogeneous codebase as long as you want. If you take away seamless zero-overhead JS interop, the language you have is radically different from TypeScrip…

No, I'm not. You're way overthinking this and your attitude is weirdly gatekeepy. I'm asking TypeScript to implement a shortcut feature for the tedious, boilerplate code we already write to use type guards to inspect objects from APIs before passing them on.

Re: Deno Joins TC39

#156

Post by munificent »

moron4hire wrote: post #155
munificent wrote: post #151

Earlier quoted context omitted.

> I wouldn't say it's core to the design of the language. It is absolutely core to the language. TypeScript's core value proposition is that you can take vanilla JavaScript and use it from TypeScript without any overhead, incrementally migrate to TS, or maintain a heterogeneous codebase as long as you want. If you take away seamless zero-overhead JS interop, the language you have is radically different from TypeScrip…

No, I'm not. You're way overthinking this and your attitude is weirdly gatekeepy. I'm asking TypeScript to implement a shortcut feature for the tedious, boilerplate code we already write to use type guards to inspect objects from APIs before passing them on.

I'm not sure where the "gatekeeping" accusation comes from. In your original comment, you wrote:

> There are a number of ways that TypeScript's type-checking can be subverted at runtime, ... As a developer, in the case of an API change that violated my assumptions, I would personally prefer my applications to fail-hard at the point of the API call

I interpreted that to mean that you would prefer TypeScript's type system to be sound: If a function expects a Foo, you want a guarantee that you'll never get into the body of the function at runtime with an argument whose type isn't Foo.

I can understand that that seems like a fairly simple request. But when you dig into soundness, you discover that it is anything but. Optionally-typed languages like TypeScript are unsound by design because soundness is a difficult requirement with very severe trade-offs around interop, runtime performance, and usability. Making TypeScript sound would give you a language that felt very little like TypeScript does today.

Re: Deno Joins TC39

#157

Post by thegagne »

kentonv wrote: post #67
thegagne wrote: post #49

Something I’d like to see, in browsers, Cloudflare Workers, Deno, etc: explicit network firewall in the software stack. An example with Workers, one script might only need to fetch from Backblaze. I’d like to set their host as a whitelisted address, and so even if a log4j type vuln happens, it can’t go anywhere except Backblaze. I think this could even work in browser-land? If you don’t need to pull in any resources…

FWIW, in Cloudflare Workers, a log4j-type RCE vulnerability would be impossible because Workers does not allow dynamic code loading (eval() and similar are disabled). Of course, a lesser form of the vulnerability -- data leaks rather than RCE -- would still be possible. I agree that being able to restrict outbound traffic would be useful to mitigate that. As a hack that works now, you could monkey-patch `fetch()` to…

Thanks for thinking about this Kenton. I agree the data leak is more the concern here, or even accidental use as a ddos attack agent. The scenario is an import of something like worktop, if worktop released a malicious version.

Monkey patching is an option of course, but a native solution would be nice.

Re: Deno Joins TC39

#158

Post by BrendanEich »

lucacasonato wrote: post #115
frutiger wrote: post #75

Earlier quoted context omitted.

He doesn’t need to, the authors of the proposal are on the committee and are planning to see it through. The proposal is humming along through the stages at a good pace.

Exactly. I am very much in favor of them though. They would be a great addition to the language.

Yes, Bloomberg has a big JS investment due to the Terminal (20MLOC of JS last I heard) and they have employed the records and tuples champions.
Post reply on HN