12 ms·

Hello World

212 points by ddevault 7y ago

phoe-krk 7y ago
What is this post supposed to prove? It certainly is not supposed to prove that a hello world is a representative real-world program, from which one could infer that writing and debugging a real-world program in Julia is 835 times as complex as writing a real-world program in assembly, since the former makes 835 times as many syscalls as an assembly program. (You know, that number seems okay for me, except it needs to be applied to these languages in reverse.) I agree that software bloat is a big problem, but trivializing that problem to printing a "hello world" to the screen, punishing all languages with runtimes by measuring the syscalls involved in their startup routines, disregarding the fact that many users are going to have a single system-wide runtime for e.g. C or Python or Julia and therefore the total-kB number does not scale linearly with the number of programs written in C or Python or Julia, ignoring the massively increased software development and debugging time for writing in low-level and memory-unsafe languages like assembly, static Zig, or C, and directly implying[0] that most problems with software complexity can be solved by writing in assembly, static Zig, or C rather than in Julia/Ruby/Java/all other languages from the bottom 90% of the list (and that's the vibe that this post gives me) is, for me, more about making a venting shitpost than creating something that provides even a part of an actual solution to software bloat in general. The "more time your users are sitting there waiting for your program" statement is especially amusing to me. Your users are not going to wait shorter for your program because you and your team are taking another year to write, test, and debug it in assembly. [0] "These numbers are real. This is more complexity that someone has to debug, more time your users are sitting there waiting for your program, less disk space available for files which actually matter to the user."
- ajkjk 7y ago
  It could just be trying to be interesting, not to prove anything.
  - phoe-krk 7y ago
    Why is it attempting to moralize if it is not meant to prove any morals then?
  - hn_throwaway_99 7y ago
    The language in the post, "Most languages do a whole lot of other crap other than printing out “hello world”, even if that’s all you asked for." certainly seems to imply it's moralizing about something.
- overgard 7y ago
  If your compiler generates something huge for the most basic test, how can you trust it's doing well on actual programs? Most real programs are far too complicated to analyze. It may be a toy example, but if your language can't handle a toy, it's probably bad on real world programs also.
  - jefozabuss 7y ago
    This example is not too relevant because the overhead is probably the additional tools (e.g. debug, error handlers, etc), there should be multiple examples for a normal comparison, e.g. 3-4 examples of more and more advanced code since then maybe these numbers would increase in a similar fashion.
  - phoe-krk 7y ago
    You have a weird definition of "handling". A high-level language performs the same amount of work as the lower-level one - I cannot see a language listed in the blogpost that has failed to display a command in the console. It's the lower-level languages that, for the sake of efficiency and minimalism, cannot handle systems larger than a hello-world and actual programs written in them without long development times and a mass of bugs that come straight from their inability to abstract when necessary and from their memory management systems that lack sanity and safety. This "simplicity"[0] is often fetishized, and this blog post looks no different to me - look how many overflow bugs in operating system kernels this "simplicity" has caused. Or, paraphrasing your quote, if your language prevents you from creating most basic abstractions, how can you trust it's doing well on actual programs? [0] I can agree, writing in a memory unsafe language is simple, as long as it's someone else who maintains the code you wrote, accepts or reroutes all of the bugtickets that happen, and analyzes heisenbugs that come from weird memory corruptions caused by unsafe code.
    - overgard 7y ago
      > A high-level language performs the same amount of work as the lower-level one No, uh, the high level language performs way more work. It just happens that most of that work is useless. You seem to be unclear on the definition of efficiency, so let me spell it out: it's not about getting the work done, it's about getting the work done in the minimal amount of steps. That's why this is a good test: there's a clear boundary of "minimal amount of work". > It's the lower-level languages that, for the sake of efficiency and minimalism, cannot handle systems larger than a hello-world and actual programs written in them without long development times and a mass of bugs that come straight from their inability to abstract when necessary and from their memory management systems that lack sanity and safety. Yes, nobody has ever written a complex program in C. Excluding every OS and every important desktop application, I guess. Yeah, it's more work. Sometimes doing something hard takes more work. > Or, paraphrasing your quote, if your language prevents you from creating most basic abstractions, how can you trust it's doing well on actual programs? You're right. Let's rewrite the Linux kernel in Ruby. C just isn't up to the task. As an added bonus, all our computers will now have the benefit of working as excellent space heaters!
- einpoklum 7y ago
  > What is this post supposed to prove? It proves that the compilers for many programming languages emit a lot of instructions and a lot of system calls they could have optimized away theoretically. This is particularly true when there are lots of "startup routines". When the program to be run is known, almost all of that startup can be found out to not be necessary, and stripped from the final executable. > Your users are not going to wait shorter for your program because you and your team are taking another year to write, test, and debug it in assembly. They might, if your program is interactive and is used often enough. Now, writing assembly is not very realistic, but considering a different language with less overhead - is.
  - phoe-krk 7y ago
    > they could have optimized away theoretically. For a hello-world program, this is true, you do not need any of the features that usually come in the language runtime - no garbage collection, no runtime memory safety, no runtime introspection, et cetera. This stems directly from the fact that many of these languages have borrowed features from Lisp, which has the whole language (GC, compiler, debug functions, etc..) always available for the code. And that, considering your point of view, might be a feature, not a bug - especially if your program, having a runtime of its own, actually produces its own stacktrace, allows you to interactively inspect values of variables throughout the stack, and - in case of some runtimes - is capable of opening up its own debugger for you to perform introspection and issue analyzing in.
    - saagarjha 7y ago
      > This stems directly from the fact that many of these languages have borrowed features from Lisp, which has the whole language (GC, compiler, debug functions, etc..) always available for the code. Right, I think the point was that this isn't always necessary, in which case it becomes extra baggage that you have to carry around.
  - hokumguru 7y ago
    For all the daily articles that pop up here on HN concerning premature optimization I find it surprising to see this thread and all the sentiment of language choice mattering. It’s far easier to work in and translate thoughts to more feature rich languages. The vast majority of the time it’s not the language itself that will be an optimization issue down the line but rather the written code.
- jhoeriutre 7y ago
  It's the software developers equivalent of virtue signaling. Some people get outraged that OTHERS use plastic straws, and wiggle the finger at them for being bad persons while pointing at their VIRTUOUS paper straw. Some programmers get outraged that OTHERS write bloated programs in Python/JavaScript/Electron, and wiggle the finger at them for being bad persons while pointing at their VIRTUOUS C/Assembly/native GUI app.
- deleted 7y ago
  [deleted]
- 3xblah 7y ago
  "What is this supposed to prove?" Perhaps it proves that if one is writing relatively small, simple programs, some of these languages are overkill.
deleted 7y ago
[deleted]
NilsIRL 7y ago
It would be interesting to know why the number of syscalls for C are so high.
- gerikson 7y ago
  Which version of C?
  - zamadatix 7y ago
    All versions are interesting, zig/assembly managesto do it in 2/3 so what is musl doing that needs 5? And what on Earth is glibc dynamic doing that it needs 65?
- BearOso 7y ago
  I’m wondering why his dynamic glibc C executable is so big.
  - kungtotte 7y ago
    He's counting glibc too, not just the binary. This is true for all of the examples, the size is the binary itself plus whatever system/libraries you'd need to actually run the binary.
lttlrck 7y ago
It’s comparing unassembled assembler to JITed code and compilers that are pulling in precompiled libraries. I feel it needs some kind of normalizing. I get that it is illustrating bloat but it doesn’t really illustrate where that’s coming from. Maybe only the output of the JITs should counts, or the syscalls required to assemble the example should be included. Are musl and glibc really wasting cycles or are they doing something that the example is missing. Fun to think about.
- ddevault 7y ago
  It's deliberate that JITs, interpreters, and compiled languages are compared on the same terms here. JITs and interpreters are fundamentally less performant than compiled languages, they don't get a pass on performance tests just because it's by design.
  - joshuamorton 7y ago
    > JITs This is...highly context dependent. For highly polymorphic code, my understanding is that JITs can outperform precompiled binaries, since they can inline virtual/polymorphic calls in tight loops. This also isn't a "performance" test in any real sense. It's a test of startup time. Where, yes, JITs lose, but unless you're writing short lived interactive command line tools, or something that runs on lambda, that shouldn't be a concern. For "normal" serverside or desktop apps that run for more than, say, 30 seconds, the difference between 0s of startup and 0.2s of startup time is literally in the noise.
    - ddevault 7y ago
      Startup time is the least interesting metric in this article. The more interesting metric is the number of syscalls. This isn't a measure of performance, it's a measure of complexity and busywork. Complexity tends to indirectly affect performance, but that's not the point of the article.
      - joshuamorton 7y ago
franciscop 7y ago
Random thought/question, does `process.stdout.write("Hello World");` in Node.js make any difference? While `console.log()` is correct for this analysis since it's the more common one, it does a lot of extra internal logic: https://github.com/nodejs/node/blob/v13.x/lib/internal/console/constructor.js https://github.com/nodejs/node/blob/v13.x/lib/internal/conso... Edit: I'm just curious and don't know how to even start testinng this, not trying to promote/demote Node.js in any way.
- np_tedious 7y ago
  If it is any better, it probably would be the more fair entry (and perhaps similar for python and stdout/bytes) since Go's example did basically that instead of fmt.print with a string
- zamadatix 7y ago
  I would be surprised if console.log() made many more syscalls than process.stdout.write. More function calls probably but those aren't being counted and neither is RAM usage. "strace" would let you count and find out though! The size would be a few bytes larger since node is scripted and that's more characters.
- TheNorthman 7y ago
  I'm not able to reproduce the authors results (nor reliably ANY result) but you're right. Using `strace -c node -e <code>` I get ~630 syscalls using `console.log("Hello world")` and ~620 syscalls using `process.stdout.write("Hello World");`. This is on nodejs v13.5.0 EDIT: My previous comment was made using an old version of nodejs, the update halved the number of syscalls from being around ~1350
- z3t4 7y ago
  As a performance optimization I use stderr instead of console.log, for some reason stderr is much faster then stdout :P And console.log is slow as hell, mostly because it's sync, but also because it does a ton of stuff; parsing the parameters, etc.
  - 7y ago
alberth 7y ago
I’m curious to know how NIM performed given it transcodes into C.
- zamadatix 7y ago
  Someone commented a test shortly after you asked https://news.ycombinator.com/item?id=21957476 https://news.ycombinator.com/item?id=21957476
  - dom96 7y ago
    I’m actually curious why Nim didn’t make the list. Crystal is there and a lot of other emerging languages. Is the author not familiar with it?
    - kick 7y ago
      Drew's familiar with nim, and he's talked with you about it before on HN. Crystal was volunteered by someone working on Crystal, Julia was volunteered by a dev who works using Julia, etc. Haskell was also presented, I think, but Haskell was a mess.
ChrisMarshallNY 7y ago
That's pretty cool. It reminds me of GodBolt (https://godbolt.org https://godbolt.org). I'm told that the story behind it, is that he was arguing with someone about the efficiency of an operation, and actually wrote that site to prove his point.
_paulc 7y ago
As it's not on Drew's list: Nim: $ cat hello.nim stdout.write("hello, world!\n") Static (musl): $ nim --gcc.exe:musl-gcc --gcc.linkerexe:musl-gcc --passL:-static c -d:release hello.nim $ ldd ./hello not a dynamic executable Execution Time: 0m0.002s (real) Total Syscalls: 16 Unique Syscalls: 8 Size (KiB): 95K (78K stripped) Dynamic (glibc): $ nim c -d:release hello.nim $ ldd ./hello linux-vdso.so.1 => (0x00007ffc994b6000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f7c88785000) libc.so.6 => /lib64/libc.so.6 (0x00007f7c883b8000) /lib64/ld-linux-x86-64.so.2 (0x00007f7c88989000) Execution Time: 0m0.002s (real) Total Syscalls: 42 Unique Syscalls: 13 Size (KiB): 91K (79K stripped) Which I think is actually pretty reasonable for a high-level GC'd language.
- zamadatix 7y ago
  "Size (KiB): 95K (78K stripped)" Seems suspicious that lines up with the 95.9 KiB the author listed for C + GCC + musl static build even though the author says they stripped the binary after. I think they might have copied the wrong number into the table :). The author was counting the size of dynamic as binary + dynamically linked files. Should be about the same as the c dynamic ones in the table in this case anyways but just a note to anyone else running their own tests.
  - NilsIRL 7y ago
    Nim compiles to C
