13 ms·

Analysis of the overhead of a minimal Zig program

186 points by matu3ba 5y ago

3a2d29 5y ago
I've been seeing a lot of posts about Zig recently. Out of curiosity is there a specific reason these are more common (like a recent big project or release)? Not hating, just wondering. EDIT: Just saw there was a new release 10 days ago, although it wasn't 1.0
- dnautics 5y ago
  Just fyi, zig 1.0 is likely years out.
- isaiahg 5y ago
  The people who like zig really like zig so they upvote it to the top while the people who don't like zig are at worst indifferent to it. So no one really complains. But we're starting to reach the point where zig is becoming popular and people will hate it for that alone very soon. Because we're all really just cavemen typing on keyboards and we can't even discuss how to encode text strings without descending into tribal war.
  - gompertz 5y ago
    Ironically, V programming language has 2-3x the amount of github stars (decent measure of popularity) to zig/nim, yet has been the brunt of general hate here on HN from day one. (Mostly, as I can tell, due to some single individual blog Christine something?;that everyone has taken as gospel).
    - saagarjha 5y ago
      That blog post put into words a sentiment that had been around for quite a while.
    - Tomte 5y ago
      https://christine.website/blog/v-vaporware-2019-06-23 https://christine.website/blog/v-vaporware-2019-06-23
      - DyslexicAtheist 5y ago
        never heard of V and this blog was the introduction I didn't know I needed. beautiful but brutal :D ... thank you
        gompertz 5y ago
        Don't forget the post is 2.5 years old... Lots has evolved.
    - kaba0 5y ago
      The V website did in fact contain impossibly wild claims that were taken down when called out. Add to the fact that it was closed source for a long time, but had an ongoing patreon, you could easily see the possibility of a scam in all that. And I personally haven’t seen evidence to the contrary still.
    - AnIdiotOnTheNet 5y ago
      V was also called out by Andrew Kelly (Zig's originator) and Ginger Bill (of Odinlang fame). A lot of people who knew stuff about compilers and languages had things to say about it, it wasn't just one blog.
    - detaro 5y ago
      github stars are a pretty crappy measure of anything. maybe for "people who've seen it and thought it looked vaguely interesting" (which something like V that makes a big splash with gigantic promises easily hits), but even that is vague, given how differently people use them. (People making a big deal out of them is a pretty good negative signal though)
    - isaiahg 5y ago
      Thankfully much of the controversy around V has escaped me. The clashes between proponents and detractors has mostly occurred on my periphery and it comes across rather silly to me. And I realize that will make me unpopular with both sides. It reminds me more of highschoolers arguing rather than than engineers actually trying to solve something, in that no one is fully wrong and everyone is a little bit right. One side should realize they're deriding a project that's still in its infancy and it's bound to be unfinished, buggy, off-kilter, and missing features that are still more or less just rough ideas in the heads of the creators. The same can be said for any early project. And one side needs to accept the creators were a bit overzealous and advertised features that we're really just rough ideas in their heads. And that fighting criticism with anger just makes those criticizing double down in their energy and aggressiveness. I'm sure V will be a fine language some day. I actually like the simple style of Go's syntax. It's a breath of fresh air when you're up to your neck in "Value<double, SIUnits::m> distance;" Though I question if it actually brings anything new more than some nicer syntax. I might wait until it's closer to a v1 and make something in it for my blog.
      - gompertz 5y ago
        Thanks for saying all this, probably one of the more mature insights. Personally I find V to already be a fine language - it improves on everything I feel Go just slightly missed the mark on. Regarding the hostility towards the performance claims; even if they aren't reaching those claims, the language is nonetheless extremely fast - so fast, that missing the claims is a mute point from a user perspective. It uses TCC on the backend; which everyone knows, and nobody disputes, is a very small and fast compiler. I understand/derive people are maybe upset the author is getting Patreon/Github donations based (in their opinion) on these 'false' claims. I don't think that's the case at all - people are thinking it's causation, when it's mere correlation. It's a still-obscure language, and it's not like they are selling Norwex cleaning supplies at a convention of everyday people walking by. The landing page isn't attracting your family relative, compelling them to donate money on Patreon. It's an extremely small group of people that are going to pay even the slightest interest to the project. People who have an interest in a boutique languages and providing monetary support are more than likely doing so out of interest in the project's goals (obtainable, or otherwise), appealing syntax, ambitions of the author, github activity, and general goodness; not solely off some bullets on a landing page - especially in a world where we know 99% of that is always shilled bullshit from VC's, bigbox products, etc. etc. Undoubtedly, the author could have maybe done better PR - who doesn't stumble at first though? Like, really. Everything I see referenced is from articles 2.5-3 years old... from a single blog to boot. Notwithstanding, the donations (which seem to be the target of most peoples comments), are around $1,000/month; this isn't really a large amount of money; but people are acting like this is $20,000/month.
    - Tozen 5y ago
      Not only is the blog post from 2 and a half years ago, but it was bashing the very first alpha release of the V programming language (vlang) that just hit GitHub at that time. Could you imagine doing a brutal bashing of Zig or Nim, the first week it came out? Then claiming they're vaporware? Make it make sense. An alpha of a programming language, much less a program, isn't feature complete on day one. This should be common sense. Trying to label a brand new alpha as vaporware is inappropriate at best. A fair and unbiased critic gives a project a reasonable period of time to prove itself, not attempt to prematurely stomp all over it. Looks wrong to do so, at the least. Even crazier is then using that very old blog post, as the "be all, say all" for the state of the V language versus actually looking on GitHub and the documentation. V has been consistently coming out with weekly releases (https://github.com/vlang/v/releases https://github.com/vlang/v/releases) and updates for years now.
  - socialdemocrat 5y ago
    It is like Newton’s second law or something: anything deeply loved must be hated by an equal number of people with equal intensity. Otherwise there will not be balance in the force… or something.
    - 3a2d29 5y ago
      Hahaha can this please become a internet proverb
- fulafel 5y ago
  It has many of the virtues of Rust, and lacking some of the sins, probably HN likes it for the same reasons as Rust. Rust also took a while to make it onto the radar but then it was popping up more frequently.
- sharikous 5y ago
  Somehow zig has become the "new C" and Rust has become the "new C++" in the community, I guess. I don't think there is something strange about the recent days. Sometimes there are small waves about that and there have been in the past.
- ksec 5y ago
  >I've been seeing a lot of posts about Zig recently. About 4 reached HN front page in the past 30 days. Not really that much. And that is already considered an outliner in the history of Zig.
asdfasgasdgasdg 5y ago
It's an interesting analysis, but I'm a little skeptical that there is any partical scenario where Linux would be runnable and a 1.2 kB program will significantly underperform a 600B program. The program would have to be small indeed for this difference to be material.
- Aransentin 5y ago
  Between a 1.2 KiB and 600 Byte program, probably not, no. I wrote that section to confront the general idea that program startup performance is irrelevant and that optimizing it doesn't matter; a language that assumes so will start piling up features until it actually does, like it does for C in the example.
dleslie 5y ago
Interestingly, I can't seem to get an empty nim programme below 32k. #> touch foo.nim #> nim c -d:release --opt:size -d:strip -d:danger foo.nim #> ls -lhs foo | cut -d\ -f1 32K
- b3morales 5y ago
  Same with Swift (on Mac) % touch foo.swift % swiftc -Osize -Xlinker -x foo.swift % ls -lh foo | cut -d' ' -f10 33K % strip foo % ls -lh foo | cut -d' ' -f10 33K
- goodpoint 5y ago
  With --os:standalone and panicoverride.nim it goes down to 15k And down to *150 bytes* with some hacks https://hookrace.net/blog/nim-binary-size/ https://hookrace.net/blog/nim-binary-size/
  - dleslie 5y ago
    Very handy! Thank-you.
NikolaeVarius 5y ago
> I've watched friends try Go and immediately uninstall the compiler when they see that the resulting no-op demo program is larger than 2 MiB. That seems a bit extreme > Overhead breeds complacency — if your program is already several megabytes in size, what's a few extra bytes wasted? Such thinking leads to atrocities like writing desktop text editors bundled on top of an entire web browser I'm still on board
- imoverclocked 5y ago
  > I'll allow it. ABI compliance is a very good reason for "wasting" 3 bytes of code, and should arguably be added to our original assembly program I guess we all have some set of scope creep that we take as OK. ABI compliance for some, GC or other niceties for others, and then there is anything node/electron based.
- unbanned 5y ago
- JulianMorrison 5y ago
  I'm imagining that the Go people would have a hard time making the compiled program smaller, because they're bundling in a M:N threading system, inter-thread channels, a garbage collector, a stack resizer, a syscall parking and reactivation system, and all of the above are by necessity mutually interdependent.
  - jaytaylor 5y ago
    Perhaps functional chunks could be excluded from the final emitted binary when they're unused / unreachable from main? How hard would it be to check the AST for a go program's usage of channels, goroutines, etc at compile time? As these are features not used by the go language itself, it seems nearly trivial (no jit or other super dynamicism).
    - JulianMorrison 5y ago
      The GC needs to mess with and start and stop and throttle threads. The threads resize their stacks and that needs to talk to the GC. System calls park and restart threads. And so forth. If you use any of it you'd need all of it.
ftrobro 5y ago
"Aggressively stripping out all the unnecessary trash that the linker puts into it makes it 297 bytes" Reminds me of how impressive 256 byte intros are, like this one: https://www.youtube.com/watch?v=w72MXbAIJVg https://www.youtube.com/watch?v=w72MXbAIJVg
- jsheard 5y ago
  Those are impressive but it's not really a fair comparison, 256 byte intros are typically DOS executables which only require a handful of bytes worth of boilerplate before you're putting pixels on the screen. The OP is working with Linux executables, which have a much higher fixed overhead to get running nevermind display any graphics, and that's reflected in the smallest category for Linux and Windows intros being 4096 bytes.
- qayxc 5y ago
  You cannot compare a DOS COM program to an ELF binary, though. The ELF header alone is 64 bytes while COM files have no header and can fit more than a Hello World program into 64 bytes (uncompressed): mov ah,9 mov dx,108 int 21 ret db "Hello world!$" Using just debug.com (on DOS) this results in a 21 byte COM executable that prints "Hello world!" to the console. This simply isn't possible with formats like ELF, no matter what the linker does. Since DOS also allows direct access to video memory, just switching to VGA mode (320x200, 8-bit colours, e.g. using mov ax,13h; int 10h) will allow you to create fancy graphics with just a few bytes. In fact, I can get a colour pattern on the screen, wait for a key press, and return to text mode in just 45 bytes (for use with debug.com): a 100 mov ax,13 int 10 mov ax,a000 mov es,ax xor di,di xor ax,ax mov cx,fa00 mov es:[di],al inc ax inc di dec cx jnz 111 mov ax,0600 mov dx,ff int 21 jz 119 mov ax,3 int 10 mov ax,4c00 int 21 n vgademo.com rbx 0 rcx 2D w q This should work on any DOS machine and in DOSBox (I used VDos to create the COM file since I don't have a DOS assembler installed, and debug.com is included in vDOS) and is smaller than just an ELF header :D
goodpoint 5y ago
This is gold: """ Overhead breeds complacency — if your program is already several megabytes in size, what's a few extra bytes wasted? Such thinking leads to atrocities like writing desktop text editors bundled on top of an entire web browser, and I think it would be nice to have a language that pushes people to be a bit more mindful of the amount of resources they're using. """
- unnouinceput 5y ago
  Reason why I stopped using Skype was that they started to use Electron. That was the last drop a decade ago.
moonchild 5y ago
No comment on content. However: > What's up with the and rsp,0xfffffffffffffff0? That's because the function manually aligns the stack to the next 16-byte boundary. I'm not sure why the stdlib does this. The SystemV ABI (§2.3.1) guarantees an initial alignment of 16 already, so it should be superfluous. Linux does not make any such guarantee, however; so in order for _start to call functions using the sysv ABI in a compliant fashion, it must provide them with an aligned stack.
- Aransentin 5y ago
  Do you know offhand if the guarantees made by the Linux ELF loader is documented anywhere? I did search for it myself but didn't find anything authoritative.
  - moonchild 5y ago
    No, but I can tell you as a point of practicum that when I forgot to align the stack, clang-generated code faulted under linux.
  - mananaysiempre 5y ago
    There’s a walkthrough of the relevant kernel code in the superb “How programs get run” series[1], and it seems to try for 16-byte alignment on all platforms. Normally this kind of thing would be in the relevant System V ABI Processor Supplement (officially, by way of the SVID and gABI, but everybody just refers to the psABI directly) [2], in the “Process Initialization” section (the above-mentioned §2.3), but note e.g. the story of how the GCC developers accidentally defaulted to a stricter alignment than the spec said and then decided to just run with it and rewrite the spec after the fact[3]. [1] https://lwn.net/Articles/631631/ https://lwn.net/Articles/631631/ [2] E.g. https://gitlab.com/x86-psABIs https://gitlab.com/x86-psABIs for x86 [3] https://stackoverflow.com/a/49397524 https://stackoverflow.com/a/49397524
Thaxll 5y ago
I know it's easy to troll on JS but Electron is a very succesful project that lead to softwares used by hundred of millions of people, can't say the same about Zig or its future.
- gameswithgo 5y ago
  There are a lot of popular things that are horrible.
  - Thaxll 5y ago
    We should thanks those to push software further. php, mysql, js they allow other project to improve.
    - geodel 5y ago
      Oh yea, I love all that ad-tracking by websites which I do not even visit. They are definitely pushing further.
    - jcelerier 5y ago
      It is absolutely impossible to know if in a parallel world where they hadn't existed, everything wouldn't be unambiguously better for everyone
  - bsder 5y ago
    I'm tired of the slagging on Electron without providing something better. Cross-platform development is known to suck. Someone from the Linux world could have created a cross-platform GUI toolkit system that worked on Windows, Linux, OS X, Android, etc. and "didn't suck". People have tried. Linux folks bitched about them all. So GitHub created something. And it appears to suck least. Want to help fix the "problem"? Here's how you break the logjam: create a modern text layout/shaping/rendering toolkit based around vectors/paths that works natively on modern graphics cards (aka: use Vulkan). Text and vector rendering are the bottlenecks that cause everybody to use suboptimal solutions like "use the Chromium renderer" (Skia underneath) because it's such a bottomless swamp of complexity.
gameswithgo 5y ago
The bit about people uninstalling when they see a 2MB no-op demo program is so dumb. That is a fixed cost, its just because Go packages it's runtime in the EXE so you can distribute it and expect it to actually work rather than depending on a runtime being available on the system. Sure there are niche cases where that isn't appropriate, and you don't use Go for those. But that initial 2MB doesn't tell you anything about how program size grows for actual projects.
- deleted 5y ago
  [deleted]
alkonaut 5y ago
Launching entire processes to do small operations is an antipattern. Whether a program is 1k or 10k can’t make that much difference if the minimum process spawn time is counted in hundreds of milliseconds? Yes, I know, it’s about the philosophy of unnecessary waste and not actually about the first kb, a philosophy I can certainly support. But still, launching a 1MB program and then launching threads from it takes a fraction of the time per thread. The 1MB process start time is quickly amortized. I know as he mentions there are situations where small processes are launched hundreds of times, but these days I think of it as a disappearing antipattern. Consider how in the past it was common with compilers to use one process to compile one source file and exit. Or how a web server would serve one request and then exit. There is a reason that went out of fashion. So the only time I’d reach for actually making a tiny executable out of performance concerns would be if I couldnt use a fatter binary and I knew the tool (for whatever reason) had to be invoked a lot, and it wasn’t under my control.
- vvanders 5y ago
  While I get where you're going with this however if you use small binaries that are built for efficiency then your process start time isn't 100s of ms, it's a least an order of magnitude faster. Using a single process also guarantees a higher degree of isolation and resistance to memory leaks which can be important on certain systems.
- wnoise 5y ago
  Processes are the natural unit for user composability and control. It's more or less necessary for any multiple language scenario. That really is worth a lot. And it makes lowering the costs for that case quite worthwhile.
- chrismorgan 5y ago
  > if the minimum process spawn time is counted in hundreds of milliseconds It’s not. Here’s an extremely rudimentary bash/zsh measurement, spawning a thousand processes: time (i=0; while [ $i -lt 1000 ]; do i=$(($i + 1)); /usr/bin/true; done) This is taking my Linux-running laptop 450–530ms under zsh and 300–320ms under bash, suggesting a process spawn time of under half a millisecond, not hundreds. Another variant: time (i=0; while /usr/bin/test $i -lt 1000; do i=$(($i + 1)); done) Around 540ms in zsh and 440ms in bash. I know that Windows has historically had very slow process spawn by comparison (no idea of the current situation, I just remember it being a real drag on some process-heavy makefiles I was using at work in WSL1 days), but my recollection says that even it wasn’t into hundreds of milliseconds.
Sniffnoy 5y ago
Related: Just how small can you make an executable on 32-bit Linux? http://www.muppetlabs.com/~breadbox/software/tiny/ http://www.muppetlabs.com/~breadbox/software/tiny/ (You'll notice that, despite the change from 32-bit to 64-bit, the figure of 297 bytes mentioned in the OP as how much you'd get from doing everything in assembly and aggressively stripping is the same figure that Brian Raiter comes up with in part III of the Teensy Files, where he attempts to do everything in a totally above-board manner.)
KronisLV 5y ago
> Overhead breeds complacency — if your program is already several megabytes in size, what's a few extra bytes wasted? Such thinking leads to atrocities like writing desktop text editors bundled on top of an entire web browser, and I think it would be nice to have a language that pushes people to be a bit more mindful of the amount of resources they're using. You know, reading this kind of hurts. On one hand, i fully agree. If we take something like Visual Studio Code as an example, the folks at Microsoft have seemingly done much of what's possible to make it feel snappy and responsive, sometimes to surprisingly good results, yet i also remember how sluggish Brackets or Atom were as editors, both also based on browser technology. On the other hand, i feel that it's not the filesize that developers care about when choosing browser tech, but rather their hands are forced because of a lack of other good options out there. Show me a widely supported cross platform GUI framework that's as easy to pick up and use as Electron's stack for the developers of our current year - people who in many cases don't have years to master many different technologies, but just want/need to apply much of what they already know to deliver software in short amounts of time. For better or worse, browser technologies have become the one common platform, in more ways than one. Of course, i'll actually try to answer my own question above. In my eyes, the way how Lazarus/Pascal approached this issue was great: their LCL (https://en.wikipedia.org/wiki/Lazarus_Component_Library https://en.wikipedia.org/wiki/Lazarus_Component_Library) provided a set of common components and then allowed them to target Win32, GTK, Qt, Carbon, ... based on the compile target, while on the tooling side they still had a really great RAD environment, with all of the drag & drop functionality of yesteryear. Now, Lazarus/Pascal are basically dead due to lack of hype/interest in those technologies, but they came pretty close to being the best option out there in my eyes! Apart from that, i'm not quite sure. Over the years there have been many attempts at creating cross platform GUI frameworks for .NET, but there's still nothing truly stable yet. In Java, i really liked Swing because it was just so darn functional and simple to implement (with IDEs also having GUI builders), however many rather disliked how it didn't really look or feel native in many cases, which may or may not be relevant for particular types of software. In recent years, there also was JavaFX/OpenJFX (https://openjfx.io/ https://openjfx.io/) which i think is a good step in the right direction, but last i checked the tooling wasn't quite there yet - an integrated workflow that just lets you create and drag around windows/components without bothering too much to read the docs, whilst also letting you edit the autogenerated code after a rough wireframing/prototyping pass, should the need arise. In most other tech stacks, like Python, packaging and other concerns can be a mess, as can the loosely coupled tools be cumbersome to work with - sometimes you just want one executable (or close to it) at the end of your build steps, which can run on any supported platform. The fact of the matter is, that if there was something easy to use, many would switch away from Electron on a whim. Not everyone is smart enough or has the time to grok lots of different technologies, or learn something a bit lower level like Qt or GTK, which in lieu of bindings for higher abstraction level languages, will typically be used in language with plenty of footguns, avoiding which takes discipline and knowledge. Regardless, not everyone needs the high customizability of the web platform. Sometimes just having native UI components being created from some abstracted common set of components would be fully enough. But until technologies that make that easy surface, we'll just keep complaining about Electron every year.
gbrown_ 5y ago
Not sure why the article links to some runtimejs copy of musl [1]. It's quite old (2014 vintage) to the point where the referenced code is no longer present upstream [2]. [1] https://github.com/runtimejs/musl-libc/blob/master/crt/x86_64/crt1.s#L11 https://github.com/runtimejs/musl-libc/blob/master/crt/x86_6... [2] https://git.musl-libc.org/cgit/musl/commit/?id=6fef8cafbd0f6f185897bc87feb1ff66e2e204e1 https://git.musl-libc.org/cgit/musl/commit/?id=6fef8cafbd0f6...
- Aransentin 5y ago
  Thank you. I've fixed it by linking to the proper upstream repository instead.
kwhitefoot 5y ago
This sort of thing makes me think fondly of using Fortran many years ago (I forget which version). Then every subroutine was separately compiled into a separate object file. The linker linked only those that were actually used (if I remember correctly). Of course there was no dynamic dispatch so it wasn't difficult to prove what was and wasn't needed.
- mananaysiempre 5y ago
  Native-code libraries that are not hostile to static linking usually do this kind of thing even now, and linkers will, indeed, figure out which parts are needed and pull out only those. Even Glibc does it when statically linked, though its sprawling dependency graph makes the result less than helpful.

186 points by matu3ba 5y ago

I've been seeing a lot of posts about Zig recently. Out of curiosity is there a specific reason these are more common (like a recent big project or release)? Not hating, just wondering. EDIT: Just saw there was a new release 10 days ago, although it wasn't 1.0

dnautics 5y ago
Just fyi, zig 1.0 is likely years out.
isaiahg 5y ago
The people who like zig really like zig so they upvote it to the top while the people who don't like zig are at worst indifferent to it. So no one really complains. But we're starting to reach the point where zig is becoming popular and people will hate it for that alone very soon. Because we're all really just cavemen typing on keyboards and we can't even discuss how to encode text strings without descending into tribal war.
- gompertz 5y ago
  Ironically, V programming language has 2-3x the amount of github stars (decent measure of popularity) to zig/nim, yet has been the brunt of general hate here on HN from day one. (Mostly, as I can tell, due to some single individual blog Christine something?;that everyone has taken as gospel).
  - saagarjha 5y ago
    That blog post put into words a sentiment that had been around for quite a while.
  - Tomte 5y ago
    https://christine.website/blog/v-vaporware-2019-06-23 https://christine.website/blog/v-vaporware-2019-06-23
    - DyslexicAtheist 5y ago
      never heard of V and this blog was the introduction I didn't know I needed. beautiful but brutal :D ... thank you
      - gompertz 5y ago
        Don't forget the post is 2.5 years old... Lots has evolved.
  - kaba0 5y ago
    The V website did in fact contain impossibly wild claims that were taken down when called out. Add to the fact that it was closed source for a long time, but had an ongoing patreon, you could easily see the possibility of a scam in all that. And I personally haven’t seen evidence to the contrary still.
  - AnIdiotOnTheNet 5y ago
    V was also called out by Andrew Kelly (Zig's originator) and Ginger Bill (of Odinlang fame). A lot of people who knew stuff about compilers and languages had things to say about it, it wasn't just one blog.
  - detaro 5y ago
    github stars are a pretty crappy measure of anything. maybe for "people who've seen it and thought it looked vaguely interesting" (which something like V that makes a big splash with gigantic promises easily hits), but even that is vague, given how differently people use them. (People making a big deal out of them is a pretty good negative signal though)
  - isaiahg 5y ago
    Thankfully much of the controversy around V has escaped me. The clashes between proponents and detractors has mostly occurred on my periphery and it comes across rather silly to me. And I realize that will make me unpopular with both sides. It reminds me more of highschoolers arguing rather than than engineers actually trying to solve something, in that no one is fully wrong and everyone is a little bit right. One side should realize they're deriding a project that's still in its infancy and it's bound to be unfinished, buggy, off-kilter, and missing features that are still more or less just rough ideas in the heads of the creators. The same can be said for any early project. And one side needs to accept the creators were a bit overzealous and advertised features that we're really just rough ideas in their heads. And that fighting criticism with anger just makes those criticizing double down in their energy and aggressiveness. I'm sure V will be a fine language some day. I actually like the simple style of Go's syntax. It's a breath of fresh air when you're up to your neck in "Value<double, SIUnits::m> distance;" Though I question if it actually brings anything new more than some nicer syntax. I might wait until it's closer to a v1 and make something in it for my blog.
    - gompertz 5y ago
      Thanks for saying all this, probably one of the more mature insights. Personally I find V to already be a fine language - it improves on everything I feel Go just slightly missed the mark on. Regarding the hostility towards the performance claims; even if they aren't reaching those claims, the language is nonetheless extremely fast - so fast, that missing the claims is a mute point from a user perspective. It uses TCC on the backend; which everyone knows, and nobody disputes, is a very small and fast compiler. I understand/derive people are maybe upset the author is getting Patreon/Github donations based (in their opinion) on these 'false' claims. I don't think that's the case at all - people are thinking it's causation, when it's mere correlation. It's a still-obscure language, and it's not like they are selling Norwex cleaning supplies at a convention of everyday people walking by. The landing page isn't attracting your family relative, compelling them to donate money on Patreon. It's an extremely small group of people that are going to pay even the slightest interest to the project. People who have an interest in a boutique languages and providing monetary support are more than likely doing so out of interest in the project's goals (obtainable, or otherwise), appealing syntax, ambitions of the author, github activity, and general goodness; not solely off some bullets on a landing page - especially in a world where we know 99% of that is always shilled bullshit from VC's, bigbox products, etc. etc. Undoubtedly, the author could have maybe done better PR - who doesn't stumble at first though? Like, really. Everything I see referenced is from articles 2.5-3 years old... from a single blog to boot. Notwithstanding, the donations (which seem to be the target of most peoples comments), are around $1,000/month; this isn't really a large amount of money; but people are acting like this is $20,000/month.
  - Tozen 5y ago
    Not only is the blog post from 2 and a half years ago, but it was bashing the very first alpha release of the V programming language (vlang) that just hit GitHub at that time. Could you imagine doing a brutal bashing of Zig or Nim, the first week it came out? Then claiming they're vaporware? Make it make sense. An alpha of a programming language, much less a program, isn't feature complete on day one. This should be common sense. Trying to label a brand new alpha as vaporware is inappropriate at best. A fair and unbiased critic gives a project a reasonable period of time to prove itself, not attempt to prematurely stomp all over it. Looks wrong to do so, at the least. Even crazier is then using that very old blog post, as the "be all, say all" for the state of the V language versus actually looking on GitHub and the documentation. V has been consistently coming out with weekly releases (https://github.com/vlang/v/releases https://github.com/vlang/v/releases) and updates for years now.
- socialdemocrat 5y ago
  It is like Newton’s second law or something: anything deeply loved must be hated by an equal number of people with equal intensity. Otherwise there will not be balance in the force… or something.
  - 3a2d29 5y ago
    Hahaha can this please become a internet proverb
fulafel 5y ago
It has many of the virtues of Rust, and lacking some of the sins, probably HN likes it for the same reasons as Rust. Rust also took a while to make it onto the radar but then it was popping up more frequently.
sharikous 5y ago
Somehow zig has become the "new C" and Rust has become the "new C++" in the community, I guess. I don't think there is something strange about the recent days. Sometimes there are small waves about that and there have been in the past.
ksec 5y ago
>I've been seeing a lot of posts about Zig recently. About 4 reached HN front page in the past 30 days. Not really that much. And that is already considered an outliner in the history of Zig.

asdfasgasdgasdg 5y ago

It's an interesting analysis, but I'm a little skeptical that there is any partical scenario where Linux would be runnable and a 1.2 kB program will significantly underperform a 600B program. The program would have to be small indeed for this difference to be material.

Aransentin 5y ago
Between a 1.2 KiB and 600 Byte program, probably not, no. I wrote that section to confront the general idea that program startup performance is irrelevant and that optimizing it doesn't matter; a language that assumes so will start piling up features until it actually does, like it does for C in the example.

dleslie 5y ago

Interestingly, I can't seem to get an empty nim programme below 32k. #> touch foo.nim #> nim c -d:release --opt:size -d:strip -d:danger foo.nim #> ls -lhs foo | cut -d\ -f1 32K

b3morales 5y ago
Same with Swift (on Mac) % touch foo.swift % swiftc -Osize -Xlinker -x foo.swift % ls -lh foo | cut -d' ' -f10 33K % strip foo % ls -lh foo | cut -d' ' -f10 33K
goodpoint 5y ago
With --os:standalone and panicoverride.nim it goes down to 15k And down to *150 bytes* with some hacks https://hookrace.net/blog/nim-binary-size/ https://hookrace.net/blog/nim-binary-size/
- dleslie 5y ago
  Very handy! Thank-you.

NikolaeVarius 5y ago

> I've watched friends try Go and immediately uninstall the compiler when they see that the resulting no-op demo program is larger than 2 MiB. That seems a bit extreme > Overhead breeds complacency — if your program is already several megabytes in size, what's a few extra bytes wasted? Such thinking leads to atrocities like writing desktop text editors bundled on top of an entire web browser I'm still on board

imoverclocked 5y ago
> I'll allow it. ABI compliance is a very good reason for "wasting" 3 bytes of code, and should arguably be added to our original assembly program I guess we all have some set of scope creep that we take as OK. ABI compliance for some, GC or other niceties for others, and then there is anything node/electron based.
unbanned 5y ago
JulianMorrison 5y ago
I'm imagining that the Go people would have a hard time making the compiled program smaller, because they're bundling in a M:N threading system, inter-thread channels, a garbage collector, a stack resizer, a syscall parking and reactivation system, and all of the above are by necessity mutually interdependent.
- jaytaylor 5y ago
  Perhaps functional chunks could be excluded from the final emitted binary when they're unused / unreachable from main? How hard would it be to check the AST for a go program's usage of channels, goroutines, etc at compile time? As these are features not used by the go language itself, it seems nearly trivial (no jit or other super dynamicism).
  - JulianMorrison 5y ago
    The GC needs to mess with and start and stop and throttle threads. The threads resize their stacks and that needs to talk to the GC. System calls park and restart threads. And so forth. If you use any of it you'd need all of it.

ftrobro 5y ago

"Aggressively stripping out all the unnecessary trash that the linker puts into it makes it 297 bytes" Reminds me of how impressive 256 byte intros are, like this one: https://www.youtube.com/watch?v=w72MXbAIJVg https://www.youtube.com/watch?v=w72MXbAIJVg

jsheard 5y ago
Those are impressive but it's not really a fair comparison, 256 byte intros are typically DOS executables which only require a handful of bytes worth of boilerplate before you're putting pixels on the screen. The OP is working with Linux executables, which have a much higher fixed overhead to get running nevermind display any graphics, and that's reflected in the smallest category for Linux and Windows intros being 4096 bytes.
qayxc 5y ago
You cannot compare a DOS COM program to an ELF binary, though. The ELF header alone is 64 bytes while COM files have no header and can fit more than a Hello World program into 64 bytes (uncompressed): mov ah,9 mov dx,108 int 21 ret db "Hello world!$" Using just debug.com (on DOS) this results in a 21 byte COM executable that prints "Hello world!" to the console. This simply isn't possible with formats like ELF, no matter what the linker does. Since DOS also allows direct access to video memory, just switching to VGA mode (320x200, 8-bit colours, e.g. using mov ax,13h; int 10h) will allow you to create fancy graphics with just a few bytes. In fact, I can get a colour pattern on the screen, wait for a key press, and return to text mode in just 45 bytes (for use with debug.com): a 100 mov ax,13 int 10 mov ax,a000 mov es,ax xor di,di xor ax,ax mov cx,fa00 mov es:[di],al inc ax inc di dec cx jnz 111 mov ax,0600 mov dx,ff int 21 jz 119 mov ax,3 int 10 mov ax,4c00 int 21 n vgademo.com rbx 0 rcx 2D w q This should work on any DOS machine and in DOSBox (I used VDos to create the COM file since I don't have a DOS assembler installed, and debug.com is included in vDOS) and is smaller than just an ELF header :D

goodpoint 5y ago

This is gold: """ Overhead breeds complacency — if your program is already several megabytes in size, what's a few extra bytes wasted? Such thinking leads to atrocities like writing desktop text editors bundled on top of an entire web browser, and I think it would be nice to have a language that pushes people to be a bit more mindful of the amount of resources they're using. """

unnouinceput 5y ago
Reason why I stopped using Skype was that they started to use Electron. That was the last drop a decade ago.

moonchild 5y ago

No comment on content. However: > What's up with the and rsp,0xfffffffffffffff0? That's because the function manually aligns the stack to the next 16-byte boundary. I'm not sure why the stdlib does this. The SystemV ABI (§2.3.1) guarantees an initial alignment of 16 already, so it should be superfluous. Linux does not make any such guarantee, however; so in order for _start to call functions using the sysv ABI in a compliant fashion, it must provide them with an aligned stack.

Aransentin 5y ago
Do you know offhand if the guarantees made by the Linux ELF loader is documented anywhere? I did search for it myself but didn't find anything authoritative.
- moonchild 5y ago
  No, but I can tell you as a point of practicum that when I forgot to align the stack, clang-generated code faulted under linux.
- mananaysiempre 5y ago
  There’s a walkthrough of the relevant kernel code in the superb “How programs get run” series[1], and it seems to try for 16-byte alignment on all platforms. Normally this kind of thing would be in the relevant System V ABI Processor Supplement (officially, by way of the SVID and gABI, but everybody just refers to the psABI directly) [2], in the “Process Initialization” section (the above-mentioned §2.3), but note e.g. the story of how the GCC developers accidentally defaulted to a stricter alignment than the spec said and then decided to just run with it and rewrite the spec after the fact[3]. [1] https://lwn.net/Articles/631631/ https://lwn.net/Articles/631631/ [2] E.g. https://gitlab.com/x86-psABIs https://gitlab.com/x86-psABIs for x86 [3] https://stackoverflow.com/a/49397524 https://stackoverflow.com/a/49397524

Thaxll 5y ago

I know it's easy to troll on JS but Electron is a very succesful project that lead to softwares used by hundred of millions of people, can't say the same about Zig or its future.

gameswithgo 5y ago
There are a lot of popular things that are horrible.
- Thaxll 5y ago
  We should thanks those to push software further. php, mysql, js they allow other project to improve.
  - geodel 5y ago
    Oh yea, I love all that ad-tracking by websites which I do not even visit. They are definitely pushing further.
  - jcelerier 5y ago
    It is absolutely impossible to know if in a parallel world where they hadn't existed, everything wouldn't be unambiguously better for everyone
- bsder 5y ago
  I'm tired of the slagging on Electron without providing something better. Cross-platform development is known to suck. Someone from the Linux world could have created a cross-platform GUI toolkit system that worked on Windows, Linux, OS X, Android, etc. and "didn't suck". People have tried. Linux folks bitched about them all. So GitHub created something. And it appears to suck least. Want to help fix the "problem"? Here's how you break the logjam: create a modern text layout/shaping/rendering toolkit based around vectors/paths that works natively on modern graphics cards (aka: use Vulkan). Text and vector rendering are the bottlenecks that cause everybody to use suboptimal solutions like "use the Chromium renderer" (Skia underneath) because it's such a bottomless swamp of complexity.

gameswithgo 5y ago

The bit about people uninstalling when they see a 2MB no-op demo program is so dumb. That is a fixed cost, its just because Go packages it's runtime in the EXE so you can distribute it and expect it to actually work rather than depending on a runtime being available on the system. Sure there are niche cases where that isn't appropriate, and you don't use Go for those. But that initial 2MB doesn't tell you anything about how program size grows for actual projects.

deleted 5y ago
[deleted]

alkonaut 5y ago

Launching entire processes to do small operations is an antipattern. Whether a program is 1k or 10k can’t make that much difference if the minimum process spawn time is counted in hundreds of milliseconds? Yes, I know, it’s about the philosophy of unnecessary waste and not actually about the first kb, a philosophy I can certainly support. But still, launching a 1MB program and then launching threads from it takes a fraction of the time per thread. The 1MB process start time is quickly amortized. I know as he mentions there are situations where small processes are launched hundreds of times, but these days I think of it as a disappearing antipattern. Consider how in the past it was common with compilers to use one process to compile one source file and exit. Or how a web server would serve one request and then exit. There is a reason that went out of fashion. So the only time I’d reach for actually making a tiny executable out of performance concerns would be if I couldnt use a fatter binary and I knew the tool (for whatever reason) had to be invoked a lot, and it wasn’t under my control.

vvanders 5y ago
While I get where you're going with this however if you use small binaries that are built for efficiency then your process start time isn't 100s of ms, it's a least an order of magnitude faster. Using a single process also guarantees a higher degree of isolation and resistance to memory leaks which can be important on certain systems.
wnoise 5y ago
Processes are the natural unit for user composability and control. It's more or less necessary for any multiple language scenario. That really is worth a lot. And it makes lowering the costs for that case quite worthwhile.
chrismorgan 5y ago
> if the minimum process spawn time is counted in hundreds of milliseconds It’s not. Here’s an extremely rudimentary bash/zsh measurement, spawning a thousand processes: time (i=0; while [ $i -lt 1000 ]; do i=$(($i + 1)); /usr/bin/true; done) This is taking my Linux-running laptop 450–530ms under zsh and 300–320ms under bash, suggesting a process spawn time of under half a millisecond, not hundreds. Another variant: time (i=0; while /usr/bin/test $i -lt 1000; do i=$(($i + 1)); done) Around 540ms in zsh and 440ms in bash. I know that Windows has historically had very slow process spawn by comparison (no idea of the current situation, I just remember it being a real drag on some process-heavy makefiles I was using at work in WSL1 days), but my recollection says that even it wasn’t into hundreds of milliseconds.

Sniffnoy 5y ago

Related: Just how small can you make an executable on 32-bit Linux? http://www.muppetlabs.com/~breadbox/software/tiny/ http://www.muppetlabs.com/~breadbox/software/tiny/ (You'll notice that, despite the change from 32-bit to 64-bit, the figure of 297 bytes mentioned in the OP as how much you'd get from doing everything in assembly and aggressively stripping is the same figure that Brian Raiter comes up with in part III of the Teensy Files, where he attempts to do everything in a totally above-board manner.)

KronisLV 5y ago

> Overhead breeds complacency — if your program is already several megabytes in size, what's a few extra bytes wasted? Such thinking leads to atrocities like writing desktop text editors bundled on top of an entire web browser, and I think it would be nice to have a language that pushes people to be a bit more mindful of the amount of resources they're using. You know, reading this kind of hurts. On one hand, i fully agree. If we take something like Visual Studio Code as an example, the folks at Microsoft have seemingly done much of what's possible to make it feel snappy and responsive, sometimes to surprisingly good results, yet i also remember how sluggish Brackets or Atom were as editors, both also based on browser technology. On the other hand, i feel that it's not the filesize that developers care about when choosing browser tech, but rather their hands are forced because of a lack of other good options out there. Show me a widely supported cross platform GUI framework that's as easy to pick up and use as Electron's stack for the developers of our current year - people who in many cases don't have years to master many different technologies, but just want/need to apply much of what they already know to deliver software in short amounts of time. For better or worse, browser technologies have become the one common platform, in more ways than one. Of course, i'll actually try to answer my own question above. In my eyes, the way how Lazarus/Pascal approached this issue was great: their LCL (https://en.wikipedia.org/wiki/Lazarus_Component_Library https://en.wikipedia.org/wiki/Lazarus_Component_Library) provided a set of common components and then allowed them to target Win32, GTK, Qt, Carbon, ... based on the compile target, while on the tooling side they still had a really great RAD environment, with all of the drag & drop functionality of yesteryear. Now, Lazarus/Pascal are basically dead due to lack of hype/interest in those technologies, but they came pretty close to being the best option out there in my eyes! Apart from that, i'm not quite sure. Over the years there have been many attempts at creating cross platform GUI frameworks for .NET, but there's still nothing truly stable yet. In Java, i really liked Swing because it was just so darn functional and simple to implement (with IDEs also having GUI builders), however many rather disliked how it didn't really look or feel native in many cases, which may or may not be relevant for particular types of software. In recent years, there also was JavaFX/OpenJFX (https://openjfx.io/ https://openjfx.io/) which i think is a good step in the right direction, but last i checked the tooling wasn't quite there yet - an integrated workflow that just lets you create and drag around windows/components without bothering too much to read the docs, whilst also letting you edit the autogenerated code after a rough wireframing/prototyping pass, should the need arise. In most other tech stacks, like Python, packaging and other concerns can be a mess, as can the loosely coupled tools be cumbersome to work with - sometimes you just want one executable (or close to it) at the end of your build steps, which can run on any supported platform. The fact of the matter is, that if there was something easy to use, many would switch away from Electron on a whim. Not everyone is smart enough or has the time to grok lots of different technologies, or learn something a bit lower level like Qt or GTK, which in lieu of bindings for higher abstraction level languages, will typically be used in language with plenty of footguns, avoiding which takes discipline and knowledge. Regardless, not everyone needs the high customizability of the web platform. Sometimes just having native UI components being created from some abstracted common set of components would be fully enough. But until technologies that make that easy surface, we'll just keep complaining about Electron every year.

gbrown_ 5y ago

Not sure why the article links to some runtimejs copy of musl [1]. It's quite old (2014 vintage) to the point where the referenced code is no longer present upstream [2]. [1] https://github.com/runtimejs/musl-libc/blob/master/crt/x86_64/crt1.s#L11 https://github.com/runtimejs/musl-libc/blob/master/crt/x86_6... [2] https://git.musl-libc.org/cgit/musl/commit/?id=6fef8cafbd0f6f185897bc87feb1ff66e2e204e1 https://git.musl-libc.org/cgit/musl/commit/?id=6fef8cafbd0f6...

Aransentin 5y ago
Thank you. I've fixed it by linking to the proper upstream repository instead.

kwhitefoot 5y ago

This sort of thing makes me think fondly of using Fortran many years ago (I forget which version). Then every subroutine was separately compiled into a separate object file. The linker linked only those that were actually used (if I remember correctly). Of course there was no dynamic dispatch so it wasn't difficult to prove what was and wasn't needed.

mananaysiempre 5y ago
Native-code libraries that are not hostile to static linking usually do this kind of thing even now, and linkers will, indeed, figure out which parts are needed and pull out only those. Even Glibc does it when statically linked, though its sprawling dependency graph makes the result less than helpful.