The "better behaved" way is to call vDSO. It's a magic mini-library which the kernel automatically maps into your address space. Thus the kernel is free to provide you with whatever code it deems optimal for doing a system call.

In particular some of the system calls might be optimized away and not require the `syscall` at all because they are executed in the userspace. Historically you could expect vDSO to choose between different mechanisms of calling the kernel (int 0x80, sysenter).

https://man7.org/linux/man-pages/man7/vdso.7.html

    #![no_std]
    #![no_main]
    
    use core::panic::PanicInfo;
    
    #[panic_handler]
    fn panic_handler(_panic: &PanicInfo<'_>) -> ! {
        // TODO: write panic message to stderr
        write(2, "Panic occured\n".as_bytes()); // TODO: panic location + message
        unsafe { sc::syscall!(EXIT, 255 as u32) };
        loop {}
    }
    
    fn write(fd: usize, buf: &[u8]) {
        unsafe {
            sc::syscall!(WRITE, fd, buf.as_ptr(), buf.len());
        }
    }
    
    #[no_mangle]
    pub extern "C" fn main() -> u32 {
        write(1, "Hello, world!\n".as_bytes());
        return 0;
    }

    rustc hello.rs -C panic=abort -C opt-level=3 -C link-arg=/entry:main

    #![no_std]
    #![no_main]

    #[panic_handler]
    fn panic_handler(_panic: &core::panic::PanicInfo<'_>) -> ! {
        unsafe { ExitProcess(111) };
    }

    #[no_mangle]
    pub extern "C" fn main() -> u32 {
        let msg = b"Hello, world!\n";
        unsafe {
            let stdout = GetStdHandle(-11);
            let mut written = 0;
            WriteFile(
                stdout,
                msg.as_ptr(),
                msg.len() as u32,
                &mut written,
                core::ptr::null_mut(),
            );
        }
        0
    }

    #[link(name = "kernel32")]
    extern "system" {
        fn ExitProcess(uExitCode: u32) -> !;
        fn GetStdHandle(nStdHandle: i32) -> isize;
        fn WriteFile(
            hFile: isize,
            lpBuffer: *const u8,
            nNumberOfBytesToWrite: u32,
            lpNumberOfBytesWritten: *mut u32,
            lpOverlapped: *mut (),
        ) -> i32;
    }

It may be worth noting that the associated pdb (aka debug database) is 208,896 bytes.

   rustc hello.rs -C panic=abort -C opt-level=3 -C link-args="/ENTRY:main /DEBUG:NONE /EMITPOGOPHASEINFO /EMITTOOLVERSIONINFO:NO /ALIGN:16"

(and if you're using a language with a stack, your executable probably ultimately loads as at least two pages: r/o and r/w)

I need roughly 24 bytes. 16kb means 16.384 bytes. I can think of better usage of $4000 space in memory, FLI for example.

In that sense, they are not "lost", just merely "unused".

So now it would be interesting to see how much of the 16kB were not padding, though. OP said they looked at it with Ghidra, so did they see 16kB of actual code?

Out of these 23 bytes, 15 bytes are consumed by the dollar-terminated string itself. So really only eight bytes of machine code that consists of four x86 instructions.

    > Given a hello world C++ snippet, submit the smallest possible compiled binary

[1]: https://www.muppetlabs.com/%7Ebreadbox/software/tiny/teensy....

That should be like 10 x86 instructions tops, plus the string data.

And the setup code is not completely useless, for example it is responsible for parsing command line parameters and actually running main. If you want to actually use libc instead of just writing assembly directly, you may need it.

You can strip

>_start Almost but not quite! _start is the name of the symbol that is executed first in the program. If you compile with -nostdlib, you need to provide this symbol yourself (this will be your new main).

For instance, when I tried to make the smallest x86-64 Hello World program (https://tmpout.sh/3/22.html), I ended up lengthening it from 11 to 15 instructions, while shortening the ultimate file from 86 to 77 bytes.

This was actually a perfect ending to this piece.

Sure you can: "tcc -run hello.c". Okay, technically that's an in-memory compiler rather than an interpreter.

For extra geek points, have your program say "Hellorld" instead of "Hello world".

What comes after the syscall is where everything gets very interesting and very very complicated. Of course, it also becomes much harder to debug or reverse-engineer because things get very close to the hardware.

Here's a quick summary, roughly in order (I'm still glossing over; each of these steps probably has an entire battalion of software and hardware engineers from tens of different companies working on it, but I daresay it's still more detailed than other 'tours through 'hello world'):

  - The kernel performs some setup setup to pipe the `stdout` of the hello world process into some input (not necessarily `stdin`; could be a function call too) of the terminal emulator process. 
  - The terminal emulator calls into some typeface rendering library and the GPU driver to set up a framebuffer for the new output. 
  - The above-mentioned typeface rendering library also interfaces with the GPU driver to convert what was so far just a one-dimensional byte buffer into a full-fledged two-dimensional raster image:
    - the corresponding font outlines for each character byte is loaded from disk;
    - each outline is aligned into a viewport; 
    - these outlines are resized, kerning and font metrics applied from the font files set by the terminal emulator;
    - the GPU rasterises and anti-aliases the viewport (there are entire papers and textbooks written on these two topics alone). Rasterisation of font outlines may be done directly in hardware without shaders because nearly all outlines are quadratic Bézier splines.
  - This is a new framebuffer for the terminal emulator's window, a 2D grid containing (usually) RGB bytes.
  - The windowing manager takes this framebuffer result and *composits* with the window frame (minimise/maximise/close buttons, window title, etc) and the rest of the desktop—all this is done usually on the GPU as well.
    - If the terminal emulator window in question has fancy transparency or 'frosted glass' effects, this composition applies those effects with shaders here.
  - The resultant framebuffer is now at the full resolution and colour depth of the monitor, which is then packetised into an HDMI or DisplayPort signal by the GPU's display-out hardware, depending on which is connected.
  - This is converted into an electrical signal by a DAC, and the result piped into the cable connecting the monitor/internal display, at the frequency specified by the monitor refresh rate.
    - This is muddied by adaptive sync, which has to signal the monitor for a refresh instead of blindly pumping signals down the wire
  - The monitor's input hardware has an ADC which re-converts the electrical signal from the cable into RGB bytes (or maybe not, and directly unwraps the HDMI/DP packets for processing into the pixel-addressing signal, I'm not a monitor hardware engineer).
  - The electrical signal representing the framebuffer is converted into signals for the pixel-addressing hardware, which differs depending on the exact display type—whether LCD, OLED, plasma, or even CRT. OLED might be the most complicated since each *subpixel* needs to be *individually* addressed—for a 3840 × 2400 WRGB OLED as seen on LG OLED TVs, this is 3840 × 2400 × 4 = 36 864 000 subpixels, i.e. nearly 37 million pixels.
  - The display hardware refreshes with the new signal (again, this refresh could be scan-line, like CRT, or whole-framebuffer, like LCDs, OLEDs, and plasmas), and you finally see the result. 