- tyingq 7y ago
  Curious if the generated C is any different for nim's echo as opposed to stdout.write().
- akavel 7y ago
  When testing with glibc, I got further improvements when I used echo instead of stdout.write, and also even more with -d:danger --opt:size On lobste.rs, someone also listed results for OCaml and they were quite nice IMO too.
zamadatix 7y ago
"Passing /dev/urandom into perl is equally likely to print “hello world”" That gave me a good chuckle towards the end. It'd be useful to break this out a little further as it'd have been interesting to see how small just the output is on the dynamically linked versions instead of just comparing static to whole dynamic bundle. It's also a bit odd that e.g. zig gets optimized for size and stripped via the compiler, c gets optimized for speed and stripped via strip, and Go/Crystal just gets built standard with no stripping at all. I don't think it'd change the big picture just a bit odd. . Unrelated tangent/ramble, I played with Zig and Go as part of my yearly "take December off and tinker" break. Zig was really fun to work with but unfortunately still in a huge churn and development. Go was a lot better than I expected it to be (I had put off messing with Go for a few years now) and the size of the stdlib is just astounding. In the end it wasn't as "fun" as zig but it had very low friction and I definitely see myself using it for a few personal projects over the next year... and then seeing if Zig has less churn in December ;).
marcosscriven 7y ago
Curious what all the syscalls Rust is making, and why?
- steveklabnik 7y ago
  One reason is that println! will lock stdout for you. I'm not sure what percentage that makes up. If you don't want that behavior, you can control this all yourself with write! and friends. EDIT: deeper analysis on Reddit: https://www.reddit.com/r/programming/comments/ejxwlu/hello_world/fd3zr9p/ https://www.reddit.com/r/programming/comments/ejxwlu/hello_w...
