Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Yeah, but until a mainstream OS vendor jumps in, I don't see it happen.

Apple is now going full speed with Swift. All WWDC talks that weren't Objective-C specific used Swift.

Microsoft is happy going .NET Native + C++/CX.

UNIX tends to be married with C, due to the way they were developed together.

I doubt Firefox OS will ever allow for Rust based applications.

MirageOS is probably the one in the best position, but it will stay a research OS.

GenodeOS and L4 are also full C++.

Embedded OS vendors are pretty much a sample of real time Java, C and Ada.

So from the perspective of real systems programming I see an uphill battle for Rust.

But yeah, there is a real need for safer systems programming languages.



> I doubt Firefox OS will ever allow for Rust based applications.

Sure it will. Compile them to Web Assembly first :)

People have already run Rust code through Emscripten. (It's not well supported at the moment, but the amount of work to be done to polish it up isn't large.)


I am a firm believer in native code and consider Emscripten and Web Assembly nothing more than fads.


> Yeah, but until a mainstream OS vendor jumps in, I don't see it happen.

See what happening?

All Rust needs is LLVM support and a stable (probably C) ABI for OS features that it can link against (like libc).


Becoming a choosen systems programming language.

Until then it is just yet another programming language with an AOT compiler, whwre there is already a plethora to chose from.

We should learn from history of systems programming languages.

None of them survived without being tied to a specific OS.


> Until then it is just yet another programming language with an AOT compiler, whwre there is already a plethora to chose from.

Well, the borrow checker and safe manual memory management are unique features that allow moving a lot of code that previously had to be C++ for performance reasons to a safe language. (I've elaborated why safe dialects of Ada and such are not the same in previous posts.) I wouldn't characterize Rust as "just yet another systems programming language".


You missed the point.

I have meant if Rust fails to get adoption as systems programming language, it will become just another business language.


At least Rust has Servo and is being used in Firefox- while not really operating systems you would write Rust applications on, it's closer than many dead/dying systems languages have.

Another interesting route would be kernel modules- Rust could be a good language to write drivers in, if you need the extra security.

I don't think it necessarily needs a whole OS to itself just to survive.


Not just kernel modules—even userspace modules that are security-critical and used by lots of projects are good candidates for Rust. Think image decoders, media codecs, audio libraries, GL stacks, database engines, crypto libraries, etc.


>We should learn from history of systems programming languages. None of them survived without being tied to a specific OS.

How do you define systems programming? If you define it as writing operating systems then your statement is a bit of a tautology. If you define it as anything other than applications programming then I would say there are successful languages not tied to a specific OS, first and foremost Java.


Systems programming is the locus of development which spans boot firmware, operating system kernels, drivers, utilities and high performance middleware (API's to the operating system, numeric libraries/codecs, graphics, and whatever.)

Systems programming languages are characterized by requiring minimal run-time support, or supporting a version of themselves which is that way (e.g. ISO C has the concept of a "freestanding implementation", and there is a way for such a thing to be conforming).

As a rule of thumb, if it has no "freestanding implementation" or equivalent, then it's not a systems language.

I'm not aware that a flavor of Java exists with a toolchain that would let us rewrite U-Boot in Java, while keeping its footprint in the same ballpark. (I.e. the firmware image cannot contain an entire Java platform.)


I feel like that's an overly-aggressive definition of 'systems language.'


Could gcj produce suitable native code?


Any language capable of writing drivers, boot sectors...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: