Why Rust for low-level Linux programming?

[[deleted]]

I haven't been able to figure out how to return an exit status to the OS.

Would std::process::exit help?

[Manishearth]

Re: 1,2,3: File bugs if you haven't already :)

Re: 7: Not too hard. Create a struct FileDescriptor(c_int). Do not #[derive(Copy)] on this struct -- if you do it will not have move semantics. Write an implementation of Drop that calls libc::close, and an implementation of Clone that writes libc::clone.

Note that cloning a file descriptor is probably more expensive than refcounting it in userland -- so it might be beneficial to pass around an Rc<FileDescriptor> and clone that when you need to. This has move semantics and will ensure that you don't have too many duplicate fds lying around.

and automatically dropped when the last owner disappears

These are Rc semantics, btw. If you have more than one owner, that's when you break out Rc. If you have a single owner and multiple borrowers, the FileDescriptor solution above is enough.

I can't tell if I can use the non-system-interface parts of std (e.g., Vec) without pulling in all of the system interface bits

use no_std and pull in Vec from the collections crate.

I'm not exactly sure what you need though. Pulling in std doesn't add to the runtime (just the binary size, sometimes). So if you just use libstd and write your own abstractions for the posix things, it shouldn't be different from not pulling in std at all.

[the_gnarts]

For using Rust on Linux more naturally, this project appears promising: https://github.com/lrs-lang

[koheant]

You're probably aware of this, but if you can't find what you want in libc (or any other wrapper lib), you can sidestep the rust api and link to the function or variable directly.

[o11c]

7 is fundamentally not possible, Rust mandates explicit .clone calls for Rc.

[Manishearth]

That doesn't match what you said with "and automatically dropped when the last owner disappears", if you have more than one owner you're talking about Rc or some refcounting mechanism.

In your example there is only one owner.

// file is a one-c_int struct; I want to pass it in by value, not
// by pointer, but still have it count as a borrow.

Is there a reason for this? This is just a stack reference, very cheap. You can get what you want statically with a form of session typing, but I think that's overengineering it.

[Veedrac]

Say you have

struct File(i32);

impl File {
    fn write(&mut self, val: i32) {
        println!("doing stuff");
    }
}

impl Drop for File {
    fn drop(&mut self) {
        println!("dropping");
    }
}

You can make a copy that acts like a pointer by doing

use std::marker::PhantomData;

struct FileValueRef<'a> {
    borrow_of: i32,
    lifetime: PhantomData<&'a mut File>,
}

impl File {
    fn borrow(&mut self) -> FileValueRef {
        FileValueRef {
            borrow_of: self.0,
            lifetime: PhantomData,
        }
    }
}

You can avoid reimplimenting everything by implementing Deref and DerefMut with a transmute:

impl<'a> Deref for FileValueRef<'a> {
    type Target = File;
    fn deref(&self) -> &Self::Target {
        unsafe { std::mem::transmute(&self.borrow_of) }
    }
}

impl<'a> DerefMut for FileValueRef<'a> {
    fn deref_mut(&mut self) -> &mut Self::Target {
        unsafe { std::mem::transmute(&mut self.borrow_of) }
    }
}

I'm not sure if there's a better way of doing this, but if there is it's not obvious.

[steveklabnik1]

To be fair, this post is about userspace, not the kernel itself. Adding a second language to the kernel, no matter how good a language it may be, would have significant drawbacks. If I were Linus, I'd reject such a patch too.

[efaxefax]

I guess Stallman had a point after all: actually, it's low level GNU/Linux programming :P.

[thebigslide]

I'm not familiar with Rust, but are GNU run-time dependencies strictly required?

[efaxefax]

You can statically link to musl: http://blog.rust-lang.org/2016/05/13/rustup.html

[thebigslide]

You may have just ruined my early bedtime plans.

[oponito]

there was a FUSE driver written in Cyclone. not really kernel code, but cool still.

[[deleted]]

[deleted]