- Narishma 7y ago
  Most of them are probably from glibc.
tyingq 7y ago
Perl seems to lead the pack for interpreted langauges by a wide margin for this microbenchmark. I wonder if that's just for the narrow case of print() / hello-world.
- deleted 7y ago
  [deleted]
- kungtotte 7y ago
  I think it holds true for any kind of string management. It's kind of why Perl exists in the first place, to take one bunch of strings and turn them into another, probably printing them out somehow. It stands to reason that the default use case of Perl is well optimized.
cycloptic 7y ago
Sorry but I have to give this a thumbs down for not being a very convincing or well-written blog post. It dumps some data and then immediately jumps to a statement about how "lots of syscalls = bad" without actually detailing what those syscalls are doing in the context of the runtime. And I'm saying this as someone who already runs Alpine on my servers and doesn't need to be convinced. Drew, I think you can write much better posts than this.
- peteradio 7y ago
  More matter with less art. I thought it was a breezy read with a simple thesis. I don't know why such a thing should be discouraged.
  - cycloptic 7y ago
    It should be no surprise to users of CPython and Ruby that those languages have a lot of startup code. The details of what that code is doing are already evident if you're watching it happen in an strace log, but those bits were left out. This isn't art, it's details, and without the details, it's just preaching to the choir. No new readers are going to be convinced.
    - macintux 7y ago
      I didn’t see a great deal of effort to convince anyone of anything. Why must all blog posts be attempts to change the world?
      - cycloptic 7y ago
        Where I come from, the responsible thing to do when making a public statement is to back it up with facts, sources and explanations. We get enough blogspam and clickbait articles making the rounds here as it is. Please don't contribute to that.
- nielsole 7y ago
  It's still an interesting table. I was surprised that Java is 10x faster than Python. I would have expected initializing the JVM would be similarly complex to initializing the Python Interpreter.
hn_throwaway_99 7y ago
What is with it lately where there seem to be lots of posts fetishising absolute performance over lots of other attributes, or even worse, pretending those other attributes don't even matter. What is the point of this post? Yes, I fully expect a simple Hello World in assembly would be straightforward and fast. I still want the advantage of things like automated memory management, an interpreter or JIT compiler where warranted, a standard runtime environment, etc. For anything even remotely complicated. I get it, over the past 30-40 years we've built layers upon layers of abstraction, so it's worth it to take a look back and ask "Are there some cases where we overdid it?" Still, let's not throw the baby out with the bathwater, or forget why we added those layers in the first place.
- tyingq 7y ago
  I still find the table worthwhile, and maybe even worth looking into for the worst outliers. It's not definitive, but the spread is interesting.
- mlthoughts2018 7y ago
  This isn’t a recent trend, very common not just on HN but many, many communities of computer science. I think it’s sort of like how a lot of people fetishize a party lifestyle in their 20s and age out of it often when they get more perspective and understand bigger picture priorities.
- jhoeriutre 7y ago
  Virtue signaling. Generating outrage works and raises your profile as a righteous one.
jagrsw 7y ago
This would be a portable C (i.e. non x86-64, but still Linux) with just 2 syscalls: $ cat a.c #define _GNU_SOURCE #include <unistd.h> #include <sys/syscall.h> void _start(void) { syscall(__NR_write, 1, "Hello world!\n", 13); syscall(__NR_exit_group, 1); } $ gcc -nostartfiles a.c -o a -static $ ls -l a -rwxr-xr-x 1 user user 9584 jan 5 00:07 a $ strip -s a; ls -l a -rwxr-xr-x 1 user user 9000 jan 5 00:10 a $ strace ./a execve("./a", ["./a"], 0x7ffd4d4f8250 /* 67 vars */) = 0 write(1, "Hello world!\n", 13) = 13 exit_group(1) = ? +++ exited with 1 +++ I'm not actually sure why syscall() is inlined and glibc code is not included here while compiling with -static, but well, it works. Maybe it's because syscall() is a macro, or maybe it's some kind of ld code minimization (removing unused/unreachable code) trick which seems to be common in modern static linkers (ld, gold, lld).
- sandov 7y ago
  > portable > #define _GNU_SOURCE If it's portable, what's the point of defining _GNU_SOURCE? Honest question.
  - saagarjha 7y ago
    I’m not sure why they aren’t using the SYS_* constants either.
    - jagrsw 7y ago
      Yup, it'd make it (also using SYS_exit instead of SYS_exit_group) compilable under various *BSD OSes. Doesn't work for some reason under NetBSD due to some linking problem producing invalid binary for the platform. $ gcc -nostartfiles a.c -o a -Wl,--entry=_start -static $ ./a -bash: ./a: cannot execute binary file: Exec format error $ file a a: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped\ But the final binary is impressively small, and it seem to contain all relevant code (body of _start and syscall funcs) $ strip -s a; ls -l a -rwxr-xr-x 1 user users 2688 Jan 5 07:53 a Works under FreeBSD though: $ clang -nostartfiles a.c -o a -static $ ./a Hello world! $ strip -s a; ls -l a -rwxr-xr-x 1 user user 9216 Jan 5 07:59 a
