Bun v0.7.0(bun.sh) |
Bun v0.7.0(bun.sh) |
> bun --smol is a new CLI flag which configures the JavaScriptCore heap size to be smaller and grow slower, at a cost to runtime performance. This is useful for running Bun in memory-constrained environments.
From the example they gave (https://i.imgur.com/IDHTaAh.png):
Bun 343 MB
Bun with --smol 54 MB
Node.js 138 MBThe bot is rarely used, so on average, it only uses 0.06% of my machine's CPU power. However, it consumes 3% of the RAM at the same time. --smol switch according to Jarred's tests reduces memory usage ~7 times by increasing CPU usage just 2x times. In my case such redistribution of resource consumption would be a clear win!
To save RAM, I actually switched to a 32-bit Python base image. This switch resulted in a 30% reduction in RAM usage.
Maybe launching lots of separate services/containers locally, just to have the ability to debug everything and step through how a request travels through all of the services in one go, with multiple IDE instances also open locally, in addition to other stuff?
Distributed tracing is nice for remote environments, but having 5-20 IDE instances open with all of the related services can also provide a nice debugger experience. Not every machine has ample RAM for this, though, so I guess it's nice to have the option, without the processes/containers running into OOM so much?
If some significant portion of the user base is as slang-ignorant as I am (for example, most who speak English as a second language!), it'd be good to support both --small and --smol for mnemonic reasons. Remembering a series of letters that have no meaning to you is much harder than remembering a word that obviously relates to what you're trying to accomplish, and if I had landed on the bun docs first I would have continued pronouncing it "es em oh el".
However from the outside in, if an alternative runtime was to steal the show so to speak, then Bun looks like it might be able to do it.
- Full interoperability with the existing ecosystem
- Typescript and JSX as first class
- Blazing fast compile times
- Can serve a very large number of concurrent requests
- And a standard library that does as much as the go stdlib
Someone please tell me why this is a bad project, because so far I want to jump in.
Bun is written in Zig while Deno is in Rust.
edit: I find this to be a big differentiator for those wanting to better understand how their tools work and hack/propose code changes when desired.
Nevertheless, have moved on to Go for servers so I don't really feel the need to go back to a Typescript/Javascript environment again. Rust is awesome for low level stuff. So quite happy with the combo of Go (for servers) and Rust (for everything else backend).
I’m also still a little lost on the “why” of Bun. I respect the tech a ton having noodled around with the JavaScriptCore API myself in the past. But I’m not sure why I’d use it over Node.
Not likely. Bun doesn't use v8.
And if Bun has to go the way of NodeJs nothing will likely happen as well. Bun can move fast because there aren't as many stakeholders, committees and all sorts of gatekeepers in the way.
nodejs devs are firm on "this proposal is betteer kept in userland than within nodejs" approach, which also kept their ecosystem stable and predictable at most times.
Bun + RabbitMQ + BunnyCDN + Apache Jackrabbit for the Lagomorph stack.
LAPTOP-162NUQO7:~$ curl -fsSL https://bun.sh/install | bash
######################################################################## 100.0%
bun was installed successfully to ~/.bun/bin/bun
Manually add the directory to ~/.bashrc (or similar):
export BUN_INSTALL="$HOME/.bun"
export PATH="$BUN_INSTALL/bin:$PATH"
To get started, run:
bun --help
LAPTOP-162NUQO7:~$ ~/.bun/bin/bun
Error relocating /home/lewis/.bun/bin/bun: unsupported relocation type 37
Error relocating /home/lewis/.bun/bin/bun: unsupported relocation type 37
Error relocating /home/lewis/.bun/bin/bun: unsupported relocation type 37I'm also wondering if some old benchmarks could now be irrelevant.
We might enable —smol by default though.
The garbage collector configuration in JavaScriptCore is still kind of a mystery to me. I think we would ideally have something in-between —smol and default. I expect we will fiddle with this more shortly before or after 1.0
https://medium.com/walmartglobaltech/react-native-memory-pro...
If you're looking to currently build a larger scale project with a few people that supports a lot of users, it's safer to go with nodejs/typescript.
I can get all the help text displaying but there's no output or error when running a JS file with the latest release (or even one from last year).
The latest Deno release works out the box with Code Interpreter. There might not be much benefit to running Bun over Deno but if like to try.
Update: the bug is likely due to Code Interpreter using a 4.4 kernel, which is 7 years old!
> Why is it binary?
> In a word: Performance. Bun’s lockfile saves & loads incredibly quickly, and saves a lot more data than what is typically inside lockfiles.
> How do I inspect it?
> Run bun install -y to generate a Yarn-compatible yarn.lock (v1) that can be inspected more easily.
It seems bun is:
Zig 52.0%
C++ 19.2%
JavaScript 14.6%
TypeScript 12.1%
...
which is an interesting mix. I assume the JS is intended to be TS eventually or actually is right now. But why all the C++?
> Bun is an incredibly fast JavaScript runtime, bundler, transpiler, and package manager — all in one.
The answer usually is there's a bunch of IO/parsing/configuration that we need to do, and doing that in a lower-level language isn't that much faster overall, is much less maintainable or accessible for users than wrapping in a scripting language, or simply avoids the need for recompiling each time you want to modify something (e.g. game engines with a high-level scripting component).
Abstractions are needed to simplify the problems of a particular stack.
If that weren’t the case then we would all still be punching machine code directly into computers.
Deno's desire to rethink server-side JS adds friction in service of goals I don't value. They're gradually giving ground their aspirations (e.g., in my memory it was previously a point of pride to not interoperate with NPM), but it's still not a drop-in replacement and I don't think they want it to be.
Bun's goals align with mine, so it's the one I prefer using.
What are some viable options that communities have had success with?
I'm a bit curious how the oven-sh will make money in the long term. It looks like you are getting funding at the minute, but at some point will users need to pay for this tooling?
> Oven will provide incredibly fast serverless hosting & continuous integration for backend & frontend JavaScript apps — and it will be powered by Bun.
I have looked a bunch of times at how hard it’d be to import the DOM APIs from WebKit/Safari and would really love to if it didn’t also mean pulling in most of a web browser
I think happy-dom is good for DOM-like testing though.
how's the compatibility with web frameworks? when will nextjs 13 be supported?
With the face on it, I can't help but think of the Pixar short Bao: https://www.pixar.com/bao
I read this with a Spanish accent and it gave me a good laugh.
It’s also worth noting that even their abridged description would be too long to use as the title string in HN. So what you’re asking for isn’t even possible on this forum.
And thanks for the UWU.md idea, love it!
This sort of gatekeeping over programming culture and aesthetic is only causing the community to further splinter between people with sticks up their asses and people who just want to have fun and enjoy life.
because commercial platform decides to block searchbot indexing and once again content vanishes.
Or a user merely wishes to remain anonymous & that shouldn’t be a problem for them (provided they are acting in good faith).
All options can by bridged to all other options (even the proprietary ones) in some manner, but if possible, the defacto server would be FOSS & owned/operated by the community so that that community can define their ToS and/or CoC. This way they are in control of the community rather than requiring users agree to someone else’s—especially a for-profit US corporation’s—terms in order to participate. Some users will want privacy, anonymity, control of personal data, or to get around a firewall/sanctions …and these desires should be considered acceptable. If not self-hosted (requires time/money), it’s still better to choose something using open protocols, like a space on Matrix.org, a big chatroom on XMPP’s Blabber/Conversations, Libera.Chat/OFTC, etc.
Your assertion about the title is not correct, either. Try it. These titles fit into the limit:
"Bun v0.7.0: a fast JavaScript runtime, bundler, transpiler, package manager"
"Bun: an incredibly fast JavaScript runtime, bundler, transpiler, package manager"
It's time to stop silently putting up with useless titles, and WAY past time to stop attacking those of us who don't.
What does UWU means? Why using an artificial language instead of established one?
Let's turn this around. If the flag was called --cutesy-wootesy-fartsy, would you still argue it's approximately the same amount of information? If not, can you explicitly explain why not?
I'm writing out a bunch of notes for a technical screen in an UWU.md file right now (even if I'm definitely not shipping it to them like that)
You can sometimes say something is objectively bad: You shouldn't name your class `Car` if it models a boat. It's unrelated.
However to argue about "small" vs "smol" is a matter of pedantry. And it's further trivialized by the fact that "smol" is part of a well-established lexicon of a large demographic. Eventually you'll see it in Merriam-Webster. But if the argument is "it must be in Merriam-Webster", that's textbook gatekeeping.
Personally yeah I think it's better as an alias. I'm actually all for having fun with programming, but if you want your product to be useful you have to consider your audience. I'm much more likely to stick a joke name on an internal facing function, where I've got a strong reason to believe that everyone who sees it will be in on the joke. Or a piece of software that is itself for fun. Something that's meant for actually getting work done should generally not use naming that gets in the way of that.
> The notion of a "bad name" is evidence of aesthetic gatekeeping.
I mean that's objectively not true. You even provide an example in your next paragraph of a bad name. Another would be taking using md5s of descriptive names and using that. I mean md5 is broken and reversing it is fun and nerdy right?
When talking function names and program arguments, names which convey their purpose are better than those that don't. It's not gatekeeping, it's designing effective interfaces.
Having your own aesthetic preferences doesn't mean there is a stick up your ass.
But, if you were to claim, as others have, that this is an affront to programmer etiquette, that this product has a mandate to change it, then you might.
>> Something that's meant for actually getting work done should generally not use naming that gets in the way of that.
Like this. The case that "smol" is getting in the way of getting work done is just silly. No one is shoving their culture down your throat, but if you like Deno then you should be ready to also accept the culture established by its developers and not demand that one word be used over another of similar meaning, after it's established. There are other options out there for people who absolutely cannot be near and nonsense while working.
>> You even provide an example in your next paragraph of a bad name.
I established the difference between a pedantic situation and a genuinely unrelated name. This is nuance that most software developers are able to grasp.
>> When talking function names and program arguments, names which convey their purpose are better than those that don't. It's not gatekeeping, it's designing effective interfaces
`--smol` does this. It just happens to not be as well-known a word, but it is in fact an established part of the lexicon of an entire culture. That culture produced Deno, and being encouraging and accepting of these difference makes our little nerd corner of the internet just a bit cooler and more culturally diverse.
There is absolutely nothing from stopping anyone from joining the Deno collaborative process and creating a GitHub issue that requests a change. But if the maintainers find they prefer `smol`, it should end there and not become a constant struggle brought on by non-maintainers. And seeing as how it's been brought into the engine already, that is a sign that a consensus has already been reached at least once.