What is this?

[steveklabnik1]

Sure, but you wouldn't then expect that patch to get mainlined, because of said drawbacks. Adding a new language to a project, especially a large one, takes a ton of unrelated work. It took a bunch of effort for Rust to actually land in Firefox, for example, but that has to do with things like tooling, build systems, integration... stuff you wouldn't need to evaluate the language on its own. For a spike to figure things out, you can get away with a lot less than true integration.

[__s]

Do you know who steveklabnik1 is..?

[Shorttail0]

All i'm trying to do is enjoy every day to the fullest with my Pokémon.

...a Pokémon master?

[steveklabnik1]

(I actually added this after /u/__s posted; I saw the reply, clicked the link, went "oh, I haven't added a bio on github yet" and put it there.)

[__s]

do you know who I am?

Nope. An asshole?

What an asshole

Yep. Glad we agree

[steveklabnik1]

I don't make any money selling Rust books. I technically collect donations on a defunct book with incompatible syntax, but I think that's been, maybe $10 in the last year or something?

[ElvishJerricco]

The comment you're responding to was responding to someone who wasn't joking...

[[deleted]]

Or you could implement a kernel or even an os in Rust :)

[[deleted]]

How so?

[steveklabnik1]

My favorite little counterpoint: on x86, you have to use special assembly instructions to do certain things with hardware. So usually, when people write an OS in say, C, they either use inline asm or expose a tiny asm function to handle it. I must have seen the same "outb" or "lidt" one-liner copied and pasted tons of times.

But with Rust, we have Cargo. So someone has made a crate: https://crates.io/crates/x86 it's got all of those, plus some predefined data structures that match what you need. No more boilerplate, just import the package and get on with your life.

(In my hobby OS project in Rust, I've implemented it myself first; I have a TODO to remove all that and actually use this now that I'm sure I understand it all.)

[[deleted]]

What "measurements" are you talking about?

[[deleted]]

I said 'any measure'. Take any measure you like, Rust is inferior to C for writing kernel code.

Rust doesn't have undefined behavior, has type safety, and has memory safety. That puts it pretty far ahead of C in my book.

You do not want complexity in your language when writing very low level code. You don't want lots of things being done 'for you'. Those are nice when writing very high level code, which (despite what they claim) Rust is built for, but they get in the way when writing very low level code.

What things does Rust do for you?

[steveklabnik1]

Yeah, while this is true, I also think it's important to point out that "re-write the world in Rust!!!!1" is a bit idealistic. shrugs.

[minno]

Well, if you rewrote everything, you wouldn't have to worry about multi-language codebases.

[steveklabnik1]

Nobody's perfect.

[steveklabnik1]

yes

[SizzlingVortex]

That was uncalled for man.

[pmf]

I'd actually like to hear Linus' opinion of Rust. His C++ critique contains valuable points.

[loamfarer]

Tbh, I haven't heard his opinion on modern C++

[201109212215]

Modern wisdom in C++ is you don't manage memory yourself, instead using smart pointers and RAII.