majewsky 7y ago
Two notes on Go. Since Drew is stripping the binaries for many other languages, he should also do it for Go: go build -ldflags '-s -w' -o test test.go Also, since he's complaining about the difficulty of obtaining a static build in Go: There's an issue for that. (https://github.com/golang/go/issues/26492 https://github.com/golang/go/issues/26492) Drew definitely knows, he left an incredibly unhelpful comment there yesterday.
- Aeolun 7y ago
  You do have to wonder why nobody thought ‘this is getting a bit crazy’ before though.
  - tptacek 7y ago
    You do?
    - Aeolun 7y ago
      It is known. I guess I could have written: I think someone should have wondered whether this was actually a reasonable way to make a statically linked binary before. Maybe if you’ve gotten used to invoking the magic it doesn’t seem quite so arcane anymore.
      - hundt 7y ago
        FWIW if you don't need cgo then CGO_ENABLED=0 is sufficient to get a static binary. The tricky part is getting a static binary while also embedding C libraries. That's what the github issue is about.
    - Lammy 7y ago
      Try the pronoun form of "one"
- saagarjha 7y ago
  Unhelpful, but I must be jaded because I’m not sure I’d call it “incredibly unhelpful”.
Arrezz 7y ago
What is the history of the Hello World example program? I'm not sure why it's become this defacto example of syntax for every language. Maybe there is something else we could use as an example that would be more indicative of syntax but perhaps I'm overthinking it.
- imglorp 7y ago
  Brian Kernighan, 1972, A Tutorial Introduction to the Language B. And yeah, I think it's an okay intro to syntax because at least it shows you the minimum boilerplate to get some output. https://en.wikipedia.org/wiki/%22Hello,_World!%22_program https://en.wikipedia.org/wiki/%22Hello,_World!%22_program
- yiyus 7y ago
  I have always thought it first appeared in K&R, but I do not know where I got that from.
zbentley 7y ago
> Passing /dev/urandom into perl is equally likely to print “hello world” I chuckled.
gpsx 7y ago
And then, someone went and invented the graphical user interface. So many precious machine cycles wasted rendering graphics for people who are too lazy to use the command line like they are supposed to. Shhheez.
pyb 7y ago
test.c compiles to 6 kilobytes on my Linux Mint machine... how did he get it to compile to more than 2 megabytes?
- phoe-krk 7y ago
  Add the size of all the dynamic libraries that your executable depends on - which most likely means glibc, the C runtime.
- kick 7y ago
  Run ldd on it, the "true" size will probably paint a different picture.
z3t4 7y ago
What is the command used to get total and unique syscalls!? strace wc !?
thamer 7y ago
Haskell: https://gist.github.com/nicolasff/fe5668194769c175d9d4dfc78f694724 https://gist.github.com/nicolasff/fe5668194769c175d9d4dfc78f... 38 bytes source code, 970 KB binary (782 KB stripped) 0m0.003s execution time, 139 syscalls (26 unique). Seeing the list of syscalls is the most interesting part of this whole exercise; the number of milliseconds it takes to print "hello world" is not super relevant (except in the few cases where start-up time is painfully long).
tptacek 7y ago
This appears to have been written by someone who thinks the point of "Hello World" is to print the string "Hello World" as efficiently as possible. If that were the case, Kernighan wouldn't have written the first one with "printf()".
- kick 7y ago
  He didn't write the first one with "printf()". https://www.bell-labs.com/usr/dmr/www/btut.pdf https://www.bell-labs.com/usr/dmr/www/btut.pdf
  - tptacek 7y ago
    Because he didn't have it in B. The K&R C "Hello World" uses printf(), which itself does a whole bunch of crap other than printing out "hello world".
    - saagarjha 7y ago
      Mhm, like being recognized as constant by the compiler and turned into a call to puts?
      - tptacek 7y ago
        Something Kernighan's compiler didn't do.
        overgard 7y ago
        How is a 40 year old compiler relevant?
        tptacek 7y ago
        Kernighan had puts(3) available, but chose printf(3), which does a lot more than puts. The point is Kernighan, not the compiler.
        7y ago
tylermenezes 7y ago
I don't know much about Julia. Why is the binary over a third a GiB?
- ChrisRackauckas 7y ago
  Julia by default is loading a system image which is made for scientific computing, so linear algebra support, a package manager, distributed parallel computing, etc. are all part of that. You can build a system image without all of that of course, but given its audience it's a good default choice.
swiftcoder 7y ago
Rust drops to 16KB (on a Mac, I suspect nearer 8KB on Linux) if you set panic=abort, turn on LTO, and drop the std library: #![feature(start, lang_items)] #![no_std] #![no_main] #[link(name = "c")] extern "C" { pub fn puts(s: *const u8); } #[no_mangle] pub extern "C" fn main(_argc: i32, _argv: *const *const u8) -> i32 { unsafe { puts(b"hello world\n" as *const u8); }; 0 } #[panic_handler] fn panic(_info: &core::panic::PanicInfo) -> ! { loop {} } #[lang = "eh_personality"] extern "C" fn eh_personality() {} 2x assembly isn't bad, but I'm willing to bet we can go smaller.
- steveklabnik 7y ago
  https://github.com/tormol/tiny-rust-executable https://github.com/tormol/tiny-rust-executable (See also http://mainisusuallyafunction.blogspot.com/2015/01/151-byte-static-linux-binary-in-rust.html http://mainisusuallyafunction.blogspot.com/2015/01/151-byte-... which was the original implementation, this shaved a few more bytes off)
emmanueloga_ 7y ago
I feel like printing "hello world" with, say, java, is like picking up your supermarket groceries on an Scania truck. All that extra machinery is there for when you need to tackle harder problems, but may represent a lot of overhead for super simple ones.
skybrian 7y ago
It's an interesting table, but what you really want to know is how much of the standard library gets linked in as soon as you do anything interesting. For example, if using one printf links in a lot and you almost always use at least one printf (or use a library that does), then the size you get when you entirely avoid printf doesn't matter, because that's not a practical thing to avoid. But you might want to know the minimum size with printf. Figuring how where the binary size cliffs are (what causes size to grow a lot) and which cliffs it's practical to avoid might be useful.
alaroldai 7y ago
An alternate interpretation of the same data - if you're committed to writing a program in a language that requires a runtime / does a lot of work on startup, writing a program that prints "Hello, World!" does not make the most effective use of that language and runtime. Put that way, most of this post seems like a tautology: if you misuse the tools you are given, of course you're going to get bad results! It seems reasonable to me that a language should make the assumption that the programmer's use case matches the languages strengths, so by default any runtime setup / bookkeeping / teardown code should run. Failure to remove that extra "complexity" isn't a failure of the toolchain, it's a failure of the programmer to select the right tool for the job. If the point the author was trying to make was that the complexity being added is never useful, this is not a post that argues that position. A cost / benefit discussion of the specific behaviours being supported by that complexity would be very interesting!
abjKT26nO8 7y ago
>The following assembly program is the ideal Linux x86_64 program for this purpose. A perfect compiler would emit this hello world program for any language. I.e. you want your compiler to emit code that isn't portable across unix-like systems (and their future versions) in any degree? AFAIK Linux is the only unix-like system that guarantees ABI stability. I'm curious what Zig does in this case that it got so "good" results. Does it forgo portability?
- saagarjha 7y ago
  Linux binaries should take advantage of the stability of the platform they’re on, surely?
based2 7y ago
http://www.rosettacode.org/wiki/Hello_world/Text http://www.rosettacode.org/wiki/Hello_world/Text
fulafel 7y ago
Anyone want to do Clojure + GraalVM?
ianopolous 7y ago
I'm curious what method was used to compile the Java version. I'm assuming it was jlink? If you use graalvm's native image then last time I checked the output was 6 MiB and runtime ~1 ms. And it may be much better now with Java 11.

212 points by ddevault 7y ago

What is this post supposed to prove? It certainly is not supposed to prove that a hello world is a representative real-world program, from which one could infer that writing and debugging a real-world program in Julia is 835 times as complex as writing a real-world program in assembly, since the former makes 835 times as many syscalls as an assembly program. (You know, that number seems okay for me, except it needs to be applied to these languages in reverse.) I agree that software bloat is a big problem, but trivializing that problem to printing a "hello world" to the screen, punishing all languages with runtimes by measuring the syscalls involved in their startup routines, disregarding the fact that many users are going to have a single system-wide runtime for e.g. C or Python or Julia and therefore the total-kB number does not scale linearly with the number of programs written in C or Python or Julia, ignoring the massively increased software development and debugging time for writing in low-level and memory-unsafe languages like assembly, static Zig, or C, and directly implying[0] that most problems with software complexity can be solved by writing in assembly, static Zig, or C rather than in Julia/Ruby/Java/all other languages from the bottom 90% of the list (and that's the vibe that this post gives me) is, for me, more about making a venting shitpost than creating something that provides even a part of an actual solution to software bloat in general. The "more time your users are sitting there waiting for your program" statement is especially amusing to me. Your users are not going to wait shorter for your program because you and your team are taking another year to write, test, and debug it in assembly. [0] "These numbers are real. This is more complexity that someone has to debug, more time your users are sitting there waiting for your program, less disk space available for files which actually matter to the user."

ajkjk 7y ago
It could just be trying to be interesting, not to prove anything.
- phoe-krk 7y ago
  Why is it attempting to moralize if it is not meant to prove any morals then?
- hn_throwaway_99 7y ago
  The language in the post, "Most languages do a whole lot of other crap other than printing out “hello world”, even if that’s all you asked for." certainly seems to imply it's moralizing about something.
overgard 7y ago
If your compiler generates something huge for the most basic test, how can you trust it's doing well on actual programs? Most real programs are far too complicated to analyze. It may be a toy example, but if your language can't handle a toy, it's probably bad on real world programs also.
- jefozabuss 7y ago
  This example is not too relevant because the overhead is probably the additional tools (e.g. debug, error handlers, etc), there should be multiple examples for a normal comparison, e.g. 3-4 examples of more and more advanced code since then maybe these numbers would increase in a similar fashion.
- phoe-krk 7y ago
  You have a weird definition of "handling". A high-level language performs the same amount of work as the lower-level one - I cannot see a language listed in the blogpost that has failed to display a command in the console. It's the lower-level languages that, for the sake of efficiency and minimalism, cannot handle systems larger than a hello-world and actual programs written in them without long development times and a mass of bugs that come straight from their inability to abstract when necessary and from their memory management systems that lack sanity and safety. This "simplicity"[0] is often fetishized, and this blog post looks no different to me - look how many overflow bugs in operating system kernels this "simplicity" has caused. Or, paraphrasing your quote, if your language prevents you from creating most basic abstractions, how can you trust it's doing well on actual programs? [0] I can agree, writing in a memory unsafe language is simple, as long as it's someone else who maintains the code you wrote, accepts or reroutes all of the bugtickets that happen, and analyzes heisenbugs that come from weird memory corruptions caused by unsafe code.
  - overgard 7y ago
    > A high-level language performs the same amount of work as the lower-level one No, uh, the high level language performs way more work. It just happens that most of that work is useless. You seem to be unclear on the definition of efficiency, so let me spell it out: it's not about getting the work done, it's about getting the work done in the minimal amount of steps. That's why this is a good test: there's a clear boundary of "minimal amount of work". > It's the lower-level languages that, for the sake of efficiency and minimalism, cannot handle systems larger than a hello-world and actual programs written in them without long development times and a mass of bugs that come straight from their inability to abstract when necessary and from their memory management systems that lack sanity and safety. Yes, nobody has ever written a complex program in C. Excluding every OS and every important desktop application, I guess. Yeah, it's more work. Sometimes doing something hard takes more work. > Or, paraphrasing your quote, if your language prevents you from creating most basic abstractions, how can you trust it's doing well on actual programs? You're right. Let's rewrite the Linux kernel in Ruby. C just isn't up to the task. As an added bonus, all our computers will now have the benefit of working as excellent space heaters!
einpoklum 7y ago
> What is this post supposed to prove? It proves that the compilers for many programming languages emit a lot of instructions and a lot of system calls they could have optimized away theoretically. This is particularly true when there are lots of "startup routines". When the program to be run is known, almost all of that startup can be found out to not be necessary, and stripped from the final executable. > Your users are not going to wait shorter for your program because you and your team are taking another year to write, test, and debug it in assembly. They might, if your program is interactive and is used often enough. Now, writing assembly is not very realistic, but considering a different language with less overhead - is.
- phoe-krk 7y ago
  > they could have optimized away theoretically. For a hello-world program, this is true, you do not need any of the features that usually come in the language runtime - no garbage collection, no runtime memory safety, no runtime introspection, et cetera. This stems directly from the fact that many of these languages have borrowed features from Lisp, which has the whole language (GC, compiler, debug functions, etc..) always available for the code. And that, considering your point of view, might be a feature, not a bug - especially if your program, having a runtime of its own, actually produces its own stacktrace, allows you to interactively inspect values of variables throughout the stack, and - in case of some runtimes - is capable of opening up its own debugger for you to perform introspection and issue analyzing in.
  - saagarjha 7y ago
    > This stems directly from the fact that many of these languages have borrowed features from Lisp, which has the whole language (GC, compiler, debug functions, etc..) always available for the code. Right, I think the point was that this isn't always necessary, in which case it becomes extra baggage that you have to carry around.
- hokumguru 7y ago
  For all the daily articles that pop up here on HN concerning premature optimization I find it surprising to see this thread and all the sentiment of language choice mattering. It’s far easier to work in and translate thoughts to more feature rich languages. The vast majority of the time it’s not the language itself that will be an optimization issue down the line but rather the written code.
jhoeriutre 7y ago
It's the software developers equivalent of virtue signaling. Some people get outraged that OTHERS use plastic straws, and wiggle the finger at them for being bad persons while pointing at their VIRTUOUS paper straw. Some programmers get outraged that OTHERS write bloated programs in Python/JavaScript/Electron, and wiggle the finger at them for being bad persons while pointing at their VIRTUOUS C/Assembly/native GUI app.
deleted 7y ago
[deleted]
3xblah 7y ago
"What is this supposed to prove?" Perhaps it proves that if one is writing relatively small, simple programs, some of these languages are overkill.

deleted 7y ago

[deleted]

NilsIRL 7y ago

It would be interesting to know why the number of syscalls for C are so high.

gerikson 7y ago
Which version of C?
- zamadatix 7y ago
  All versions are interesting, zig/assembly managesto do it in 2/3 so what is musl doing that needs 5? And what on Earth is glibc dynamic doing that it needs 65?
BearOso 7y ago
I’m wondering why his dynamic glibc C executable is so big.
- kungtotte 7y ago
  He's counting glibc too, not just the binary. This is true for all of the examples, the size is the binary itself plus whatever system/libraries you'd need to actually run the binary.

lttlrck 7y ago

It’s comparing unassembled assembler to JITed code and compilers that are pulling in precompiled libraries. I feel it needs some kind of normalizing. I get that it is illustrating bloat but it doesn’t really illustrate where that’s coming from. Maybe only the output of the JITs should counts, or the syscalls required to assemble the example should be included. Are musl and glibc really wasting cycles or are they doing something that the example is missing. Fun to think about.

ddevault 7y ago
It's deliberate that JITs, interpreters, and compiled languages are compared on the same terms here. JITs and interpreters are fundamentally less performant than compiled languages, they don't get a pass on performance tests just because it's by design.
- joshuamorton 7y ago
  > JITs This is...highly context dependent. For highly polymorphic code, my understanding is that JITs can outperform precompiled binaries, since they can inline virtual/polymorphic calls in tight loops. This also isn't a "performance" test in any real sense. It's a test of startup time. Where, yes, JITs lose, but unless you're writing short lived interactive command line tools, or something that runs on lambda, that shouldn't be a concern. For "normal" serverside or desktop apps that run for more than, say, 30 seconds, the difference between 0s of startup and 0.2s of startup time is literally in the noise.
  - ddevault 7y ago
    Startup time is the least interesting metric in this article. The more interesting metric is the number of syscalls. This isn't a measure of performance, it's a measure of complexity and busywork. Complexity tends to indirectly affect performance, but that's not the point of the article.
    - joshuamorton 7y ago

franciscop 7y ago

Random thought/question, does `process.stdout.write("Hello World");` in Node.js make any difference? While `console.log()` is correct for this analysis since it's the more common one, it does a lot of extra internal logic: https://github.com/nodejs/node/blob/v13.x/lib/internal/console/constructor.js https://github.com/nodejs/node/blob/v13.x/lib/internal/conso... Edit: I'm just curious and don't know how to even start testinng this, not trying to promote/demote Node.js in any way.

np_tedious 7y ago
If it is any better, it probably would be the more fair entry (and perhaps similar for python and stdout/bytes) since Go's example did basically that instead of fmt.print with a string
zamadatix 7y ago
I would be surprised if console.log() made many more syscalls than process.stdout.write. More function calls probably but those aren't being counted and neither is RAM usage. "strace" would let you count and find out though! The size would be a few bytes larger since node is scripted and that's more characters.
TheNorthman 7y ago
I'm not able to reproduce the authors results (nor reliably ANY result) but you're right. Using `strace -c node -e <code>` I get ~630 syscalls using `console.log("Hello world")` and ~620 syscalls using `process.stdout.write("Hello World");`. This is on nodejs v13.5.0 EDIT: My previous comment was made using an old version of nodejs, the update halved the number of syscalls from being around ~1350
z3t4 7y ago
As a performance optimization I use stderr instead of console.log, for some reason stderr is much faster then stdout :P And console.log is slow as hell, mostly because it's sync, but also because it does a ton of stuff; parsing the parameters, etc.
- 7y ago

alberth 7y ago

I’m curious to know how NIM performed given it transcodes into C.

zamadatix 7y ago
Someone commented a test shortly after you asked https://news.ycombinator.com/item?id=21957476 https://news.ycombinator.com/item?id=21957476
- dom96 7y ago
  I’m actually curious why Nim didn’t make the list. Crystal is there and a lot of other emerging languages. Is the author not familiar with it?
  - kick 7y ago
    Drew's familiar with nim, and he's talked with you about it before on HN. Crystal was volunteered by someone working on Crystal, Julia was volunteered by a dev who works using Julia, etc. Haskell was also presented, I think, but Haskell was a mess.

ChrisMarshallNY 7y ago

That's pretty cool. It reminds me of GodBolt (https://godbolt.org https://godbolt.org). I'm told that the story behind it, is that he was arguing with someone about the efficiency of an operation, and actually wrote that site to prove his point.

_paulc 7y ago

As it's not on Drew's list: Nim: $ cat hello.nim stdout.write("hello, world!\n") Static (musl): $ nim --gcc.exe:musl-gcc --gcc.linkerexe:musl-gcc --passL:-static c -d:release hello.nim $ ldd ./hello not a dynamic executable Execution Time: 0m0.002s (real) Total Syscalls: 16 Unique Syscalls: 8 Size (KiB): 95K (78K stripped) Dynamic (glibc): $ nim c -d:release hello.nim $ ldd ./hello linux-vdso.so.1 => (0x00007ffc994b6000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f7c88785000) libc.so.6 => /lib64/libc.so.6 (0x00007f7c883b8000) /lib64/ld-linux-x86-64.so.2 (0x00007f7c88989000) Execution Time: 0m0.002s (real) Total Syscalls: 42 Unique Syscalls: 13 Size (KiB): 91K (79K stripped) Which I think is actually pretty reasonable for a high-level GC'd language.

zamadatix 7y ago
"Size (KiB): 95K (78K stripped)" Seems suspicious that lines up with the 95.9 KiB the author listed for C + GCC + musl static build even though the author says they stripped the binary after. I think they might have copied the wrong number into the table :). The author was counting the size of dynamic as binary + dynamically linked files. Should be about the same as the c dynamic ones in the table in this case anyways but just a note to anyone else running their own tests.
- NilsIRL 7y ago
  Nim compiles to C
tyingq 7y ago
Curious if the generated C is any different for nim's echo as opposed to stdout.write().
akavel 7y ago
When testing with glibc, I got further improvements when I used echo instead of stdout.write, and also even more with -d:danger --opt:size On lobste.rs, someone also listed results for OCaml and they were quite nice IMO too.

zamadatix 7y ago

"Passing /dev/urandom into perl is equally likely to print “hello world”" That gave me a good chuckle towards the end. It'd be useful to break this out a little further as it'd have been interesting to see how small just the output is on the dynamically linked versions instead of just comparing static to whole dynamic bundle. It's also a bit odd that e.g. zig gets optimized for size and stripped via the compiler, c gets optimized for speed and stripped via strip, and Go/Crystal just gets built standard with no stripping at all. I don't think it'd change the big picture just a bit odd. . Unrelated tangent/ramble, I played with Zig and Go as part of my yearly "take December off and tinker" break. Zig was really fun to work with but unfortunately still in a huge churn and development. Go was a lot better than I expected it to be (I had put off messing with Go for a few years now) and the size of the stdlib is just astounding. In the end it wasn't as "fun" as zig but it had very low friction and I definitely see myself using it for a few personal projects over the next year... and then seeing if Zig has less churn in December ;).