Nice explanation but you stopped at the human's visual system which is where everything gets very interesting and very very complicated. :)

[1] https://en.wikipedia.org/wiki/Visual_system

Otherwise, its gets very interesting and very very complicated. :)

However, the point of a hello world program is to introduce programming to beginners, and make a computer do something one can visibly see. I daresay this is made moot if you pipe it into /dev/null. I could then replace 'hello world' in the title with 'any program x that logs to `stdout`', and it wouldn't reach HN's front page.

In the same vein is this idea of 'a trip of abstractions'—I don't know about you, but I always found most of them very unsatisfying as they always stop at the system call, whether Linux or Windows. It really is afterwards where things get interesting, you can't deny that.

I just tried and it shows me 33738 lines (744 lines for C btw).

In a language like C++, even Hello World uses like half of all the language features.

With C you just need a definition for printf instead of including stdio. In the old days you'd get by without even defining it at all.

GCC and Clang have a `__builtin_printf()` instead, quite useful for adhoc printf-debugging without having to include stdio.h. Under the hood it just resolves to a regular printf() or puts() stdlib call though.

I was going to say that this looks like the type of dumb shit I said in undergrad while learning comouter basics.

Then I saw the OP is 16. Continue being a dumb ass OP, no one was born knowing and being confidently wrong is the fastest way to grow.

OPs sentiments are very much true. For example, there will never be a feature complete alternative to Chromium/WebKit/Gecko.

But there are movements to move software to a smaller stack, like the Gemini protocol for example.

People are realising how brittle and inefficient (in terms of runtime computer resource usage and human resource usage in maintaining them) modern complex software are.

We hope to see things get better.

Thanks OP for the article

That's because Google discovered that by infiltrating the standards committees they can build a much better moat than anything IE ever had.

To the point where everyone, including MS, gave up on implementing a web browser.

The fact that QUIC is now HTTP3 is both awesome in the biblical sense and would be completely unbelievable to anyone involved with the previous versions of the spec in the 90s and 00s.

I mean it's impossible for anyone to "fully understand". This post didn't even get to the hardware level!

This ancient Google+ post is one of my all time-favorites: Dizzying but Invisible Depth. https://archive.is/100Wn#selection-693.0-693.28

I do think it's critical for programmers to be curious and dig a few levels deep. This young programmer went about 7 levels deeper than almost anyone would. Kudos to him!

And yet, 99% of the people I've ever seen in the industry have no idea how any of the code they write works.

I used to ask a simple interview question, I wanted to see if potential hires could explain what a pointer or memory was. Few ever could.

This article is very much in that same friendly, explanatory spirit, although obviously it goes into greater depth and uses a modern system.

I think that's the answer to the question of "why do we have so many". It's a great thing you don't have to know about them. Go down a layer, and the people working there will think it's a great thing they don't have to worry about the abstraction below. Software development is, currently, a human task, so the human needs necessarily structure it.

I can't comment on web development...

Are in fact the things I think have become worse from the abstractions.

Well, the recent abstractions. I like the ones that were widespread until about 2018 or so.

You might save some bytes but boy how annoying and complicated it can get.

I just… wrote my previous comment so badly everyone legitimately missed the point that was in my head.

Consider that part framing.

My problem with modern abstractions is the wheel keeps getting reinvented by people who don't know the lessons from the previous times it was invented, even when they're making their wheel out of other wheels — which is how I feel when I notice a website using javascript to implement and tags or scroll regions whose contents can't be fully selected because it loads/unloads content dynamically 'for performance' because someone just assumed 10,000 lines of text in a browser would be slow without bothering to test it, or that I see HTTP servers returning status 200 while the body is JSON {"error": "server error"} or equivalent.

I could go on (also don't like VIPER) but this would turn a comment into a long blog post.

While I also don't like that web browsers are inner-OSes, can see how it happened from the second half of Zawinski's Law: Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can. - https://softwareengineering.stackexchange.com/questions/1502...

I thank and respect them, at the expense of some plentiful CPU cycles.

This is the conventional wisdom, but it's increasingly not true.