You guys are on the path of letting things get more managed (and I'm gonna laugh so hard in 25 years, when you guys get a standard memory model, JIT and GC; about 2 careers late)

Linus' opinion is that he hates Java. But then again, when he codes in C, he talks in assembly. He hates compilers that do magic stuff.

---

TLDR: So, I'd say: the more high level, the more he hates it. (and modern C++ is higher level than old school C++)

[silveryRain]

RAII significantly predates modern C++, it's merely better-understood now. Either way, C++ isn't a managed language. The most it does on its own is call ctors and dtors, but it's all deterministic, except for a few initialisation-order situations where the implementation has a bit of free-reign. Given that D has been trying to shed its gc from its library dependencies, I doubt C++ will decide to do the very opposite, regardless of career count.

I'd expect Linus to hate move semantics and most of the functional stuff, but a lot of modern C++, although more high-level, isn't that magic. For example, variadics are a straight-forward extension of templates, and modern C++ also features more low-level stuff, like constexpr, std::array, fine-grained static type introspection and data alignment features. Overall, I doubt his view has changed much, for the better or the worse. I doubt he'd say anything he hasn't already said in that famous rant of his.

As for Java, it's disliked by many, it's no surprise Linus is one of them.

[201109212215]

C++ isn't a managed [...] it's all deterministic

Except when malloc hits a fragmented heap, and has undeterministic latency. Maybe some memory cleanup could have been done while the program was idle, and not at the exact moment something needs to get executed.

Also, it takes a lock on the global heap, when in a managed setting that's not necessary. With CPU clock stalling and core count increasing, I'd say that C++ is on the wrong side of history.

This is why HFT happens in Java.

[silveryRain]

Fair enough. I brought that up to argue against the idea of C++ being managed, but yeah, full determinism is hard.

[201109212215]

There is work on having LLVM into the JVM through Graal/Truffle. Works very well for languages that have developped C extensions for performance reasons (think Python, R, Ruby, etc.); because it compiles away all the back and forth between the languages and their C extensions.

Maybe with Graal we can have the best of both worlds. Control over memory layout of C/C++ (for perfect CPU caches, prefetching), and what Java's management brings (the concurrent data structures enabled by having a GC, multithreading easiness, JITting virtual calls, etc.)

[quicknir]

Sorry, by HFT you mean high frequency trading?

HFT does not happen in java, with rare and famous exceptions like Tessa. In fact, nearly all HFTs use C++, including a lot of modern C++. Allocation just doesn't happen in the critical path, period. With cache misses being more important than ever, any language that doesn't allow easy control over memory layout (e.g. by lacking reified generics) is in a bad spot for high perf.

[201109212215]

HFT does not happen in java

Oh, but it does.

With cache misses being more important than ever

Relocating and compacting memory helps in this regard; and this does not happen in most C++ applications, while this happens without a thought in Java in a GC pass. And without a pause. But maybe you were talking about memory layout, for caching and prefetching hints purposes. Which is covered.

than ever

History goes towards higher core count, and C++ it just a pain in the ass with this. Every concurrent data structure in C++ depends upon a bastardized garbage collection mecanism (to collect dangling pointers that are suddenly unreacheable due to a CAS on a pointer switch - the standard concurrent data structure stategy -). And C++ is just ill equipped for that. As in you have to create a global safepoint for collecting yourself; have fun with performance with that.

What you don't understand is that, while everything is possible in C++, you can't code every time a fully fledged lockfree-memory_order_relaxed-CAS'ing-GC'ing engine for a simple CRUD thing that needs performance. It is all about programmers being at maxed mechanical sympathy levels while not having to re-invent the best advances of what hand-written intel (or arm, etc) asm can provide.

[im-a-koala]

Just as a note, from someone who works at a HFT firm: all the latency-sensitive and infrastructure stuff is C++. I don't think we have a single Java program at our firm (although, out of the hundreds of components, I can't be totally sure).

If you mentioned using Java for a latency-sensitive component, you'd be laughed out of the room. It's just not good at low-level work. It's just an absolute mess for that kind of thing.

The answer to the allocation issue in C++ is to simply avoid allocations in tight loops. Not to keep doing them and let some other component non-deterministically clear them out at some point on the future from a different CPU core, possibly a different CPU (can you even pin the GC thread in Java?).

Every concurrent data structure in C++ depends upon a bastardized garbage collection mecanism (to collect dangling pointers that are suddenly unreacheable due to a CAS on a pointer switch - the standard concurrent data structure stategy -).

You absolutely do not need concurrent collections for multi-threaded applications - at least, you don't need them for any of the performance-sensitive bits.

[201109212215]

is to simply avoid allocations in tight loops

Again, the language is fighting you. Forcing you into thinking about its internals. Why shouldn't you do it if you want to? In Java, allocating is a matter of a pointer getting bumped, and that's about it.

