Deno 1.33: Deno 2 is coming
deno.com
Deno 1.33: Deno 2 is coming
1–10 of 127 posts
Re: Deno 1.33: Deno 2 is coming
#2Nice 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?
Re: Deno 1.33: Deno 2 is coming
#3Is it considered a stable version? The amount of unnecessary breaking changes is really frightening.
I mean, why would one ever need to change standard module names or demo.json structure?
Maybe it looks a bit better, but I’m sure it invokes a lot more pain for all developers, who need to watch out carefully with every release.
I consider this a JavaScript curse to be honest. Every webpack version breaks apis in random ways, react native is notoriously hard to upgrade because of this etc
Why isn’t it considered a problem in the community?
Re: Deno 1.33: Deno 2 is coming
#4Building 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 whether you can take advantage of this without using deno deploy, or if you'd be locked in by using deno kv. Also, wondering how many bugs will only show up when deployed due to the different backbends.
Re: Deno 1.33: Deno 2 is coming
#5Is it considered a stable version? The amount of unnecessary breaking changes is really frightening. I mean, why would one ever need to change standard module names or demo.json structure? Maybe it looks a bit better, but I’m sure it invokes a lot more pain for all developers, who need to watch out carefully with every release. I consider this a JavaScript curse to be honest. Every webpack version breaks apis in rand…
The json structure is not a breaking change. You can use the old and the new structure
Re: Deno 1.33: Deno 2 is coming
#6Building 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…
There is a good little overview of Deno KV here (by @simonw): https://til.simonwillison.net/deno/deno-kv
So it's backed by SQLite on the OS local version.
I'm intrigued if there will be a way to swap out the backend for other cloud providers.
Re: Deno 1.33: Deno 2 is coming
#7Is it considered a stable version? The amount of unnecessary breaking changes is really frightening. I mean, why would one ever need to change standard module names or demo.json structure? Maybe it looks a bit better, but I’m sure it invokes a lot more pain for all developers, who need to watch out carefully with every release. I consider this a JavaScript curse to be honest. Every webpack version breaks apis in rand…
Deno has a very cool architecture where almost all of the standard library is imported from outside of the runtime. Which means you can pin specific versions of unstable APIs, and never get caught by surprise even as they're being iterated on rapidly. They also say in the post that eg., the deno.json file changes are backward-compatible
As far as I know, Deno 1.x runtime upgrades are always backwards-compatible
Re: Deno 1.33: Deno 2 is coming
#8> allowing any code editor with LSP support to work great with Deno projects.
Really? And why did he switch to vscode to get autocompletions for deno kv?
Re: Deno 1.33: Deno 2 is coming
#9Is it considered a stable version? The amount of unnecessary breaking changes is really frightening. I mean, why would one ever need to change standard module names or demo.json structure? Maybe it looks a bit better, but I’m sure it invokes a lot more pain for all developers, who need to watch out carefully with every release. I consider this a JavaScript curse to be honest. Every webpack version breaks apis in rand…
The standard library is separate from the Deno runtime and is currently pre-1.0 (0.185.0).
As the blog post touches on, upgrading Deno itself does not force you onto the latest version of the stdlib. You will need to change the import URLs to get it.
Re: Deno 1.33: Deno 2 is coming
#10Building 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…
I dunno.
Is having a database that happens to be a product you sell as part of your runtime good, or are you creating some mixed incentives here?
Are you a database vendor now?
If not, don’t build a database.
If this is a mature product that someone else is looking after, and it’s good and free and we’ll maintained like redis or SQLite, sure.
…but it seems like building cloud databases is not the core competency of a group building a javascript runtime.
Once money is involved, it’ll either be a distraction from their core mission, or become their core mission.
A KV db you can use for quick hacks? Sure. Awesome!
A scalable production database you’re selling to people? O_o why are you doing that?