marcosscriven 7y ago

Curious what all the syscalls Rust is making, and why?

steveklabnik 7y ago
One reason is that println! will lock stdout for you. I'm not sure what percentage that makes up. If you don't want that behavior, you can control this all yourself with write! and friends. EDIT: deeper analysis on Reddit: https://www.reddit.com/r/programming/comments/ejxwlu/hello_world/fd3zr9p/ https://www.reddit.com/r/programming/comments/ejxwlu/hello_w...
Narishma 7y ago
Most of them are probably from glibc.

tyingq 7y ago

Perl seems to lead the pack for interpreted langauges by a wide margin for this microbenchmark. I wonder if that's just for the narrow case of print() / hello-world.

deleted 7y ago
[deleted]
kungtotte 7y ago
I think it holds true for any kind of string management. It's kind of why Perl exists in the first place, to take one bunch of strings and turn them into another, probably printing them out somehow. It stands to reason that the default use case of Perl is well optimized.

cycloptic 7y ago

Sorry but I have to give this a thumbs down for not being a very convincing or well-written blog post. It dumps some data and then immediately jumps to a statement about how "lots of syscalls = bad" without actually detailing what those syscalls are doing in the context of the runtime. And I'm saying this as someone who already runs Alpine on my servers and doesn't need to be convinced. Drew, I think you can write much better posts than this.

