Hacker News Reader

Comment by titzer | Hacker News Reader

> My problem is that C was elevated to a role of prestige and power, its reign so absolute and eternal that it has completely distorted the way we speak to each other. Rust and Swift cannot simply speak their native and comfortable tongues – they must instead wrap themselves in a grotesque simulacra of C’s skin and make their flesh undulate in the same ways it does.

Lol at this. Love this eloquent style, and pretty much agree. However, C's reign is not absolute. Virgil compiles to tiny native binaries and runs in user space on three different platforms without a lick of C code, and runs on Wasm and the JVM to boot. I've invested 12+ years of my life to bootstrap it from nothing just to show it can be done and that we can at least have a completely different userspace environment. No C ABI considerations over here. It can be as romantic as just you and the kernel in Virgil land. Heh.

View on HN

But how would you link a library written in Rust to a Virgil program? Or vice versa?

That's the real problem the author is ranting about. If you've solved that, too, then I think that the author's article isn't the only Rust team member who'd like to talk to you.

> But how would you link a library written in Rust to a Virgil program? Or vice versa?

Sounds like that's Rust's problem, or maybe Virgil's? Why is it C's problem?

If Rust is going to "replace C" for systems work, as the more grandiose claims would have it, it's going to have to replace all of C.

It's not like writing a POSIX-like system is that hard. It's a lot of work, sure, but it's been done multiple times, by unpaid volunteers at that.

This complaint basically boils down to "We can't/won't/haven't reimplemented this low-level stuff in our whizzy new language, and that's somehow C's fault".

Your argument reads like: you shouldn't need to run Rust programs unless _the entire operating system_ is first rewritten in Rust. I doubt you really mean that, though...

No. More like "You shouldn't whine about the C infrastructure unless you're planning to replace it with something better."

C is only used for FFI because it provides a well-defined, stable interface for function calls that can be easily implemented by another language.

The article argues against every word of this statement.

The article is wrong.

C definitely doesn't provide a well-defined stable interface. Specific ABI definitions might, but there are 176 of those, and implementing all of those in another language is decidedly not what I'd call "easy".

It's been done multiple times, by small teams of unpaid volunteers.

"Easy"? Depends on your definition of "easy". Doable? Absolutely. But complaining won't get it done.

In most cases, I'd think those small teams support like a max of 5 ABIs, out of the 176.

Of course it's "possible". Of course, complaining about it won't get it done. But I can easily envision an alternate universe with the same OS & CPU architecture variety, that has the effort required for doing this be ten times smaller, and I don't see it being utterly pointless to ponder the viability of that if only just for fun (which the swearing in the article hints to me it is).

I, as an author of a small language implementation, would really prefer to not need to implement more than one C FFI ABI, much less 176. I'd meet somewhere in the middle, but 176? nah.

C provides an API, not an ABI.

The compiler provides a mapping from the stable, (relatively) portable, well-defined API -> the unstable, non-portable, ill-defined ABI of the host system.

> If Rust is going to "replace C" for systems work, as the more grandiose claims would have it, it's going to have to replace all of C.

... and people complain all the time about Rust fanatics talking about rewriting everything in Rust.

Yeah, they do talk about that a lot. They talk a lot about a lot of things.

They just don't ever do any of them.

And they say romance is dead lol

Anyway to build a GUI app?

Definitely looks like a cool project. Can you write an OS in it, for microcontrollers ?

Hmm, very interesting question. I think you could interface with X windows via IPC, but you'd have to build that IPC layer, which ultimately boils down to pipes/sockets. So that route would be doable, but probably a steep climb.

Another option would be to compile to Wasm and then import GUI-related functions that are then implemented in the Wasm host environment, e.g. JavaScript.

As for microcontrollers, that was in fact, Virgil I, circa 2006. :) My prototype compiler back then generated C code and then you could compile with avr-gcc. Nowadays, I don't have a C backend or native backend for microcontrollers, so it'd require a new backend and a new exe format. Or maybe again, try to compile Wasm to AVR.

Are you planning to do an arm64-darwin port for Virgil?

Yes, this would be very useful. I have it listed here [1] and am hoping to get either a student or a volunteer to do some work there.

[1] https://github.com/titzer/student-projects

Reply on news.ycombinator.com