The state of low-level system programming
erik-poupaert.blogspot.com
The state of low-level system programming
1–10 of 62 posts
Re: The state of low-level system programming
#2I really hope to see Go and Rust move in the direction of pluggable runtimes that can be embedded into a C host program. Currently, both runtimes require being seated as the main entry-point of the program to function. Both projects also have issues in their bug trackers to rectify this:
Rust issue: https://github.com/mozilla/rust/issues/3608
Go issue: http://code.google.com/p/go/issues/detail?id=2790
I wonder who will get there first.
Re: The state of low-level system programming
#3C code can call into rust: http://static.rust-lang.org/doc/rust.html#extern-functions
Re: The state of low-level system programming
#4there's also ats [http://www.ats-lang.org/]. somewhere on my long-term todo list is to write a library of efficient data strucures in ats, to take advantage of some of its safety guarantees.
Re: The state of low-level system programming
#5C code can call into rust: http://static.rust-lang.org/doc/rust.html#extern-functions
True, and so can C call back into go code with cgo. The problem is that it still requires that the main function be in a Rust/Go binary. A program written in C can't currently call into a library written in one of these two languages since the runtimes don't work unless they control the main entry point.
From the Rust doc linked: "The primary motivation of extern functions is to create callbacks for foreign functions that expect to receive function pointers."
Re: The state of low-level system programming
#6C code can call into rust: http://static.rust-lang.org/doc/rust.html#extern-functions
If you read what you linked to it says the main purpose is to provide C functions with callback arguments when called from Rust. It isn't clear from what you have written that this mechanism is available to generally access from C programs and scripting languages.
Re: The state of low-level system programming
#7there's also ats [ http://www.ats-lang.org/ ]. somewhere on my long-term todo list is to write a library of efficient data strucures in ats, to take advantage of some of its safety guarantees.
It's a pity ATS doesn't get more attention in the "Systems programming language" field. It can call into C, be called from C, provides a powerful type system, and can be used to write very low level code. I've written a few posts about how ATS can interact with C on my weblog here: http://www.bluishcoder.co.nz/tags/ats/
Re: The state of low-level system programming
#8Compatability with the C ABI I feel isn't a necesssity. On platforms built on C it is, but if you wanted to invent a new machine running a new system language with the ABI messes of C exonerated, you could. You would need to devise a translation layer in the OS executor to be able to interpret classic C ABI .so or .dll files for legacy applications and so you could compile C on these platforms, but that isn't a prohibitively hard challenge.
Re: The state of low-level system programming
#9C code can call into rust: http://static.rust-lang.org/doc/rust.html#extern-functions
True, and so can C call back into go code with cgo. The problem is that it still requires that the main function be in a Rust/Go binary. A program written in C can't currently call into a library written in one of these two languages since the runtimes don't work unless they control the main entry point. From the Rust doc linked: "The primary motivation of extern functions is to create callbacks for foreign functions…
Then is it even possible to make a program that can use libraries written in Rust and Go and C++? If everyone wants to control main(), is there an escape hatch provided by any of these languages, like a C function that can be explicitly invoked near program start?
Re: The state of low-level system programming
#10Vala does not seem to get much attention. It borrows C# syntax (and maybe Java), compiles down to C and offers nearly symmetrical interoperability as a result. I believe Ubuntu's Unity is written in Vala. Knowing Java, it was easy to acquire the syntax from the tutorial [https://live.gnome.org/Vala/Tutorial] in very little time.
For transparent access to compiled C libraries, external C functions need to be declared in a 'vapi' file and although these were already provided for a large part of the GNOME ecosystem, documentation on vapi syntax was nearly non-existent. Object-orientation and standard libraries are integrated with Gnome's GObject system and Glib libraries which I found unfamiliar and usually better documented in C at the time.