>Linux isn't some kind of golden rule for all OSes on the galaxy. Tomorrow it and those like it will be the norm. A couple of years ago it was the GM EV1: It used to be largely promise of a future to come with a loads of downsides, where today it's expensive to get started with, has a lot of incompatibilities, but it's superior to most alternatives. Rust today seems like a 2013 Tesla Model S.
But I realize that's on me, and appreciate the focus and purpose of the language. It feels very unintuitive and "write-only" from my 1000 foot, ignorant perspective. Rust is particularly susceptible to this effect as it has been racking up wins and growing in influence, making people feel insecure about their current skillset/knowledge (always a weird motivator for rhetoric in this industry). You mean something that is good to great but that "outsiders" or late adopters feel unexplainably threatened by and thus feel the need to attack it and its admirers? Where ironically the detractors are louder and more numerous than the advocates ever were? "Rust (the Rick & Morty of programming languages - not a compliment)" You aren't going to see C# or Go used in the Linux kernel. Garbage collection alone invalidates it in that regards (religious war: reference counting beats GC every time), in the same way that C# and Java aren't credible low level languages.
Yet I wouldn't consider it for "low-level" code. It is the ultimate duct-tape language, allowing one to build robust, performant systems using a massive library and fantastic C interop where necessary. I absolutely adore Go, finding it to be an imperfect language that nonetheless yields powerful, maintainable solutions. Rust (the Rick & Morty of programming languages - not a compliment) Go (surprisingly easy to control the GC and get it to do what you want) C/C++ (footguns galore, but lots of existing literature)
#Codevision discord code#
The 4 languages I would consider for low-level code these days are, in order: For general kernel code I wouldn't use it. On balance, having written a bunch of lower-level C# code, I'd still slightly prefer it to C++ for (e.g.) talking to the GPU driver, but there's no denying that that's a very low bar to clear. The projects that successfully use C# in low-level code pretty much all roll their own containers, stdlib and a module that implements black-magic stuff, usually called something like UnsafeUtil. You pretty much can't use the C# stdlib for any low-level code. This makes a lot of operations that are sublinear in C++ take linear time in C#.
Data structures carry generation numbers that increment on various operations and invalidate iterators. Once again, there are ways around this, but they involve pointers, which pull in a bunch of the "unsafe" language.ģ) The standard library makes a lot of choices that, in hindsight, are extremely unfortunate. This means that you can't directly operate on values in an array. There are reference types, but they are restricted so that, for example, the array subscription operator cannot return them. If you've ever written kernel code, you know that fixed-size data members are really common, so this is more annoying that you might think.Ģ) C# types are either always references (classes) or always values (everything else). There are ways around it, but they are all more unsafe, require code generation or hit the GC. Some common annoyances are:ġ) C# is unable to declare fixed-size arrays in structs.
You can really tell, though, that the language wasn't meant to be used this way. It's surprisingly flexible, and unsafe low-level code composes well with high-level code quite well. Unity has been using C# for low-level code for years, and they have even gone as far as compile C# code into shaders.
0 kommentar(er)
