Live data from Hacker News

Deno Joins TC39

deno.com

21–30 of 158 posts

Re: Deno Joins TC39

#21
> More extensive standard library functions for (async) iteration

Great news! I wrote an open source library called axax that adds a number of utility methods to async iterators - map, filter etc.

I think having them as part of the language would be awesome.

Standardising async cancellation would be neat too if Deno wants a challenge....

Re: Deno Joins TC39

#22
post #12

Hey - I am Luca Casonato, Deno's new delegate at TC39. I am happy to answer any questions you all might have :-)

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.

Re: Deno Joins TC39

#23

Hey - I am Luca Casonato, Deno's new delegate at TC39. I am happy to answer any questions you all might have :-)

Hey luca, Huge fan of the achievements that Deno has made in recent years. Several questions: How do you aim to promote Deno as a viable alternative to node, considering it's significant network effect and legacy? Do you believe that Deno's 'more sane' defaults for security will appeal to developers in the long term? Do you think that the front end community will be receptive to these defaults? Choosing TS as your la…

> How do you aim to promote Deno as a viable alternative to node, considering it's significant network effect and legacy?

This is a great question, but not one I can answer in a small HN comment :-). I may write a blog post about it one day. The core of the argument is that Deno can save you an insane amount of time / discussion (OOTB linting, formatting, testing, standard library, etc). It aims to unify the ecosystem into a single style, like in Go.

> Do you believe that Deno's 'more sane' defaults for security will appeal to developers in the long term? Do you think that the front end community will be receptive to these defaults?

I think many developers do not care about permissions, and also will not in the future. This is a problem, but not something that can be tackled overnight. Security is often not emphasized enough in our industry unfortunately. Because of this I think sane defaults and opt ins are good - they push people to think about security at the most basic level. Maybe the log4shell attack also shows people that it is a good idea to sandbox server side scripts aggressively (something we have been pushing for), to prevent large scale system takeovers through a single vulnerable entrypoint.

> Choosing TS as your language de jure, do you think that you will alienate any dyed in the wool JS devs? Can we expect that TS is now effectively the superset of JS going forwards?

There is work being done on this. I don't have too much to share right now, but expect some updates on this early next year. JS has to evolve to support some form of type annotations first class to stay relevant.

> Do you believe Deno's lack of support for NPM style package management will result in cleaning up the frontend community's over reliance on 'leftpad' style packages? Do you think that Deno's approach to dependencies fosters a more considered approach to transitive dependency bloat?

Maybe, maybe not. I think it is still to early to tell. I do think that so far it is looking like it. People seem to be doing less weird stuff like "leftpad" with Deno so far. Ideally all these little helper modules should just be part of JS directly (hit me up with suggestions!)

> Again, huge fan of Deno, and happy to hear about this announcement.

Thanks, glad you like it :-)

Re: Deno Joins TC39

#24

Earlier quoted context omitted.

I hope the pace will accelerate. The real questions is what functions we need though. Some candidates that I would love to see are better helper functions on iterators, and Uint8Array base64/hex. Most of the "standard library" in most languages is related to IO, and for JS is dependant on the host (the web, Deno, Node) so not something TC39 will touch directly. Do you have ideas for standard library functions that yo…

'reversed' a-la python

Currently in stage 2 as `Array.prototype.toReversed`: https://github.com/tc39/proposal-change-array-by-copy

Re: Deno Joins TC39

#25

Earlier quoted context omitted.

I hope the pace will accelerate. The real questions is what functions we need though. Some candidates that I would love to see are better helper functions on iterators, and Uint8Array base64/hex. Most of the "standard library" in most languages is related to IO, and for JS is dependant on the host (the web, Deno, Node) so not something TC39 will touch directly. Do you have ideas for standard library functions that yo…

'zip' a-la python

I have often needed this too. Noted.

Re: Deno Joins TC39

#26

Earlier quoted context omitted.

Hey luca, Huge fan of the achievements that Deno has made in recent years. Several questions: How do you aim to promote Deno as a viable alternative to node, considering it's significant network effect and legacy? Do you believe that Deno's 'more sane' defaults for security will appeal to developers in the long term? Do you think that the front end community will be receptive to these defaults? Choosing TS as your la…

> How do you aim to promote Deno as a viable alternative to node, considering it's significant network effect and legacy? This is a great question, but not one I can answer in a small HN comment :-). I may write a blog post about it one day. The core of the argument is that Deno can save you an insane amount of time / discussion (OOTB linting, formatting, testing, standard library, etc). It aims to unify the ecosyste…

> JS has to evolve to support some form of type annotations first class to stay relevant.

What are you thinking in this regard? Just to define type annotations that can be made but will not necessarily be type-checked at runtime? To have them serve as inputs to the interpreter for optimisations? Or even breaking at runtime if types don't match their annotations?

Re: Deno Joins TC39

#27

Hey - I am Luca Casonato, Deno's new delegate at TC39. I am happy to answer any questions you all might have :-)

What are your thoughts on the do expressions proposal? Cause I think they'd be awesome for cleaner scoping of temporary variables.

I think they are great! Especially in combination with pattern matching (https://github.com/tc39/proposal-pattern-matching), or when using JSX.

Re: Deno Joins TC39

#28

Earlier quoted context omitted.

'reversed' a-la python

Currently in stage 2 as `Array.prototype.toReversed`: https://github.com/tc39/proposal-change-array-by-copy

Nice, I didn't know about that, but in any case note that IMO it should be part of the Iterable protocol. Also note that the proposal above creates a copy on reverse AFAIKT.

Re: Deno Joins TC39

#29
post #16

Hey - I am Luca Casonato, Deno's new delegate at TC39. I am happy to answer any questions you all might have :-)

Hey Luca! What does > Better support for explicit resource management refer to?

Things like https://github.com/tc39/proposal-explicit-resource-managemen.... Essentially better language level support for objects which represent some IO resource that should be reliably closed when a user is done with it. Something like the `defer` statement in Go is really missing from JS.

Re: Deno Joins TC39

#30
post #26

Earlier quoted context omitted.

> How do you aim to promote Deno as a viable alternative to node, considering it's significant network effect and legacy? This is a great question, but not one I can answer in a small HN comment :-). I may write a blog post about it one day. The core of the argument is that Deno can save you an insane amount of time / discussion (OOTB linting, formatting, testing, standard library, etc). It aims to unify the ecosyste…

> JS has to evolve to support some form of type annotations first class to stay relevant. What are you thinking in this regard? Just to define type annotations that can be made but will not necessarily be type-checked at runtime? To have them serve as inputs to the interpreter for optimisations? Or even breaking at runtime if types don't match their annotations?

I don't want to go into details right now. Expect more in a couple of weeks :-)
Post reply on HN