This is a rather speculative post about Julia being used for building systems from scratch, as an alternative to ‘the C way’.
Recently i spent some time learning Rust, as it infers it can be systems programming ‘for all’. But actually, like Dlang, its another reformation of the C way. People will still avoid it because its hard for those not already into the C way … and they are still kept from systems programming because of what it takes to do so.
I assert that there isnt enough systems programmers, and this is holding back the world - because learning the C way turns most people away. This also applies to Rust. i think that because of the C way, we still have the outdated limited duopoly of Unix and windows. I think its a bottleneck for human technology. Do you think its an issue?
I propose a way to do systems programming with higher level languages like julia, that completely bypasses any kind of C - so that ‘the coding masses’ can easily do systems programming. The flowering of innovation in apps land is kept from systems programming, imagine what a whole lot of new people could do in systems land.
I know Julia isnt trying to be that language, but could it be? Is it a reasonable candidate? Is it too high level? Or is the higher the level the better? Is there already a language trying to do this that i dont know about?
I personally think that problems are elsewhere. To use your terminology, we learn how to make languages less C-like and more normal person friendly (Python, Ruby, Julia, etc.), with its pluses and minuses. I don’t seen anyone that show how to make OS less OS-like and more normal programmer-friendly.
Also with OS world inertia factor is tremendous. People don’t want to spend the time learning theory of complexity, they just want they Word-like program to work and generate text they want to generate. And porting old software to new OS can be an nightmare, while writing new from the bottom up cost so much money.
For me this question should be rephrased “What language for writing OS we need?” and this is rather question to OS community, not to Julia community. Speed is only one factor among many, important one, but probably not the most important. What I mean about that, Android is written in Java, because convenience of using it outperformed loss of performance on smartphones.
From what I see, OS writers prefers rigid, explicit languages and one of the most problems with C is that it is not rigid and explicit enough. Yes, in C you need to declare types explicit, and from what I understand, this is what OS people want. You must stay what a type of variable is to everyone to know. Problem is that you have implicite conversion in C, so this knowledge is “lost” for programmer at some point. Go language, which was never aiming for OS writing, but for servers, removes implicit types conversions for all types like ints and floats, there only exception when it is allowed are some wrappers of previous types. I believe Rust did similar things.
Needless to say, this is opposite of what Julia do. Maybe not on the real of type conversion, but implicit calling of type specialized method. In Go you can’t write intVar + intFloat, because in Go don’t allow implicit conversion and has no notion of adding int to float. In Julia + can have literally hundreds of meanings and you can add another one itself. It take from us a much of burden of thinking about types, but while it is liberating when making numerical computation (and many other things), it seems be a opposite of what most OS people want.
Of course, you probably can find person that writes OS in Julia. But in every language community you kind find such super skilled person, that like extreme sports and this didn’t change OS landscape a bit.
I think these sort of questions crop up in large part because of the narrative that Julia is the one language to replace them all, but it’s important to remember that the “two language problem” exists in the context of scientific computing, or more broadly wherever both high performance and expressive syntax is valuable. The problem doesn’t exist in many other contexts, like systems programming.
As mentioned earlier in the thread, Julia has intentional design features that are at odds with the priorities of systems programming languages. I haven’t done it, just read a bit about it, but systems programming is close to the machine, has a machine-dependent layer at the least, and much more limited than application programming; for example, you can write OS kernels in C, but you can’t use the C standard library. By contrast, Julia is abstracted from the machine by several layers, portable, interactive, and is higher level than C in many other ways. Could you write Julia code and claim it’s an OS kernel? Yes. Could it be compiled to something that actually works? Not now. Assuming systems-Julia was designed, would it make coding easier and safer than using systems-C? Probably not.
There is actually some demand for stripping down Julia for some contexts. GPU programming is already in use. There’s related work on StaticCompiler; a Julia session has a large memory footprint, and people are interested in smaller executables that can run on more limited machines or integrate into other languages with little overhead. Although I doubt manual memory management will ever happen, the work on the compiler’s effect analysis could allow soft realtime applications to use a lot more mutables without needing the collector interrupting. I mention these because they seem to edge Julia in the direction you’re thinking of, but it’s still a far cry from systems programming.
I agree that “One language to rule the all” is popular phrase about Julia, but does anybody take it literally? I’m, mean, it could be, but it looks strange to me.
The two-languages problem that Julia attempts to solve is not having to use different languages to do different things, but having to rewrite in another language the code that you drafted to solve a given problem, because the original code (probably made in a high level, dynamic language to facilitate quick prototyping) does not scale well when the size of the problem increases.
Nope!
Julia is wonderful because it composes so well. I use it for about 90% of my work these days. However, safe it isn’t. It is sometimes unpredictable because two packages interact in ways that neither packages authors anticipated. Plus Julia uses a prodigious amount of memory.
Rust, on the other hand, is great because it has figured out how to handle concurrency and efficient memory allocation/deallocation in a reliably safe manner. As someone, who learned C/C++ decades ago, I find Rust super appealing because it fixes most of the problems with C/C++ by forcing you to do what you probably ought to have been doing all along. IMHO, C++ provides so much rope that it is almost impossible not to hang yourself. When I’ve used C++ (for embedded and other work), I usually restricted myself to C plus a few basic C++ extensions.
(I’m not a software engineer, so pardon the novice question.) Is there a standard definition of what is and isn’t included in the scope of the term “systems language”? I see this term used a lot (on Hacker News) to tout languages like Rust and Nim, but it seems to mean different things to different people—to some, it means a language for writing operating systems; to others, embedded systems/systems that are hard to update; to others still, a language for writing code for any purpose that has certain thread safety and memory safety guarantees. Or maybe all of these definitions are ultimately equivalent?
At any rate, to the extent that Julia’s goal is to solve the “two-language problem,” that goal feels very different than what people are talking about when they talk about the goals of a systems programming language (like Rust with its “batteries not included” philosophy).
We actually do have a dialect of Julia forming termed “unsafe” Julia where you might be able to more easily do systems level or embedded programming. For example, see
To do this, we do give up some features of Julia such as the garbage collector and dynamic memory allocation.