peteradio 7y ago
More matter with less art. I thought it was a breezy read with a simple thesis. I don't know why such a thing should be discouraged.
- cycloptic 7y ago
  It should be no surprise to users of CPython and Ruby that those languages have a lot of startup code. The details of what that code is doing are already evident if you're watching it happen in an strace log, but those bits were left out. This isn't art, it's details, and without the details, it's just preaching to the choir. No new readers are going to be convinced.
  - macintux 7y ago
    I didn’t see a great deal of effort to convince anyone of anything. Why must all blog posts be attempts to change the world?
    - cycloptic 7y ago
      Where I come from, the responsible thing to do when making a public statement is to back it up with facts, sources and explanations. We get enough blogspam and clickbait articles making the rounds here as it is. Please don't contribute to that.
nielsole 7y ago
It's still an interesting table. I was surprised that Java is 10x faster than Python. I would have expected initializing the JVM would be similarly complex to initializing the Python Interpreter.

hn_throwaway_99 7y ago

What is with it lately where there seem to be lots of posts fetishising absolute performance over lots of other attributes, or even worse, pretending those other attributes don't even matter. What is the point of this post? Yes, I fully expect a simple Hello World in assembly would be straightforward and fast. I still want the advantage of things like automated memory management, an interpreter or JIT compiler where warranted, a standard runtime environment, etc. For anything even remotely complicated. I get it, over the past 30-40 years we've built layers upon layers of abstraction, so it's worth it to take a look back and ask "Are there some cases where we overdid it?" Still, let's not throw the baby out with the bathwater, or forget why we added those layers in the first place.

