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

Deno 1.33: Deno 2 is coming

deno.com

Post reply on HN
Print view View original

71–80 of 127 posts

Re: Deno 1.33: Deno 2 is coming

#71

Post by mark_and_sweep »

conaclos wrote: post #61

Something that still stop me from using Deno is the incompatibility between Deno and other tooling regarding the import of TypeScript files. Namely, it is not possible to import a `.ts` file via a `.js` import [0]. [0] https://github.com/denoland/deno/discussions/18293

Which other tooling allows you to import a `.ts` file from a `.js` import? Not knowing much about the issue, this seems like a rather strange decision to me: If I'm importing a `.js` file, and it does not exist, I'd prefer an error message rather than the sort of magic that you're suggesting: "Oh, but I found a `.ts` file with the same name, so let me just go ahead, transpile the file to JavaScript and let you import the result!" That's rather unexpected IMHO.

Re: Deno 1.33: Deno 2 is coming

#72

Post by hermanradtke »

mark_and_sweep wrote: post #71
conaclos wrote: post #61

Something that still stop me from using Deno is the incompatibility between Deno and other tooling regarding the import of TypeScript files. Namely, it is not possible to import a `.ts` file via a `.js` import [0]. [0] https://github.com/denoland/deno/discussions/18293

Which other tooling allows you to import a `.ts` file from a `.js` import? Not knowing much about the issue, this seems like a rather strange decision to me: If I'm importing a `.js` file, and it does not exist, I'd prefer an error message rather than the sort of magic that you're suggesting: "Oh, but I found a `.ts` file with the same name, so let me just go ahead, transpile the file to JavaScript and let you import…

This is literally how esm support in node works today unless you turn on an experimental feature flag.

https://www.typescriptlang.org/docs/handbook/esm-node.html

Re: Deno 1.33: Deno 2 is coming

#73

Post by yurishimo »

pictur wrote: post #66

deno seems to follow a very similar line to php. you can do a lot with php without dependencies. but if you are not careful, there is a possibility that you will create garbage. i'm sure this will take deno further, similar to php.

Couldn't you also make this argument for JS in general? I think many folks looking from the outside in at JS would argue that the amount of "JS garbage" has already surpassed PHP.

I know you specified _without dependencies_, but I don't know that it's a fair comparison. The standard library for PHP and JS seem fairly similar to me; I work with both languages daily. Using NPM packages are much easier imo for greenfield projects.

PHP before Composer still had a ton of 3rd party script usage, but with explicit imports instead of autoloading.

Re: Deno 1.33: Deno 2 is coming

#74

Post by wiseowise »

potamic wrote: post #22
billllll wrote: post #4

Building a KV store into the language is kind of nuts. I love how it abstracts away the local SQLite and deployed FoundationDB behind one interface. Testing would be super easy, as there is no question of "do I spin up an entire db instance or mock the db interface?" as SQLite is relatively lightweight and the burden for keeping both cases consistent falls to the language instead. That being said, was wondering wheth…

It's a lock-in strategy. There is zero reason for a language runtime to be opinionated about the database. All the good programming advice will tell you such a coupling is a bad idea. What if you want to move parts of your application to a different language in the future, do you need to redo the entire database? That is just nuts! Database providers, cloud application platforms should be agnostic of the language the…

> What if you want to move parts of your application to a different language in the future, do you need to redo the entire database? That is just nuts!

How often does that happen?

Re: Deno 1.33: Deno 2 is coming

#75

Post by vbezhenar »

datadeft wrote: post #65

Didn't take too long to start the 2.0 version. I really like how Rust does not do this.

I think that difference is that Deno is some kind of commercial startup and Rust feels like community project backed by few huge corporations. So Deno needs to generate hype while Rust's not hurrying anywhere.

Re: Deno 1.33: Deno 2 is coming

#76

Post by qbasic_forever »

dgellow wrote: post #67
kybernetikos wrote: post #43

Earlier quoted context omitted.

I think almost all languages should have a database built in. Almost all programs need a way of storing and querying data but the drama required to hook up to an external db is excessive for little programs. Basic dB functionality should be as available in language standard libraries as file access.

What do you mean by drama to hook up external db? It’s almost always just a one liner: let conn = db.newConn(host, port, …).

One line _after_ you figure out the myriad of database libraries available, half of which are abandoned, a quarter which are little toys, and if you're lucky one that has a core dev who is being paid real money to support and maintain the library.

Re: Deno 1.33: Deno 2 is coming

#77

Post by vbezhenar »

jatins wrote: post #11

Anyone using Demo in production? If yes, what's your experience has been as compared to, say, Next.js?

I wrote tiny script which reloads kube deployments when GitHub CI finishes. I liked the fact that I did it with zero dependencies. Standard library is good enough, and I even had to use some crypto. Zero effort configuration is superb, I hate when I need to configure node for all the things, it easily takes few hours.

I disliked the fact that this script constantly eats few percent of CPU despite being idle 99.999% of the time. Not a big deal but a sign of bad engineering.

Re: Deno 1.33: Deno 2 is coming

#78

Post by qazxcvbnm »

presentation wrote: post #40
pjmlp wrote: post #34

While it is interesting to see the work going on this, unless something really messes up node, I don't see any big adoption ever taking off, other than how egcs forced GCC to come back on track.

The only true benefit I’m seeing as a potential Deno user is the faster startup time to reduce cold boots in a serverless setting - everything else is more in the category of “nice to haves” like ease of setup (I’m used to the workflows with Node so while it’s obtuse it’s something I know and is well documented on the web) and a tighter security model (I haven’t personally ran into any issues with this in Node but ca…

I was unaware of information on superior startup time for Deno and couldn't find references from a quick search. Would you be able to provide more information?

Snapshots having landed in Node (https://nodejs.org/en/blog/release/v18.8.0), is Deno still superior here?

Re: Deno 1.33: Deno 2 is coming

#79

Post by conaclos »

mark_and_sweep wrote: post #71
conaclos wrote: post #61

Something that still stop me from using Deno is the incompatibility between Deno and other tooling regarding the import of TypeScript files. Namely, it is not possible to import a `.ts` file via a `.js` import [0]. [0] https://github.com/denoland/deno/discussions/18293

Which other tooling allows you to import a `.ts` file from a `.js` import? Not knowing much about the issue, this seems like a rather strange decision to me: If I'm importing a `.js` file, and it does not exist, I'd prefer an error message rather than the sort of magic that you're suggesting: "Oh, but I found a `.ts` file with the same name, so let me just go ahead, transpile the file to JavaScript and let you import…

Literally most of other tools: TSC, esbuild, bun, swc, babeljs, ... It is even the recommended way in TSC, esbuild and others to import a .ts file in order to emit esm-valid code. I understand the point of Deno. However, it is just too hard to adopt a tool that cannot be used in tandem with others.

I do not know who downvoted my comment: it is not a healthy behavior.

Re: Deno 1.33: Deno 2 is coming

#80

Post by theGnuMe »

billllll wrote: post #4

Building a KV store into the language is kind of nuts. I love how it abstracts away the local SQLite and deployed FoundationDB behind one interface. Testing would be super easy, as there is no question of "do I spin up an entire db instance or mock the db interface?" as SQLite is relatively lightweight and the burden for keeping both cases consistent falls to the language instead. That being said, was wondering wheth…

The Mumps language did this in the 60s.
Post reply on HN