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

91–100 of 127 posts

Re: Deno 1.33: Deno 2 is coming

#91

Post by cropcirclbureau »

jerrygenser wrote: post #63
StefanWestfal wrote: post #2

Nice to see ongoing development and a view ahead. For work I would need a good interface for SQL. In pet projects I am using sqlx for Rust and sqlc for Python. In both you can write SQL directly and get query validation and parsing into struct / PyDantic for free. Is there something like this for Deno?

I was interested in looking up sqlc for python but it seems to be for go? Is there a different version than this? https://github.com/kyleconroy/sqlc

They appear to have beta grade[0] support for Python and Kotlin. (TypeScript on the roadmap as well)

[0]: https://docs.sqlc.dev/en/latest/reference/language-support.h...

Re: Deno 1.33: Deno 2 is coming

#92

Post by veidr »

Sytten wrote: post #62
sph wrote: post #57

Earlier quoted context omitted.

My SaaS is not an open source project nor a language runtime. How would you feel if Go, Elixir or Rust (just to name a few) were run by a company that depends on their success, so try to push aggressively new features and mindshare, often with disastrous result? Are Go, Elixir or Rust developers working for free? There is a difference between getting paid to work on open source, and structuring an open source company…

This is a bad analogy, it is more like if the Tokio runtime was built by a VC backed business which is really not that bad. Honestly the anti business sentiment on HN is just becoming annoying. Get shamed when not building OSS, get shamed if you take VC money, etc. People are supposed to be saints that work for free so you can then take that and build your own proprietary stuff? Seriously...

Precisely. So much of the negativity in this thread (and elsewhere) weirdly conflates Deno with a language.

Deno is an open source runtime for TypeScript (and JavaScript and WASM). One that has been delightful, in my experience, for system scripting, build tooling, and CLI apps.

Deno Deploy is a hosted runtime that is very similar, but not open source.

The complaining in this thread reads to me like people complaining that the company that makes AWS Lambda also makes DynamoDB.

This new Deno KV is a fantastic addition to both of their runtimes. Dead simple, no need to sign up for some other service, works out of the box in either case.

But nobody is forcing you to use it. You don't have to opt out of it. If you don't like it, then you can go use all the other database layers that you could before this announcement.

Re: Deno 1.33: Deno 2 is coming

#93

Post by mark_and_sweep »

conaclos wrote: post #79
mark_and_sweep wrote: post #71

Earlier quoted context omitted.

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.

I'm not sure you understand the point of Deno if you say that the Node ecosystem does something strange so Deno should do it, too... Magic file resolution was one of the regrets explicitly mentioned in Ryan's first talk introducing Deno.

Re: Deno 1.33: Deno 2 is coming

#94

Post by lenkite »

frou_dh wrote: post #55
lenkite wrote: post #26

Earlier quoted context omitted.

Yeah, this is a very stupid change std/encoding/* is also actually the right place, why pollute the top level namespace with encodings ?

How's it namespace pollution? It won't cause any clashes in either std or the user's code. It's just a few directories moving slightly higher up in a directory structure (which as an aside, is even deeper than you might think, because it also includes the deno.land domain, remember).

Just un-necessary pollutes the drop-down list in auto-completes when someone is coding stuff that has nothing to do with encodings. There is a reason for categorization and this change breaks it.

Re: Deno 1.33: Deno 2 is coming

#95

Post by conaclos »

mark_and_sweep wrote: post #93
conaclos wrote: post #79

Earlier quoted context omitted.

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.

I'm not sure you understand the point of Deno if you say that the Node ecosystem does something strange so Deno should do it, too... Magic file resolution was one of the regrets explicitly mentioned in Ryan's first talk introducing Deno.

I did not say that. I think it is a good thing to do thing properly. File resolution is pretty complex (too complex) in Node/TSC. I would like others tools to support native .ts imports and translate automatically to .js on code emitting. However, it is not going to happen in the short and medium terms.

Using a fallback to .ts files when importing .js files is a minor and straightforward addition to file resolution. And this is a big gain in terms of interoperability with others tools.

Re: Deno 1.33: Deno 2 is coming

#96

Post by komon »

zja wrote: post #69
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…

Deno.dev (deploy) uses a different, proprietary runtime than Deno. I believe Ry mentioned at a recent talk that on deno.dev, the kv will be synced across all instances. Obviously this can’t be the case for stock Deno.

KV storage is SQLite, and SQLite replication and syncing using an out-of-process daemon is becoming a solved problem.

For that application at least no changes to the runtime would be necessary

Re: Deno 1.33: Deno 2 is coming

#97

Post by h1fra »

I still don't understand the true goal of Deno.

It started as "better node.js", with better security and modern tooling. Better security was not achieved imo, it's not flexible enough but painful enough that you want to allow everything straight away. The module system suffers the same issues as of npm, and since everything is loaded from the same domain its hard to tell what is official or not.

They have a builtin server, linter, testing, benchmarking, a hosting platform, now a kv store.

I feel like they are getting away from being a language and heading toward being a framework. Why not, but will probably not help adoption imo.

Re: Deno 1.33: Deno 2 is coming

#98

Post by nateb2022 »

p-e-w wrote: post #33
potamic wrote: post #22

Earlier quoted context omitted.

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…

> There is zero reason for a language runtime to be opinionated about the database. The API is extremely simple. It's little more than a hash map. That's hardly opinionated. > All the good programming advice will tell you such a coupling is a bad idea. That advice is outdated. Virtually any modern application will want a database, and this API can serve as a foundation for it – a foundation that conveniently already…

> The API is extremely simple. It's little more than a hash map. That's hardly opinionated.

In that case, why does Deno have to provide this? Can't users simply create their own hashmap?

Re: Deno 1.33: Deno 2 is coming

#99

Post by tough »

h1fra wrote: post #97

I still don't understand the true goal of Deno. It started as "better node.js", with better security and modern tooling. Better security was not achieved imo, it's not flexible enough but painful enough that you want to allow everything straight away. The module system suffers the same issues as of npm, and since everything is loaded from the same domain its hard to tell what is official or not. They have a builtin s…

Deno is really useful on edge computing like serverless lambda functions in things like NextJS/Vercel or Supabase and such

Re: Deno 1.33: Deno 2 is coming

#100

Post by veidr »

h1fra wrote: post #97

I still don't understand the true goal of Deno. It started as "better node.js", with better security and modern tooling. Better security was not achieved imo, it's not flexible enough but painful enough that you want to allow everything straight away. The module system suffers the same issues as of npm, and since everything is loaded from the same domain its hard to tell what is official or not. They have a builtin s…

Wild take, but agree with your first sentence.

1.) it was never a language

2.) indisputably better security any time you take advantage of any of the features to disable reading of environment variables, using network, reading files, etc.

Post reply on HN