> 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.
This is cool but I'm struggling to think of a case where I'd want to run backend JavaScript in a memory constrained environment, doubly so where performance isn't a concern.
I have an example for you. I self-host a Telegram bot, which is written in Python. However, I believe that if it were written in JavaScript, the situation would be similar.
The 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.
Full process/container isolation for many instances of untrusted code, perhaps? A serverless PaaS could use this to cut down significantly on the frequency of cold starts, all else being equal.
> This is cool but I'm struggling to think of a case where I'd want to run backend JavaScript in a memory constrained environment, doubly so where performance isn't a concern.
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?
The macbook air only has up to 16GB of memory right now. There's plenty of cases where one might want to run a javascript script on their laptop which uses quite a bit of memory, and they'd rather it complete at all, even if it's a bit slower.
My browser is already eating half of the 16 GiB of RAM I have on my laptop. I definitely don't need random small command-line tools which eat >300 MiB of overhead each. So far I am a happy non-user of Electron apps.
Uninformed spitballing here but I can totally imagine brewing up an eInk display that grabs X from the internet then draws something via the Canvas API. JavaScript would probably be a fine solution for that.
Yeah, and how is this different from the behavior V8/JavaScriptCore would already have on a system with very little memory? Unless this actually makes it possible to run on lower-memory systems than before, I don’t really see how it’s helpful. Unused memory is wasted memory and all that. I hope it’s using every last byte, not letting memory sit unused.
Maybe I'm dating myself, but it took reading these comments for me to figure out that "smol" is pronounced "small" and not "es em oh el". Only after that did I think to Google it and find the dictionary.com slang entry [0].
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".
This has nothing to do with enterprise, it's about accessibility. For most people on the planet English isn't even the first language and now you expect them to know about obscure wannabe-cutesy internet slang? Fuck that shit, what's next? UWU.md instead of README.md?
English isn't my first or even second language. --smol creates a lot of confusion in my head. It doesn't even make any sense. Why not --less-ram or similar?
What does UWU means? Why using an artificial language instead of established one?
To me, --small gives much more information. I immediately assume that it means something is smaller than the default, memory makes immediate sense. --smol on the other hand could be an acronym or a technical word I just don't know, the likelihood of random internet slang actually being one of the first interpretations seems low for most engineers.
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?
People like you make me want to code only in Brainfuck.
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.
The notion of a "bad name" is evidence of aesthetic gatekeeping.
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.
TIL I have a stick up my ass. I'm US born and didn't know what smol was until today so I'm not sure I buy the "large demographic", but it's always possible I'm out of touch.
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.
Not knowing some internet slang doesn't mean there is a stick up your ass.
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.
If weebs are in, then I am out. Consider this my final farewell. Mods don't even ban AYAYA anymore. 40 year old men thinking they are little anime girl. Thinking they are cuties
Why not? The audience is people who are deploying JS apps. Such people likely have access to the internet and are able to google "smol" if they want to know what it means. I'm not a first language speaker of English either, the system language on my phone is not English, if I google "smol" it immediately give me the translation into my system language. It takes no time at all.
It's not bad, it's just still too early to "jump in", except to be an early adopter and perhaps one of the go-to experts when the bulk of the user developers come on board. The price for that is to always be prepared to refactor anything you build at this stage.
Bun is awesome. The only thing missing, for me at least, is streaming support (specifically for Server Sent Events [1]). Not sure if this release fixes it.
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).
The inevitable question: what does Bun do that Deno doesn’t and vice versa? Competition is always good and I applaud it heavily. What is Bun’s killer feature over Deno and why would I pick Bun over Deno for a new project?
Personally, I like that Bun aims to be "Node, but better". That's all I ever wanted.
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.
In a word: pragmatism. Bun is pragmatic where Deno is “by the book”. Node.js globals like process are Bun globals. You can use require() and import in the same file. Bun is faster, easier to use, and more compatible with the JavaScript ecosystem. There’s less new stuff to learn. And that also makes Bun easier to try in new and existing projects.
When will communications beyond the proprietary Discord be opened up to something FOSS & trustworthy for folks concerned about privacy or under sanctions?
IRC is very low bandwidth & offers the minimal requirements for communication which can be accessible/acceptable for many projects. If something heavier is needed or wanted, XMPP MUCs & Matrix Spaces may be a good option since they are federated & decentralized (although Matrix has unfortunate defacto centralization around Matrix.org, because it requires quite a lot of resources to self-host in both the Python server as well as mirroring all content for all users for its take on federation). Mattermost & Zulip are fine, but require an account (I believe) to the central server but are FOSS & used enough places to be considered stable/trustworthy.
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.
I'd second the recommendation for Zulip. It's pretty similar to Slack/Discord, but unlike those it has good support for making the archives public. It also has much better threading support, which is a nice bonus.
It’s expensive to self-host, and centralized if using Matrix.org. It has its uses, but XMPP MUCs have a lot of overlapping features & Prosody/ejabbard can run on a potato by comparison.
It might be expensive for an organization to host, but for individual / small groups it can be as low as $6/mo. I've been running a small Matrix server on a DigitalOcean droplet for years now, and the $6/mo plan has been working fine for 5 users, and three bridges running on that server.
I believe all messages/multimedia from all users & the history all the rooms & private messages need to be mirrored which can end up being a lot even with a few users depending on what they’ve joined. If my understand is wrong tho, I’d like to know so I’m not running around with this notion.
I really like this project and will have to try it at work.
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.
Does Bun have a built-in DOM Parser? In Nodejs it's horrendously slow using JSDOM and Linkedom is a great effort but still about 20x slower than a browser. Keep up the good work Jarred.
The closest thing we have builtin is HTMLRewriter, which is more of a tool for transforming HTML than for traversing.
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.
Thanks HTMLRewriter actually fits my use case perfectly. I don't need canvas and complicated stuff like that. Just the ability to parse some html and strip out certain things.
Tried the latest version. Axios is broken. But that's an improvement from the last time I tried to run one of my backends. I'll keep an eye on your progress.
Expecting SvelteKit & SolidStart end of next week. Maybe Next 13 in two weeks. A lot of frameworks work today in the release builds, it’s the dev servers which are harder for us right now.
I can’t imagine a merge ever being on the cards. io.js was a fork of Node so merging it back in was a relatively simple proposition. Bun uses an entirely different JS engine so a merge would be horrendous, it would be more like a ground up rebuild.
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.
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.
I don't think it will merge. After deno nodejs is getting similar features like native fetch, web stream etc. Similarly nodejs can just implement buns unique features
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 37
The heap size grows faster & stays larger in the default configuration, adjusted for the amount of memory the computer has
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
Using more memory to increase performance is a good thing. All software should be doing it, especially one that is meant to run server-side. Who cares if Bun takes a couple hundred MBs extra (which is worth like $0.20)? It is also like 5-20x faster than Node for basic tasks because of it.
Not having much luck running non-strict Node.JS classic scripts in Bun using CommonJS/require. Errors about strict mode despite not using "use strict";. Is there a flag to allow such scripts to run?
Bun internally treats most CJS modules as ESM, mapping require() calls to synchronous import() etc. And ESM is always strict mode, so that might be the issue?
Bun is not able to run non-strict javascript and there is no documentation that suggests it will be supported. No choice other than running Node.JS for this.
We really care about performance and spend probably way too much time on it. I think caring a lot is a good way to fight against the longterm default trajectory of software becoming bloated & slow over time
Many of the web APIs in Bun are generated code from WebKit/Safari, which uses C++. We copy them into Bun, comment out the web browser parts, and ship them in the runtime. This is great for web compatibility because it’s literally from a web browser
I'm not conflating anything, and never mentioned a summary. I don't know if you're using a specialized application to view this site or something, but in a regular browser there's no summary. There's only the title, and this one neglects to say what the thing is.
My point was that you’re misunderstanding what a title is. If you want to understand more about something then you should click the link. Not complain that all the detail isn’t in the title.
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.
I'm not misunderstanding anything. It's easy to put a short description in the title. To deny this is to promote making HN useless, since scanning its pages will tell you nothing and you would have no way to skip things you're not interested in.
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.
Is it only me that finds it strange that engineers working in a particular language will get another language to solve issues with said language? e.g. Javascript using C, C++, Zig, Rust, etc. Ruby and Python is also similar situation there are tools, libraries and such built in other languages
This is the way any interpreted language works, the interpreter has to be written in something and for good performance this has to be a compiled language
"RPython is a subset of Python2 that can be statically compiled. The PyPy interpreter is written mostly in RPython (with pieces in Python), while the RPython compiler is written in Python." - https://rpython.readthedocs.io/en/latest/getting-started.htm...
I don't think it's strange. A programming language should focus on a specific problem domain, and not try to solve problems outside that domain (not that Javascript is a particular good example of that philosophy though).
One could flip that question around: given there's all these fast C/C++/Fortran libraries, why do we have all these scripting languages?
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).
It’s the same reason people will use Vue or React instead of writing their own frameworks for each and every website. Or why people target Windows or macOS instead of writing their applications to run on bare metal.
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.
> 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):