6 ms·

I maybe chose the wrong horse and hopped onto deno early on. Bun's success has really surprised me. It had some really misrepresented benchmarks that were oft-r

by culi 2y ago

I maybe chose the wrong horse and hopped onto deno early on. Bun's success has really surprised me. It had some really misrepresented benchmarks that were oft-repeated early on that seemed to contribute to it but they've been able to really capitalize on its hype since then. I guess choosing a small up-and-coming language like zig has the added benefit of making that entire community rally behind you

int_19h 2y ago
OTOH it's strange to me that they're shipping v1.2, when Zig itself is at v0.13 (and generally considered a moving target).
- sampullman 2y ago
  A bit ambitious maybe, but I don't necessarily see why breaking changes in Zig would need to be exposed to end users.
- culi 2y ago
  Zig is following a different versioning philosophy. It's not semver, it's https://0ver.org/ https://0ver.org/
  - AndyKelley 2y ago
    Fun website, I like it. I actually gave this some serious thought when I saw it, but, the reality is that every release so far has had major breaking changes, or was a bug fix release. So, that's indeed a fit for semver with the major version zero: > Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable. There's nothing to gain from a different versioning scheme. People just want 1.0 and this is just another way to ask for it. It'll be done when it's done.
  - int_19h 2y ago
    I know that it's not semver, but the notice about the language itself not being stable yet is on the website.
    - otabdeveloper4 2y ago
      No language is stable unless it has an actual published standard. Python certainly isn't stable, for example. (And likely never will be, the devs just don't care.)
diggan 2y ago
> I maybe chose the wrong horse and hopped onto deno early on In the end, it's all JavaScript (or TypeScript if you like Kool-Aid), as long as you know the language you can pretty much effortlessly jump between node, bun and deno, they're more similar than they are different :) Migrating projects on the other hand, well...
- culi 2y ago
  If you're writing production code and not using TypeScript then you're using JsDocs. Which is just TypeScript again
  - diggan 2y ago
    Yup, there is only JSDoc or TypeScript, no alternatives, either before or after. Most of my production code ends up ClojureScript for frontend stuff.
    - culi 2y ago
      the assumed topic here is the node/javascript/bun/whatever ecosystem That's cool that you get to write front-end code in an interesting language though! How long have you been doing that? How big is your team? I feel like larger teams tend to have more boring choices of software
CharlesW 2y ago
> I maybe chose the wrong horse and hopped onto deno early on. After reading through this thread, I'm personally leaning toward Deno for my first non-Node project. Demo seems to be more thoughtfully managed, more pragmatic (e.g. Node/NPM compatibility), more secure, with better technology choices (e.g. Rust vs. Zig) overall.
- culi 2y ago
  I'm still a fan of Deno and hoping it wins out but > more pragmatic (e.g. Node/NPM compatibility) Both projects are good on this front. Deno actually originally explicitly promised NOT to work on node compatibility to "move the industry forward". They realized this was a failing move and backtracked (which has been a little controversial amongst the core base) > with better technology choices (e.g. Rust vs. Zig) I think it's a little silly to take the choice of language as a "technology choice". Both are new languages, both still have a lot to prove, and both have pros and cons the other lacks
- porridgeraisin 2y ago
  > Node/NPM compatibility Bun is miles better in this regard. Deno initially did not even want to focus on Node/NPM compatibility, and then backtracked once they understood the importance of it. Bun OTOH runs the entire Node.js test suite on every commit, and the mentality of breaking less existing node/npm code is clear. e.g, just in this release, `bun publish` has the exact same CLI as `npm publish`, and bun also works out of the box with .npmrc. About the Node.js test suite.. many modules are at 100% compatibility, and many are at 90%. You can track it here: https://bun.sh/docs/runtime/nodejs-apis https://bun.sh/docs/runtime/nodejs-apis Also, they reimplement the V8 public C++ API in JavaScriptCore (!) so that packages like npmjs.com/cpu-features work [1] Every new feature has this aspect to it, e.g the postgres client inbuilt is a drop-in replacement for the `postgres` package. As far as Node/NPM compatibility, and thought given to compatibility in general, is concerned, there is absolutely no contest. And if I'm allowed a little snarky slight... Deno couldn't even maintain compatibility with their own API for reading and writing files during the Deno 1->2 update. [1]: https://bun.sh/blog/how-bun-supports-v8-apis-without-using-v8-part-1 https://bun.sh/blog/how-bun-supports-v8-apis-without-using-v...

