4 ms·

> without having to choose one of the 20 relatively popular Postgres client libraries They can easily provide official extensions/packages clearly namespaced a

> without having to choose one of the 20 relatively popular Postgres client libraries They can easily provide official extensions/packages clearly namespaced and avoid all this mess. But I fear that they're more focused on a "headline-driven-development" approach, the more different from the status quo, the better

animuchan 2y ago
And it's successful! I've unironically learned about Bun on YouTube, and now am a happy user. :) A set of "blessed" known good packages would be wonderful to have in any language, I wonder why it's not a thing.
- Raed667 2y ago
  I'm wondering what made you switch ? I find the ubiquity of node very comforting, maybe I'm not seeing the argument that will convert me over ?
  - morcus 2y ago
    Not the original commenter - It has just been a pretty low effort drop in replacement for me. It's definitely not a complete game changer, but quick iteration is just that bit more convenient since it's faster and I don't need to remember all the flags I normally have for my setup (Typescript, .env file, etc...)
  - animuchan 2y ago
    Not entirely switch, but so far I've been using bun for small side projects and it's been rewarding. There's a lot less project managing, some scripts can be just a single file with no dependencies, no package.json and no build chain. Of the "batteries included" features, the `Bun.serve` web server and the `HTMLRewriter` HTML5 SAX API thing are very powerful, saving a lot of node_modules space. Running TypeScript without a build step is neat. (I know there's `node --experimental-transform-types`, and it's great to see this feature propagated "upstream") That said, for large established Node.js projects, I don't really see the pull to switch over to Bun. There's cost associated with it (for one, the built-in test runner works a bit differently, so if you're using `node --test` it'll require some fiddling)
wiseowise 2y ago
No, thanks. That’s what Kotlin does and it’s an absolute shitshow. I want ‘editor index.ts’ and start working instead of going shopping for something that should’ve been part of std.

animuchan 2y ago

And it's successful! I've unironically learned about Bun on YouTube, and now am a happy user. :) A set of "blessed" known good packages would be wonderful to have in any language, I wonder why it's not a thing.

Raed667 2y ago
I'm wondering what made you switch ? I find the ubiquity of node very comforting, maybe I'm not seeing the argument that will convert me over ?
- morcus 2y ago
  Not the original commenter - It has just been a pretty low effort drop in replacement for me. It's definitely not a complete game changer, but quick iteration is just that bit more convenient since it's faster and I don't need to remember all the flags I normally have for my setup (Typescript, .env file, etc...)
- animuchan 2y ago
  Not entirely switch, but so far I've been using bun for small side projects and it's been rewarding. There's a lot less project managing, some scripts can be just a single file with no dependencies, no package.json and no build chain. Of the "batteries included" features, the `Bun.serve` web server and the `HTMLRewriter` HTML5 SAX API thing are very powerful, saving a lot of node_modules space. Running TypeScript without a build step is neat. (I know there's `node --experimental-transform-types`, and it's great to see this feature propagated "upstream") That said, for large established Node.js projects, I don't really see the pull to switch over to Bun. There's cost associated with it (for one, the built-in test runner works a bit differently, so if you're using `node --test` it'll require some fiddling)

wiseowise 2y ago

No, thanks. That’s what Kotlin does and it’s an absolute shitshow. I want ‘editor index.ts’ and start working instead of going shopping for something that should’ve been part of std.