tyingq 7y ago
I still find the table worthwhile, and maybe even worth looking into for the worst outliers. It's not definitive, but the spread is interesting.
mlthoughts2018 7y ago
This isn’t a recent trend, very common not just on HN but many, many communities of computer science. I think it’s sort of like how a lot of people fetishize a party lifestyle in their 20s and age out of it often when they get more perspective and understand bigger picture priorities.
jhoeriutre 7y ago
Virtue signaling. Generating outrage works and raises your profile as a righteous one.

jagrsw 7y ago

This would be a portable C (i.e. non x86-64, but still Linux) with just 2 syscalls: $ cat a.c #define _GNU_SOURCE #include <unistd.h> #include <sys/syscall.h> void _start(void) { syscall(__NR_write, 1, "Hello world!\n", 13); syscall(__NR_exit_group, 1); } $ gcc -nostartfiles a.c -o a -static $ ls -l a -rwxr-xr-x 1 user user 9584 jan 5 00:07 a $ strip -s a; ls -l a -rwxr-xr-x 1 user user 9000 jan 5 00:10 a $ strace ./a execve("./a", ["./a"], 0x7ffd4d4f8250 /* 67 vars */) = 0 write(1, "Hello world!\n", 13) = 13 exit_group(1) = ? +++ exited with 1 +++ I'm not actually sure why syscall() is inlined and glibc code is not included here while compiling with -static, but well, it works. Maybe it's because syscall() is a macro, or maybe it's some kind of ld code minimization (removing unused/unreachable code) trick which seems to be common in modern static linkers (ld, gold, lld).

sandov 7y ago
> portable > #define _GNU_SOURCE If it's portable, what's the point of defining _GNU_SOURCE? Honest question.
- saagarjha 7y ago
  I’m not sure why they aren’t using the SYS_* constants either.
  - jagrsw 7y ago
    Yup, it'd make it (also using SYS_exit instead of SYS_exit_group) compilable under various *BSD OSes. Doesn't work for some reason under NetBSD due to some linking problem producing invalid binary for the platform. $ gcc -nostartfiles a.c -o a -Wl,--entry=_start -static $ ./a -bash: ./a: cannot execute binary file: Exec format error $ file a a: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped\ But the final binary is impressively small, and it seem to contain all relevant code (body of _start and syscall funcs) $ strip -s a; ls -l a -rwxr-xr-x 1 user users 2688 Jan 5 07:53 a Works under FreeBSD though: $ clang -nostartfiles a.c -o a -static $ ./a Hello world! $ strip -s a; ls -l a -rwxr-xr-x 1 user user 9216 Jan 5 07:59 a

majewsky 7y ago

