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].
Deno 1.33: Deno 2 is coming
61–70 of 127 posts
Re: Deno 1.33: Deno 2 is coming
#62Earlier quoted context omitted.
I like to get paid for my work. Most people do. There is nothing disgraceful about that. I don't see any difference between deno as a company and your SAAS bernard.app.
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...
Re: Deno 1.33: Deno 2 is coming
#63Nice 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
Re: Deno 1.33: Deno 2 is coming
#64Earlier quoted context omitted.
I think Deno feels a fire under their ass. The JS ecosystem has not really embraced Deno in terms of tooling, libraries or frameworks and the serverless ecosystem has not embraced Deno as a runtime (aws/gcp/azure functions), so they're iterating rapidly to see if they can get something to really stick. And then there's Bun. I love Deno for system scripting but the friction with the rest of the JS ecosystem has preven…
[flagged]
I would rather they have money and a business plan. That way it’s more likely it will get the resources needed to develop it, build a community around it, and I won’t end up with a mothballed open source project that’s not maintained anymore.
Nodejs is an open source alternative you can stick with, if you don’t like commercial products.
Re: Deno 1.33: Deno 2 is coming
#65Didn't take too long to start the 2.0 version. I really like how Rust does not do this.
Re: Deno 1.33: Deno 2 is coming
#66deno 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.
Re: Deno 1.33: Deno 2 is coming
#67Building 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 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, …).
Re: Deno 1.33: Deno 2 is coming
#68Building 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…
I think this kind of "batteries included" approach is interesting. My feeling is that in many cases we spend way too much time when building our platforms from various bits and pieces. Some apps and businesses would get huge productivity boost by using more opinionated platform.
Not saying this is for everything and everyone, but there's so much competition on this space that I can understand why somebody would like to try something different.
Re: Deno 1.33: Deno 2 is coming
#69Building 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.
Re: Deno 1.33: Deno 2 is coming
#70Building 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…
Building a KV store into the runtime, that has more features when using deno deploy is just that: vendor lock-in. It's just one more way to force you into paying for the service when you have locked yourself in and you can't use an alternative store. Deno is not and has never been an "alternative runtime" to node.
I am confused. In my book vendor lock-in would refer to a situation where a user or customer would be unable to switch vendors or only with prohibitivly large cost and often under the notion that they were unknowingly lead into that situation.
So first of all, _you_ can use whatever ORM or database solution you like in general so _you_ specifically choose which technology you want to invest in. If you want to hand craft your kubernetes cluster for your database nodes and put them on GCP or Azure, then go for it. You want redis? Go for it. If you want to use supabase, firebase, planetscale or whatever, use that. If you want to choose a KV store that's built into your runtime then that's great. Believe it or not but people use lowdb in production and their database is literally a json file. I would argue whichever you choose, switching from one hosting provider, database solution, managed or unmanaged platform to another will always incur cost and how high that is will depend on your depth of integration and familiarity with it. I am most likely going to use this feature and I am happy it exists. Also let's not ignore that there is a large breadth of different needs that developers have. Would I build a massive modular corporate CRM system with BI features with it? Probably not. Am I going to build my next D&D game tool, habit tracker or Tinder for sneaker trading for it? Maybe!
I sincerely wonder what specifically you loose from this feature simply existing.