by culi 2y ago

int_19h 2y ago

OTOH it's strange to me that they're shipping v1.2, when Zig itself is at v0.13 (and generally considered a moving target).

sampullman 2y ago
A bit ambitious maybe, but I don't necessarily see why breaking changes in Zig would need to be exposed to end users.
culi 2y ago
Zig is following a different versioning philosophy. It's not semver, it's https://0ver.org/ https://0ver.org/
- AndyKelley 2y ago
  Fun website, I like it. I actually gave this some serious thought when I saw it, but, the reality is that every release so far has had major breaking changes, or was a bug fix release. So, that's indeed a fit for semver with the major version zero: > Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable. There's nothing to gain from a different versioning scheme. People just want 1.0 and this is just another way to ask for it. It'll be done when it's done.
- int_19h 2y ago
  I know that it's not semver, but the notice about the language itself not being stable yet is on the website.
  - otabdeveloper4 2y ago
    No language is stable unless it has an actual published standard. Python certainly isn't stable, for example. (And likely never will be, the devs just don't care.)

diggan 2y ago

> I maybe chose the wrong horse and hopped onto deno early on In the end, it's all JavaScript (or TypeScript if you like Kool-Aid), as long as you know the language you can pretty much effortlessly jump between node, bun and deno, they're more similar than they are different :) Migrating projects on the other hand, well...

culi 2y ago
If you're writing production code and not using TypeScript then you're using JsDocs. Which is just TypeScript again
- diggan 2y ago
  Yup, there is only JSDoc or TypeScript, no alternatives, either before or after. Most of my production code ends up ClojureScript for frontend stuff.
  - culi 2y ago
    the assumed topic here is the node/javascript/bun/whatever ecosystem That's cool that you get to write front-end code in an interesting language though! How long have you been doing that? How big is your team? I feel like larger teams tend to have more boring choices of software

CharlesW 2y ago

> I maybe chose the wrong horse and hopped onto deno early on. After reading through this thread, I'm personally leaning toward Deno for my first non-Node project. Demo seems to be more thoughtfully managed, more pragmatic (e.g. Node/NPM compatibility), more secure, with better technology choices (e.g. Rust vs. Zig) overall.

culi 2y ago
I'm still a fan of Deno and hoping it wins out but > more pragmatic (e.g. Node/NPM compatibility) Both projects are good on this front. Deno actually originally explicitly promised NOT to work on node compatibility to "move the industry forward". They realized this was a failing move and backtracked (which has been a little controversial amongst the core base) > with better technology choices (e.g. Rust vs. Zig) I think it's a little silly to take the choice of language as a "technology choice". Both are new languages, both still have a lot to prove, and both have pros and cons the other lacks
porridgeraisin 2y ago
> Node/NPM compatibility Bun is miles better in this regard. Deno initially did not even want to focus on Node/NPM compatibility, and then backtracked once they understood the importance of it. Bun OTOH runs the entire Node.js test suite on every commit, and the mentality of breaking less existing node/npm code is clear. e.g, just in this release, `bun publish` has the exact same CLI as `npm publish`, and bun also works out of the box with .npmrc. About the Node.js test suite.. many modules are at 100% compatibility, and many are at 90%. You can track it here: https://bun.sh/docs/runtime/nodejs-apis https://bun.sh/docs/runtime/nodejs-apis Also, they reimplement the V8 public C++ API in JavaScriptCore (!) so that packages like npmjs.com/cpu-features work [1] Every new feature has this aspect to it, e.g the postgres client inbuilt is a drop-in replacement for the `postgres` package. As far as Node/NPM compatibility, and thought given to compatibility in general, is concerned, there is absolutely no contest. And if I'm allowed a little snarky slight... Deno couldn't even maintain compatibility with their own API for reading and writing files during the Deno 1->2 update. [1]: https://bun.sh/blog/how-bun-supports-v8-apis-without-using-v8-part-1 https://bun.sh/blog/how-bun-supports-v8-apis-without-using-v...