Two notes on Go. Since Drew is stripping the binaries for many other languages, he should also do it for Go: go build -ldflags '-s -w' -o test test.go Also, since he's complaining about the difficulty of obtaining a static build in Go: There's an issue for that. (https://github.com/golang/go/issues/26492 https://github.com/golang/go/issues/26492) Drew definitely knows, he left an incredibly unhelpful comment there yesterday.

Aeolun 7y ago
You do have to wonder why nobody thought ‘this is getting a bit crazy’ before though.
- tptacek 7y ago
  You do?
  - Aeolun 7y ago
    It is known. I guess I could have written: I think someone should have wondered whether this was actually a reasonable way to make a statically linked binary before. Maybe if you’ve gotten used to invoking the magic it doesn’t seem quite so arcane anymore.
    - hundt 7y ago
      FWIW if you don't need cgo then CGO_ENABLED=0 is sufficient to get a static binary. The tricky part is getting a static binary while also embedding C libraries. That's what the github issue is about.
  - Lammy 7y ago
    Try the pronoun form of "one"
saagarjha 7y ago
Unhelpful, but I must be jaded because I’m not sure I’d call it “incredibly unhelpful”.

Arrezz 7y ago

What is the history of the Hello World example program? I'm not sure why it's become this defacto example of syntax for every language. Maybe there is something else we could use as an example that would be more indicative of syntax but perhaps I'm overthinking it.

imglorp 7y ago
Brian Kernighan, 1972, A Tutorial Introduction to the Language B. And yeah, I think it's an okay intro to syntax because at least it shows you the minimum boilerplate to get some output. https://en.wikipedia.org/wiki/%22Hello,_World!%22_program https://en.wikipedia.org/wiki/%22Hello,_World!%22_program
yiyus 7y ago
I have always thought it first appeared in K&R, but I do not know where I got that from.

zbentley 7y ago

> Passing /dev/urandom into perl is equally likely to print “hello world” I chuckled.

gpsx 7y ago

And then, someone went and invented the graphical user interface. So many precious machine cycles wasted rendering graphics for people who are too lazy to use the command line like they are supposed to. Shhheez.

pyb 7y ago

test.c compiles to 6 kilobytes on my Linux Mint machine... how did he get it to compile to more than 2 megabytes?

phoe-krk 7y ago
Add the size of all the dynamic libraries that your executable depends on - which most likely means glibc, the C runtime.
kick 7y ago
Run ldd on it, the "true" size will probably paint a different picture.

z3t4 7y ago

What is the command used to get total and unique syscalls!? strace wc !?

thamer 7y ago

Haskell: https://gist.github.com/nicolasff/fe5668194769c175d9d4dfc78f694724 https://gist.github.com/nicolasff/fe5668194769c175d9d4dfc78f... 38 bytes source code, 970 KB binary (782 KB stripped) 0m0.003s execution time, 139 syscalls (26 unique). Seeing the list of syscalls is the most interesting part of this whole exercise; the number of milliseconds it takes to print "hello world" is not super relevant (except in the few cases where start-up time is painfully long).

tptacek 7y ago

This appears to have been written by someone who thinks the point of "Hello World" is to print the string "Hello World" as efficiently as possible. If that were the case, Kernighan wouldn't have written the first one with "printf()".

kick 7y ago
He didn't write the first one with "printf()". https://www.bell-labs.com/usr/dmr/www/btut.pdf https://www.bell-labs.com/usr/dmr/www/btut.pdf
- tptacek 7y ago
  Because he didn't have it in B. The K&R C "Hello World" uses printf(), which itself does a whole bunch of crap other than printing out "hello world".
  - saagarjha 7y ago
    Mhm, like being recognized as constant by the compiler and turned into a call to puts?
    - tptacek 7y ago
      Something Kernighan's compiler didn't do.
      - overgard 7y ago
        How is a 40 year old compiler relevant?
        tptacek 7y ago
        Kernighan had puts(3) available, but chose printf(3), which does a lot more than puts. The point is Kernighan, not the compiler.
      - 7y ago

tylermenezes 7y ago

I don't know much about Julia. Why is the binary over a third a GiB?

ChrisRackauckas 7y ago
Julia by default is loading a system image which is made for scientific computing, so linear algebra support, a package manager, distributed parallel computing, etc. are all part of that. You can build a system image without all of that of course, but given its audience it's a good default choice.

swiftcoder 7y ago

Rust drops to 16KB (on a Mac, I suspect nearer 8KB on Linux) if you set panic=abort, turn on LTO, and drop the std library: #![feature(start, lang_items)] #![no_std] #![no_main] #[link(name = "c")] extern "C" { pub fn puts(s: *const u8); } #[no_mangle] pub extern "C" fn main(_argc: i32, _argv: *const *const u8) -> i32 { unsafe { puts(b"hello world\n" as *const u8); }; 0 } #[panic_handler] fn panic(_info: &core::panic::PanicInfo) -> ! { loop {} } #[lang = "eh_personality"] extern "C" fn eh_personality() {} 2x assembly isn't bad, but I'm willing to bet we can go smaller.

steveklabnik 7y ago
https://github.com/tormol/tiny-rust-executable https://github.com/tormol/tiny-rust-executable (See also http://mainisusuallyafunction.blogspot.com/2015/01/151-byte-static-linux-binary-in-rust.html http://mainisusuallyafunction.blogspot.com/2015/01/151-byte-... which was the original implementation, this shaved a few more bytes off)

emmanueloga_ 7y ago

I feel like printing "hello world" with, say, java, is like picking up your supermarket groceries on an Scania truck. All that extra machinery is there for when you need to tackle harder problems, but may represent a lot of overhead for super simple ones.

skybrian 7y ago

It's an interesting table, but what you really want to know is how much of the standard library gets linked in as soon as you do anything interesting. For example, if using one printf links in a lot and you almost always use at least one printf (or use a library that does), then the size you get when you entirely avoid printf doesn't matter, because that's not a practical thing to avoid. But you might want to know the minimum size with printf. Figuring how where the binary size cliffs are (what causes size to grow a lot) and which cliffs it's practical to avoid might be useful.

alaroldai 7y ago

An alternate interpretation of the same data - if you're committed to writing a program in a language that requires a runtime / does a lot of work on startup, writing a program that prints "Hello, World!" does not make the most effective use of that language and runtime. Put that way, most of this post seems like a tautology: if you misuse the tools you are given, of course you're going to get bad results! It seems reasonable to me that a language should make the assumption that the programmer's use case matches the languages strengths, so by default any runtime setup / bookkeeping / teardown code should run. Failure to remove that extra "complexity" isn't a failure of the toolchain, it's a failure of the programmer to select the right tool for the job. If the point the author was trying to make was that the complexity being added is never useful, this is not a post that argues that position. A cost / benefit discussion of the specific behaviours being supported by that complexity would be very interesting!

abjKT26nO8 7y ago

>The following assembly program is the ideal Linux x86_64 program for this purpose. A perfect compiler would emit this hello world program for any language. I.e. you want your compiler to emit code that isn't portable across unix-like systems (and their future versions) in any degree? AFAIK Linux is the only unix-like system that guarantees ABI stability. I'm curious what Zig does in this case that it got so "good" results. Does it forgo portability?

saagarjha 7y ago
Linux binaries should take advantage of the stability of the platform they’re on, surely?

based2 7y ago

http://www.rosettacode.org/wiki/Hello_world/Text http://www.rosettacode.org/wiki/Hello_world/Text

fulafel 7y ago

Anyone want to do Clojure + GraalVM?

ianopolous 7y ago

I'm curious what method was used to compile the Java version. I'm assuming it was jlink? If you use graalvm's native image then last time I checked the output was 6 MiB and runtime ~1 ms. And it may be much better now with Java 11.