Live data from Hacker News

Bun 0.6

bun.sh

231–240 of 243 posts

Re: Bun 0.6

#231
post #217

Earlier quoted context omitted.

> I totally get the unholy hell that's (for example) python dependency management, and containers are a great solve for that. [...] What I don't understand is folks that use containers for stuff like [...] nodejs. I mean, it's just an "npm install". With Python it's just "venv/bin/pip install -r requirements.txt". All the tools needed to create an isolated environment (venv) and install packages (pip) come with the s…

Now wait two years, run the same command, and see what happens.

What are you implying will happen?

Using the built-in tools, you can save the exact versions of dependencies (i.e. a lock file) using "pip freeze >dependencies.txt". This should give you the exact same set of packages in two years' time.

If you want to be even more sure, you can also store hashes in the lock file. This has to be generated by a separate tool at the moment [1][2] but can be consumed by the built-in tools [3], so "pip install -r requirements.txt" is still all you need in two years' time.

This is also explained in the pip documentation [4].

[1] https://github.com/pypa/pip/issues/4732

[2] https://pip-tools.readthedocs.io/en/latest/#using-hashes

[3] https://pip.pypa.io/en/stable/topics/secure-installs/#hash-c...

[4] https://pip.pypa.io/en/stable/topics/repeatable-installs/

Re: Bun 0.6

#232

Earlier quoted context omitted.

There are several other languages that could achieve the same speed and performance optimizations. To be clear, I hope to see Zig succeed and I'd like to learn it one day. It reminds me of the video game engine question, only in this case it would be: do you want to build a product, or do you want to build something with Zig? I imagine the creators of Bun answered "we want to use Zig" as their first priority, and tha…

At one point, the Rust team switched away from the performant Jemalloc allocator to something more widely compatible (the system default). They chose to sacrifice performance in the sake of compatibility/stability. It's still available, but optional. https://internals.rust-lang.org/t/jemalloc-was-just-removed-... Insane performance gains, like the ones we see early in Zig, is something that can be easily eaten away b…

Zig, unlike C++ and Rust, doesn't need an optimized general purpose allocator in order to be fast. Zig outperforms its peers despite currently having a slow GPA in the standard library because the language encourages programmers down a path that avoids boxing the shit out of everything, which is inherently slow even if you have a global allocator optimized for this use case.

Rust switched away from Jemalloc because it uses global allocation for everything. Zig's convention of explicit allocator argument passing means such a compromise will never be needed.

As for "beating trees with a stick", I'll probably end up doing what I did for WebAssembly, which is to ignore the preexisting work and make my own thing that is better. Here's my 160-line wasm-only allocator that achieves the trifecta: high performance, tiny machine code size, and fundamentally simple.

https://github.com/ziglang/zig/blob/c1add1e19ea35b4d96fbab31...

Re: Bun 0.6

#233

Earlier quoted context omitted.

Is 90MB really that big when compared against the other types of binaries that would get deployed: containers and VM images? How big is the platform (k8s, docker, etc) you need installed to run your app? Probably more than 90MB.

A native Java "Hello World" can be around 8MB in size.[1] So, yes, 90MB is too much. 1. https://sergiomartinrubio.com/articles/getting-started-with-...

Part of that I imagine is the same problem deno has.

ICU locale data is pretty hefty and there aren't says to trim it down.

Re: Bun 0.6

#234

Earlier quoted context omitted.

Not to mention, you can get better compression with some pre-compression levels that are hard to match with the best on the fly, often getting another 10% or more on size. It all adds up. There are some Steve Souders books on optimization that are pretty good and still pretty relevant.

If you minify, aren't you increasing the overall information entropy, and thereby decreasing the amount that can be gained from compression? I'm sure overall there's still a net gain but I wonder where the point of inflection is.

Depends on the algorithm... the ones used with http typically have less overhead for decompression than compression.

If you mean code minification, that can depend, but in general with tree shaking it shouldn't be slower, typically. The computer doesn't care if a variable is aa or myDescriptiveVariableName.

Re: Bun 0.6

#235

Earlier quoted context omitted.

It doesn't HAVE to be that bulky or complex. You have a lighter space like Dokku or just direct scripted deployments pretty easily. As to the size, you can use debian-slim or alpine as a base for smaller options. There's also bare containers, or close to bare for some languages and platforms as well (go in particular).

What's even "lighter" is a single binary sitting in /home/app running under "app" user and launched by systemd unit file with auto restart. Look, I totally get the unholy hell that's (for example) python dependency management, and containers are a great solve for that. Sometimes you don't have a choice of technology, so I get it. What I don't understand is folks that use containers for stuff like go binaries. Or node…

You get a lot more from containers than just dependency management. You get isolation options for everything related to i/o from disk to network. As well as hard CPU/Memory controls. It's a few steps above what you get with chroot, etc.

There's plenty to like about containers.

Re: Bun 0.6

#236
post #137

Earlier quoted context omitted.

I deployed a small non critical service with bun. So far constant (but slow) memory leaks and an 80% chance of segfault when starting up. Will try a few more versions of bun then move it to node for a while until bun matures a bit.

wow thats rough i'm sorry can you file an issue with some code that reproduces it? will take a look

I did upgrade to bun 0.6.1. Haven't seen the segvault on startup yet but still seeing the memory leak. Maybe even slightly faster than before. Will check my code to see if it could be causing the issue.

Re: Bun 0.6

#237
post #165
post #49

Earlier quoted context omitted.

It becomes a political issue at this point w/ battling the ops team. I have more important battles.

If it's a battle by all means avoid it. But it's weird that your ops team would care about the image type. The whole point of containers is that they don't need to care.

I guess I should have said infra and not ops. But cost cutting has interesting implications on responsibilities :)

Re: Bun 0.6

#238

Earlier quoted context omitted.

Browsers weren't written in a day. Technically speaking, Mozilla Firefox is a ship of Theseus going back to the release of Netscape in 1994. Did browser and internet infrastructure developers in the early 90s understand that these things would become rich application platforms? Looking at the history of HTTP, it's clear that they expected some concept of "application" to be delivered through the browser. While there'…

Was Google Maps the first JS-heavy app? That's a TIL for me..

No it was not. There were many, but for me the most significant early single page app was Outlook web access.

A colleague of mine went diving through the JavaScript source and found a reference to an ActiveX component called XMLHttpRequest. We realised it was pretty useful and ended up using it to build an SPA that approximated a spreadsheet for global logistics planning. It worked very for 2003 standards.

Google maps came in 2005

Re: Bun 0.6

#239
post #224
post #168

Earlier quoted context omitted.

> and, frankly, why would you write `.js` in 2023? It's surprisingly convenient for munging around random json files or calling random apis that return json (or for dealing with an interaction between the two), especially now that fetch ships with node.

JSON is great, for sure, and "calling random APIs" gets even better with type definition autocompletion!

If you make me start statically typing the random scripts I write to munge data round to answer business questions, I quit.

Re: Bun 0.6

#240
post #216

Earlier quoted context omitted.

There's no JVM when using GraalVM Native Images, it relies on a JVM during the compile step (well, specifically GraalVM), but produces native code similar to compiling C. There's no virtual machine running bytecode, just entirely native code. So the size of the executable will depend on how many features of the JVM you need compiled into your executable. A pure java bytecode (bring-your-own-JVM) Hello World can be un…

The hello world .class file is 413 bytes, just as an info.

Thanks, smaller than I remembered. Been a while since I've done any Java so I aimed a little high.
Post reply on HN