Hacker News Reader

Comment by fulafel | Hacker News Reader

The project age is good background info. However Rust didn't invent memory-safety, there were reasonable options for system programming at that time too (eg Ocaml, Go, Ada, etc).

edit: Also D in safe mode like mentioend above - not sure if it was around in 2010?

View on HN

Another consideration (apart from the 64MB ROM / 8MB RAM configuration OpenWRT targets, up from 32MB / 4MB in 2010) is that the original—and still very popular—platform for OpenWRT is Linux on big-endian MIPS, which does not exactly have ubiquitous compiler support outside of the C world. (Rust treats it as Tier 2, on par with Windows on ARM and Solaris on x86-64, which isn’t bad as these things go.) So—Go is about as realistic as Java, OCaml I don’t think runs on MIPS, neither does MLton, and IIRC the GNU Ada implementation was in a much worse state then. There’s also the part where the devs are by necessity C hackers, what with sorting out the manufacturers’ kernel patches and all.

I think any language with a large runtime would be out of the question, because Openwrt has to fit into system with very limited storage.

To put it in context:

On some devices you have 32MB flash storage in total.

32 Megabytes, not gigabytes. This is not a typo.

This needs to fit the bootloader, the Linux kernel, the initrd, the rootfs containing all the user-space tools making OpenWRT an actual usable OS and whatever daemons you need to implement your particular network needs. Oh and you probably want the WebUI too.

In 32MBs. There are newspapers online which loads more than that just to show the front page!

There’s no room for 2MB HelloWorld type languages in this space.

It's even less than that. Current OpenWrt versions work on devices with 8 MB of flash and 64 MB of RAM. OpenWrt 19.07 worked on 4MB/32MB devices.

This is a good point. But Ocaml and Ada are not in the 2MB helloworld club (eg Ocaml is more like 200k), don't know about Go. Also accounting that to a single binary is not the right perspective I think - adopting a safe language in OpenWRT should be arranged so that all the programs using that language can share the same copy of the runtime.

200k is very large in the OpenWrt world

Ada then?

Eg on https://ada.godbolt.org/ you can see the default program compiled to ~25 lines of assembler.

edit: actually it contains a call to a bounds check function that presumably is in the runtime library, i don't know how big that is.

A major point in this is that C also has a fairly big runtime library that should be factored into the comparison!

Current OpenWRT uses musl libc[1] which can be optimized to have a tiny footprint and supports full static linking, before that it used ucLibc which was similarly optimized.

You can still build software for OpenWRT that requires the much bigger Glibc, but of course it will not work that well on devices with limited memory.

[1]: https://musl.libc.org/

Musl libc seems to be 2 MB ish, it's smaller than glibc but still something when comparing to other languages and their runtimes.

    464.7K Oct 15  2022 /lib/libc.so

As seen on openwrt on armv7l system

Also OpenWRT udev itself is tiny:

  20.0K Oct 13  2022 /usr/lib/libudev.so.1
   8.0K Dec 15  2022 /sbin/udevtrigger

> C also has a fairly big runtime library

The original releases of OpenWRT used uClibc, which is nowhere near Glibc levels of bloat (Musl beats it on code quality and is used today, but didn’t exist back then). Also, yeah, you’re going to have a libc on a Linux system no matter what, so this is one of the rare cases where dynamic linking makes for a legitimate optimization.

> A major point in this is that C also has a fairly big runtime library that should be factored into the comparison!

But libc will be there anyways, unless you are rewriting absolutely all of userland.

musl is a few hundred kb

Back then, your suggestions were niche languages (and some still are) and are still not popular for embedded systems or network equipment. Large runtimes or huge static binaries are not suitable due to the memory and storage constraints.

You have to consider the surrounding ecosystem. Those interested in such languages are not necessarily those interested in contributing solutions to the problem space. Any project attempting to use such a language in OpenWrt would very likely not have survived until today.

Reply on news.ycombinator.com