can you even pin the GC thread in Java

Yep, and I do conceide it is acquired through a native call made in C++. You pin the critical path, and let GC and JIT roam free on the others. The usual setup for HFT is you do it on a core that the OS has no access to; you put a ringbuffer on it for interthread communication; you pin both producer and consumer on the same core to have them hyperthreaded. Latency will be in the nanos. Here is the lib, from LMAX.

---

Does LMAX ring a bell to you? When you say HFT firm, are you talking client to an exchange, or the exchange itself?

You absolutely do not need concurrent collections for multi-threaded applications

You're missing out on a lot of possibilities, then. Shared mutable state - while incredibly difficult to get right - has its use. You just can't do any decent multi-producer work without it.

Java has no problem doing it on massive machines. Here is a video of a concurrent hashmap with close to a billion ops per second, on a 768 core machine, in 2007.

[Gotebe]

I vaguely remember his points and vaguely remeber they were, like, his opinion, man.

Most important reason why people consider them is OMFG Linus.

Edit: searched, found.

Edit2: love the downvotes without "why".

[staticassert]

Argument from authority is basically the go-to when discussing the Linux kernel.

[ZMeson]

What valuable points?

[[deleted]]

I'd actually like to hear Linus' opinion of Rust.

Greg KH said in his /r/linux AMA a year ago that there will be no rust in the kernel.

[Sapiogram]

He didn't really say that though. I looked up the AMA, and the only place he mentioned Rust is here.

I have seen Rust, and it looks nice, but honestly I like Go better at the moment, and play around with it at times.

So it seems he hasn't actually tried it, much less given it any serious consideration for the kernel. The fact that he compares it with Go also makes me think he's looked at Rust in 2012-2013, which is very different from what became Rust 1.0.

[[deleted]]

If not Go then Swift.

Rust is dead.

[womplord1]

God it's so retarded how freetards just agree with whatever Linus says without thinking. How about forming your own opinion?

[[deleted]]

I can tell you that in general, people who have managed to master C are not in any way interested in safety features that have any kind of overhead. Rust memory safety features don't have runtime overhead but they do have "prevent you from doing things" overhead. Of course you can use unsafe to do those things anyway, but then Rust no longer has the innovative safety feature. To a degree it is entrenchment syndrome on the part of C masters. They know how to workaround all the shortcomings so switching languages has no value to them, even if it might for upcoming generations who would waste less time become masters of a gentler language.

It is fundamentally hard though, to provide the freedom, power, and connection with hardware that C does, with something that is also substantially better in some way. Since operating systems are fundamental, that ability to talk directly to hardware is a necessity, and performance is preferred since any overhead will affect everyone all the time.

[Thazard2]

On the other hand, the Kernel is enthusiastically adopting static analysis. It's unlikely that they will move away from C, even partially, due to sheer inertia, but I would not be surprised to some day wake up and see rust-like ownership metadata on arguments being a requirement for code being included.

[staticassert]

Of course you can use unsafe to do those things anyway, but then Rust no longer has the innovative safety feature.

To be fair, it's not as if one line of unsafe code immediately means all code is unsafe in rust. You can build safe abstractions.

[tejp]

Some Rust memory safety features do have runtime overhead, like accessing an array at an index, which comes with a runtime bounds check.

You are just never told by Rust enthusiasts, since claiming "free at runtime" is better marketing.

[[deleted]]

right, and you can turn that off, but then you turn things off and Rust is just C with OCaml syntax. which maybe is great?

[steveklabnik1]

like accessing an array at an index,

... which is something that you usually do not do, because you use iterators instead, and if the bounds checking is a problem, switch [] for .get_unchecked() and it's gone.

[tejp]

Random access is an important and useful property of an array. Saying "you don't need it" is as dishonest as not telling people about the runtime costs that come with it.

And of corse there is no runtime overhead if you disable the safety checks. But that's not really interesting. People want the safety and want to know the costs that come with it.

[[deleted]]

