181–190 of 243 posts
This seems like the most obvious thing yet to be built.
I wonder how hard it would be to take an existing systems language and add TS syntax to it. Seeing as they are all built on LLVM. Or maybe you could transpile TS to Zig.
Earlier quoted context omitted.
And NodeJS too https://nodejs.org/api/single-executable-applications.html
There is also https://github.com/vercel/pkg
Glad others are finding value there, but i wish it was more of a drop-in replacement for `node `. Feels similar to `ts-node` (always having issues) and `tsx` (just works).
Earlier quoted context omitted.
Yeah, this is honestly one of the things that turns me off of containers in general. Like, the whole point was to effectively use linux kernel namespaces with cgroups in an intelligent way to give VM-like isolation, but non-emulated performance - and supposedly not having to deal with image size bloat from the OS like you get in VMs. What we got was an unholy mashup of difficult to debug, bloated images and ridiculou…
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).
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 nodejs. I mean, it's just an "npm install". Or now bun with it's fancy new build option, you don't even need that.
I honestly don't get the point of containers with languages that have good dependency management, unless you're in a big matrix organization or something.
Or, as one HN user put it years ago, "containers are static compilation for millennials".
I snorted beer out of my nose the first time I read that.
Earlier quoted context omitted.
Nah, rust still depends on libc at runtime which is a pain. Go doesn't have this problem afaik as it has its own stdlib and runtime.
> Nah, rust still depends on libc at runtime which is a pain. It does in general, though I don't really think this is a big pain or blocker in the general case, there are very version requirements around libc. > Go doesn't have this problem afaik as it has its own stdlib and runtime. That's also true, but it's not really a pure win. Choosing not to use a battletested libc has led to a variety of subtle and difficult…
Earlier quoted context omitted.
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-...
“The generated file is 7.7MB, which is quite impressive for a Java application since this executable does need a JVM.” I assume this is a typo and they mean “does NOT”?
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…
There are plenty of good reasons to containerize even a single binary executable, as demonstrated by the fact that officially maintained images exist for containerizing processes like Postgres or haproxy. Sure, you could run both Postgres and haproxy as services directly on the host, but then you'd miss out on all the benefits either provided by or complementary to containerization, like isolated cgroups and network namespaces that make declarative service orchestration easily achievable with maintainable configuration.
`bun` is currently my favorite "just works out of the box" utility for running Typescript programs. I've tried a couple and struggled with configuration and, on top of it all, bun is simply faster. So, if you want to write a bunch of `.ts` files and point something at them, I really recommend `bun` (and, frankly, why would you write `.js` in 2023? Probably because you've not tried bun. Edit: I don't care about bundle…
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.
yeah 90MB for a hello world is big. Approximately 2,700 times bigger than it could be.
What's the point in looking at size ? I can see two:
- want to email the exe, and you have limits on mail size - want to be ecofriendly, in that case stop watching netflix for 2 hours and you'll have your megs
Earlier quoted context omitted.
Doing it without glibc is not practical
why?
Earlier quoted context omitted.
Is the JVM inside that 8MB then I guess? That is pretty great. Originally I thought the alternative was “8MB but supply your own virtual machine.”
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…
That's very misleading. For one, Java running native still needs a Garbage Collector, maintains Object headers which increase memory usage, can do things like reflection for configured classes, can load services via the ServiceLoader, schedule Threads and manage executors, and many other things that are "expected" to any Java application... in summary: native executables still have a Java runtime embedded into them (called Substrate VM, by the way), making them very different from C (much more like Go).
Also,notice that native Java executables still tend to have a lower "peak performance" (i.e. once a "normal" JVM has warmed up, it will almost certainly be faster than a native executable because the latter cannot do JIT compilation to take advantage of runtime profiling, like a normal JVM does).