51–60 of 122 posts
Earlier quoted context omitted.
I suspect it’s the latter. I would guess V8 with a thin wrapper and a ton of effort from someone who cares about perf to port all the native goodies of node would get similar wins.
Good thing Cloudflare is open-sourcing their V8-based Workers runtime soon.
Earlier quoted context omitted.
They are roughly in competition, though Deno made the decision early on to largely split itself from the ecosystem and existing conventions of Node (and an enormous body of existing JavaScript packages on npm), whereas Bun did not. Bun, AFAIK, aims to be compatible with Node and existing the npm ecosystem.
Deno already have a node compatibility mode, and will support import npm packages directly.
"Oven, the company behind Bun, has raised $7m in funding" "Oven will provide incredibly fast serverless hosting & continuous integration for backend & frontend JavaScript apps" Isn't trying to dethrone node.js (by making Bun better and more popular) something worth pursuing on its own, or there is no money in that?
Yes, there is literally no money in doing that by itself. I don't blame the developers for doing what's needed to fund the project.
Looked to me that Oven was registered shortly after Bun exploded in popularity.
Earlier quoted context omitted.
I am fairly confident that Zig does not lack memory safety by design; from what I understand, the language as a whole isn't even finished, and the memory safety design isn't like a GC'd language or like Rust, so people assume there isn't memory safety when in reality it is at least partially implemented.
I'm afraid "partially implemented" memory safety is also widely known in the offensive security industry as "not memory safe". Many people have fooled themselves into thinking there is a gradient with safer C++ abstractions, libraries in C, custom allocators, static analyzers, valgrind, etc.
I have a lot of respect for Jarred and bun. The lean approach of just one person working for a year is rather underrated imo. No funding and therefore no pressure for growth. No overhead from scaling up a team and having to implement process, standards, etc. And at the same time, incredible content marketing by just tweeting about every little detail. Me and many others got hooked just because Jarred was posting inte…
It's honestly got me thinking about doing the same thing for my Big Project that I've been squeezing into nights and weekends for the past year and a half
My moneys on Just-JS. It’s consistently in the top 5 fastest web framework (beating out Rust, etc). Just-JS is already faster than Bun. Additionally, JSCore appears to be a significant reason why Bun is faster than NodeJS (V8). Just-JS is investigating switching to JSCore as well - which will only extend its lead. https://github.com/just-js/just https://www.techempower.com/benchmarks/#section=data-r21 https://twitter…
Earlier quoted context omitted.
Ok, but I'm not really looking to my package manager for entertainment. To me this jargon is just needlessly obtuse.
I 100% agree. Cutesy names should end once the package name has been chosen. Package authors and contributors that overdo the thematic names should stick to writing fiction, not code.
My moneys on Just-JS. It’s consistently in the top 5 fastest web framework (beating out Rust, etc). Just-JS is already faster than Bun. Additionally, JSCore appears to be a significant reason why Bun is faster than NodeJS (V8). Just-JS is investigating switching to JSCore as well - which will only extend its lead. https://github.com/just-js/just https://www.techempower.com/benchmarks/#section=data-r21 https://twitter…
Earlier quoted context omitted.
I am fairly confident that Zig does not lack memory safety by design; from what I understand, the language as a whole isn't even finished, and the memory safety design isn't like a GC'd language or like Rust, so people assume there isn't memory safety when in reality it is at least partially implemented.
I'm afraid "partially implemented" memory safety is also widely known in the offensive security industry as "not memory safe". Many people have fooled themselves into thinking there is a gradient with safer C++ abstractions, libraries in C, custom allocators, static analyzers, valgrind, etc.