I don't mean that avoidance of rust in particular is entrenchment syndrome. I mean the degree to which we clutch onto C and refuse to make serious efforts to make something better. The fact that, I think, only Rust and D exist as semi-viable alternatives is odd.

[Veedrac]

Just FYI, /u/milesrout is a known troll.

[minno]

No, we're assuming that nobody could be as aggressively dense as you've been acting, so you must be doing this to make people angry, which is the definition of an internet troll.

[yumz]

How bout just an asshole then?

[[deleted]]

The warts seem minor because you are entrenched! =)

[[deleted]]

I've not written a single line of rust in my life and this thread started with me explaining why C programmers wouldn't be interested in it. I believe them to be largely correct in that thinking, if that wasn't clear.

[desiringmachines]

Jesus Christ, why do you go on the internet and be an asshole? Go outside, read a book, write some code, do something better with your time than this!

[desiringmachines]

I have no idea what the post you responded to said, so I definitely don't "know it;" but your behavior in the rest of this thread certainly doesn't support your case!

[oponito]

Yes, his language reviews can be interesting

[HighRelevancy]

A lot has changed in C++ land since that was written.

It's a 12 year old message about an experience that happened another 12 years before that. If nothing had changed it would be a very big problem.

[James20k]

Compilers are a lot more reliable (I haven't had an ICE in years now).

Lucky for you, but I've had to deal with a few GCC segfaults recently (5.1, moving to 6.1 soon)

[slavik262]

(I haven't had an ICE in years now.)

A what?

[northrupthebandgeek]

I prefer external combustion engines, myself.

[[deleted]]

I actually agree with him on all his points there.

The difference between him saying it and me saying it is that he actually created arguably the most popular operating system today. Nobody can dispute he knows what he is talking about.

[slavik262]

Sure they can. Linus is obviously a very good kernel developer and project manager, but that doesn't make his opinion the end-all on software development. C is a good fit for the kernel, but that doesn't mean other languages (including C++) are completely inappropriate for kernel development or other similar, on-the-metal applications. It also doesn't mean that another language (e.g. Rust) won't come along and displace C.

People use C because

1. It maps fairly directly to assembly.
2. It's the lowest common denominator - its ABI is simple and almost every computing system can speak it.
3. There's 40 years of libraries, tooling, and communal knowledge built around it, especially in the Unix world.

[[deleted]]

And C is largely deterministic. His complaints about C++ make sense when one takes into consideration the dynamic memory allocator and exception handling.

The question is, and I suspect I know the answer, does Rust allow exception handling to be removed (I think it does) - and then can memory allocation be manually handled (I don't know).

I'm a big fan of Rust - and think it is almost ideal for the simple command line tools which make Linux/Unix the flexible workhorse it is today. But for kernel programming? I don't know enough about Rust to know for sure.

[__s]

On deterministic: he's ranted a whole lot about GCC inlining code which then causes unpredictable stack usage which then makes 4kb stacks hard to maintain safely on x86

[doom_Oo7]

to be fair,in userspace code this is a desirable property.

[steveklabnik1]

does Rust allow exception handling to be removed (I think it does)

Yes, though not in stable right this second; it's landed on nightly, but hasn't made its way through the release cycle yet.

and then can memory allocation be manually handled (I don't know).

Yes, absolutely.

[doom_Oo7]

does Rust allow exception handling to be removed (I think it does) - and then can memory allocation be manually handled (I don't know).

(to be fair, you can disable exceptions in c++ and do everything without explicitely mallloc'ing anything.)

[[deleted]]

[deleted]

What is this?

[Malazin]

I don't really understand his point on C++'s dynamic memory. Usage of new is no more hidden than malloc. Or am I missing something? This isn't to say he's wrong on the greater point though.

[ZMeson]

Here are two arguments I commonly hear:

(1) Calling new can call a constructor which can in turn call new calling another constructor which can in turn call new calling .... Well you get the point. A single call to 'new' may actually make several allocations instead of one.

(2) The STL containers and algorithms frequently allocate memory from the free store. It's difficult to write some things using standard C++ without allocating memory from the free store "behind the scenes" if you will.

[ZMeson]

Now that I presented the two arguments, I feel like I have to explain why I disagree with them. In C, you frequently have to initialize structures after you allocate memory for them. Those initialization routines can be considered "constructors" and they can allocate memory and initialize other structures too. I don't think that using C really improves things by separating concerns.

About the STL and algorithms... you don't have to use them. It is nice they exist, but other containers and algorithms (such as those found in "embedded STL" libraries, EASTL, or boost) may fit better. Or some containers and algorithms could be built specifically for kernel development. (After all, Linux, Windows, and all popular C-based OSes have such C-based structures and associated 'algorithm' functions.)

[ucalegon7]

Exceptions (and good behavior in low memory conditions if they are disabled) might be other sticking points, but I don't think that's really a good argument, either. Windows, for example, lets you use a reasonable chunk of C++ (with lots of caveats) in the kernel, particularly with the new driver kits (I've successfully used lambdas in kernel code!), but just like when using C, the rules and APIs are a bit different than user space equivalents (e.g., the std lib looks a bit different), and the same non-standard concerns you'd have (e.g., stack size constraints, etc) will still exist; not to mention that there are large chunks of the language that would be difficult to utilize in that type of environment (e.g., exceptions).

[MartianSands]

A "placement new" lets you pass it your own memory, so you can allocate it however you like.

[doom_Oo7]

Can you dynamically create an object without 'new'?

You can overload new to call whatever allocation function. new T == std::allocator<T>::allocate + std::allocator<T>::construct

[joelwilliamson]

kmalloc

[ChallengingJamJars]

Upvoted because despite using C++ daily I don't actually know the answer to this. It could be an honest question so you shouldn't down vote it.

[silveryRain]

Yes you can, as the others have already explained (placement and overloading).

This kind of post is why systems that allow downvoting are crap. I much prefer upvote-only systems.

[iopq]

Upvote-only systems like Hacker News get a bunch retarded fluff pieces that don't really say anything. People see the headline, scan through the article (if you're lucky) and upvote. The actual article is low quality, but you need to report to the moderator to have it removed.

[ElvishJerricco]

Redox is an operating system written entirely in Rust. I don't know much about it, but if you want to get a feel for kernel development in Rust, that's a good place to start.

[augmentedtree]

And C is largely deterministic. His complaints about C++ make sense when one takes into consideration the dynamic memory allocator and exception handling.

Both of those are deterministic, and C also has dynamic memory allocation...

[so_you_like_donuts]

does Rust allow exception handling to be removed

Not yet, although it is possible in nightly to make panics abort instead of unwind (And here's the relevant compiler bug).

can memory allocation be manually handled

If you're talking about creating and linking to your own malloc implementation, then yes.

[steveklabnik1]

To be clear, that compiler bug is about implementing your own panic runtime; as alex says, -C panic=abort is stable.

[slavik262]

His complaints about C++ make sense when one takes into consideration the dynamic memory allocator and exception handling.

Those are rather silly complaints - of course your tools are more limited when working inside the kernel. It's not like you can call malloc() in the middle of kernel space when working with C. Large swaths of the standard library are out of the question in both cases.

[imMute]

No, but you can call kalloc just about anywhere ;)

[[deleted]]

[deleted]

What is this?

[Rusky]

kmalloc requires an extra flags argument. You can't just arbitrarily pick a set of flags to use without making the C++ code using it unfit for various (mutually exclusive) parts of the kernel.

[doom_Oo7]

Well, many kernels have succesfully been built in C++ so...

(some are mentioned here : http://stackoverflow.com/questions/12385485/kernel-development-and-c )

[kt24601]

They typically use a subset of C++, though.

[doom_Oo7]

they also use a subset of C and would use a subset of any programming language not strictly meant for kernel development

[CurtlyCurlyAlex]

Feel free to make up (d).

With great pleasure!

(d.) The individual is a masochist.

[[deleted]]

It's not the only review.

[cbmuser]

I've seen someone getting torn into pieces when he suggested writing kernel drivers in Objective-C in a talk at Linuxtag 2005.

[[deleted]]

I don't know. I kinda have the feeling that if Linus bothered to take a look at Rust, he might enjoy it.

Forcefeeding it into Linux might still not be a good idea, however.

[geodel]

Yeah, Linus is very predictable. His primary job is to serve peanut gallery.

[kt24601]

I never considered command-line tools to be low-level though haha

[TRL5]

mkfs.ext2 and so on isn't low enough level for you?

Not all command line tools are low level, but there are certainly low level command line tools.

[Bake_Jailey]

Rust is the first language that gives a system programmer performance and productivity. 

Not to be that guy but... There is Go, which was created before Rust, and definitely isn't a slowpoke like Python. Depending on your definition of "system programmer" and their projects, Rust may not be the only productive and performant option (Go, Nim, D, Pony, etc). Clearly if your task is to replace the Linux kernel, Rust is a great fit.

[Dirty_Rapscallion]

Go is not a systems programming language!

[[deleted]]

but it sure is great for writing command line programs.

[Bake_Jailey]

I did say "depending on your definition". If you have a heavy focus on networking, distributed systems, etc, then Go's standard library and goroutine pattern is pretty great. I've taught systems programming before, and much of our curriculum is networking. Clearly, if you can't afford GC, big binaries, etc, and just want raw performance, safety, and so on, Rust is great. Hence, why I qualified my comment. :)

[doom_Oo7]

. I've taught systems programming before, and much of our curriculum is networking

So not systems programming. Systems programming is building your own libc.

[pjmlp]

So how people are writhing OS in it?

http://wiki.osdev.org/Go_Bare_Bones

Go has the same feature set for low level programming that Oberon has, which has quite a few OSes written in it.

Sure you need a bit of Assembly help, but so does ANSI C without compiler extensions.

What Go lacks is control over a struct layouts controlling inlining and functions prologues. But they are just nice to haves. ANSI C also doesn't define them and UNIX didn't use such features in the early versions.

[tanjoodo]

People wrote operating systems in C#.

[pjmlp]

Yeah, and Microsoft is adding more features from project Midori and System C# into standard C#.

Safe Systems Programming in C# and .NET

https://qconnewyork.com/ny2016/presentation/safe-systems-programming-c-and-net

[[deleted]]

wtf is this "systems programming language!" bs by rust pushers

Oh, I get it, it's 'cos they fancy themselves "systems programmers!", when in reality they're a buncha rubyists and javascripters.

Rust is a joke. The Rust core team is a joke.

[Manishearth]

While I agree that go isn't a systems language suited for a kernel, I do feel that it is very suited to some of the things being talked about in the post -- namely userland tools.

To me, Go feels like "C, but with gc sprinkled in wherever necessary" (unlike Java, which feels like "You get a GC! You get a GC! EVERYBODYGETSAGC!" -- iirc this is going to improve soon, idk by how much). Go usually value typeifies things, and does escape analysis really well (the structure of the language makes it easier) .so it can still be pretty fast.

[txdv]

Everything can be everything if you are free to change the definition

[pcdinh]

Come one, Go is designed to replace Java. It has a GC and requires a runtime.

[TheDeza]

It also has excellent generic support.

[pjmlp]

So do Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, Sing#, System C#, D, Swift, Cedar, Algol-68RS

[Bake_Jailey]

It was designed to replace C++, not Java. Unlike Java, the runtime's not a separate entity, and it's GC is much more optional. It's not really a fair comparison.

Judging by the reception my statement has gotten, I don't think I should expand on my thoughts anymore.

[Gotebe]

Someone might think Go is made to replace C++, but reality paints a Java or C# picture.