Rust needs to run, and be easy to use, on every platform
internals.rust-lang.org
internals.rust-lang.org
Has anyone posted a flippant request on the kernel dev list to support kernel modules written in Rust?
Be sure to mention:
* how safe Rust is
* how unsafe C is
* reiterate that "this is the 21st century, people"
I would hope that nobody trolls the LKML like that. Not even Rust people think that the kernel should adopt Rust.
Which is not a very interesting or productive reasoning when discussing the actual merits and capabilities of a programming language.
I like Rust a lot actually, but kernel modules aren't a good use case for it.
Edit: the_grue actually has an interesting criticism of Rust, which is that a lot of existing systems problems-- problems that Rust would be well suited for--are already addressed with large C/C++ codebases. Since it's unlikely you're going to replace Linux, postgres, nginx, etc. it is interesting to ask what systems applications Rust can be used for now, without requiring people to rewrite their applications in Rust or allow Rust code to be mixed in with existing C/C++ code.
Nginx seems totally probable.
If we're talking about kernel modules in general, I'd have to disagree. I think it's a perfect language for kernel, as long it's all written in Rust. I only wanted to point out the practical impossibility of integration with existing infrastructure, such as Linux kernel, which is written entirely in C.
That said, the kernel has special requirements; I'd never advocate such a thing for Linux, specifically.
Cargo is an amazing build system. But the last time I used it (which was maybe a year ago), I was struck by how tough it would be to use it for compiling a Debian package. At the time, it seemed like a big roadblock against wider Rust adoption.
> Today, Fedora includes over 300 Rust crates in Rawhide, which at the time of this writing will become Fedora 28. Over 120 Rust crates are included in Fedora 27.
It looks like the Solaris port got a nudge from Oracle, so I'm guessing that the most likely path to AIX support is a similar nudge from IBM.
IBM just published this today: https://www.ibm.com/developerworks/opensource/library/os-dev...
No idea what that means in general, but it's gotta be good in some sense!
But you lose stdout, backtraces. lto doesn’t seem to be working. Which is okay except that there is no easy way to override/replace what’s missing without hacks.
So wasm is an ideal exotic enough target to test if rust is truly portable and if libstd design isn’t too coupled with Linux/Windows/macOS.
I agree with you 100%, by the way. That's why I think wasm is important for Rust, even disregarding feelings about it as a specific technology. It's like a very small embedded platform.
I kind of agree with the sibling that the naming is odd. Why not call them String and Slice or String and MutableString? Using different ‘spellings” of the same word seems like it only encourage some confusion.
Because one is a pretty bog-standard struct: https://doc.rust-lang.org/src/alloc/string.rs.html#294-296 while the other is a primitive type: https://doc.rust-lang.org/std/#primitives
Lowercase (i8, u64) or anonymity (`[]`, &, *) means you're dealing with something fundamental to the language. Not just with special compiler/language support (like Result) but way below that, something the language doesn't itself express but has intrinsic knowledge of.
The uppercase one is a standard library type, and so is uppercased like all library types.
There's a summary of the differences at [0].
[0]: http://www.ameyalokare.com/rust/2017/10/12/rust-str-vs-Strin...
2. string_view makes no sense when many str are not actually views into strings but either static data or "cast" bytes.
3. string_view makes no sense when str is the basic builtin type.
Renaming String to something like StrBuf might have made sense, but it's not like it would have been any clearer, people get confused by Path/PathBuf all the same if not more so.
Path/PathBuf have better names, but the distinction still isn't immediately obvious.
String/str is the cause of so much confusion.
This confusion is why we reorganized the book to talk about String and &str very early on, and use them to teach ownership and borrowing.
A string (general) is fundamentally a bunch of bytes in memory. In Rust, that's implemented as a contiguous buffer of UTF8 code units composing valid unicode data.
Now because Rust aims to be a systems-oriented language, these bytes must have one[0] thing which is fundamentally responsible for them, that's the owner. If the owner goes away, so do the bytes. "Owned" qualifies the owner of those bytes. In Rust, it's String: String maintains a "strong" reference to a bunch of bytes in memory which form a valid string, and if the String disappear so does the data associated with it (it's deallocated).
Borrowed by comparison is something which holds a "weak" reference to the same buffer, it knows they're there, but when the "borrowing" structure is destroyed nothing happens to the data it refers to, because it was just borrowing it. That's what `&str` is.
Note that `&str` can borrow from a String (that's a common case), but it can also borrow from static data in the binary (all string literals are in that case) or from just a random bytes buffer (using str::from_utf8[1]).
> Could you explain to a non-Rust user why this is a good thing?
It doesn't matter for high-level languages like Java or Python[2] but it matters a lot for lower-level languages like C, C++ or Rust, because the owner of a piece of data is whoever's supposed to deallocate it (and whoever's allowed to reallocate it to expand it). When there's no difference between owner and borrower (e.g. C's char * ) the complete onus of tracking who's responsible for what is on the developer and failure brings for them to do so generates memory unsafety (dangling pointers, double-free, use-after-free, …). And developers being humans, they mess up regularly.
Making a very clear distinction between owned and borrowed types firstly helps the developer: they know they must free through the owner but mustn't — and normally can't — free through the borrower, that's what C++ is adding; and secondly can — with some additional constraints on the developer — have the language manage all that on its own, the latter being what Rust does (C++ will do the freeing part but you can still have extant borrows and so it's not memory-safe, just significantly more helpful than C).
[0] unless you're in a case where it's unclear who should be responsible and you just go "everyone!" and use reference-counting to just punt
[1] https://doc.rust-lang.org/std/str/fn.from_utf8.html
[2] generally, it does matter in the problem of substrings and whether substrings copy or point to the base data, the former is more expensive (you allocate on each substring operation) but the latter can maintain gargantuan amount of data "live" and prevent their collection
Deciding betweene two distinct types &str and &string (not mut &string) for your function's interface is nonsense. It makes no sense to have to _decide_ between which two views of a string that you can read-but-not-manipulate you want to use, and it makes zero sense that they can't unify the types with some simple compiler magic. A constant reference to a string should automatically decompose into a view of that string and that should be that. [edit: as in that view shouldn't be a separate type]
Additionally, that dereferencing a string returns a pointer... that makes no sense. That's the kind of nonsense we ran away from in the C++ world.
strings are the reason I regret not adopting rust back when as a user of a pre-1.0 language I could have joined in efforts to lobby against this insanity.
---
As a sidenote, string_view is so late in coming to the c++ world that it's not even funny. Having a separate std::string with an "implementation-defined" in-memory representation in a world of c strings (char *) is inane beyond belief. (Yes, nulls in strings would still be a problem. But why do your strings have nulls in the first place? That data should probably be a vector of strings or a [vector|array] of uint8_t (even if just typedef'd to unsigned char) and C++ strings should have been mandated utf8, contiguous, and null-terminated. You should be able to compose a zero-copy, read-only, non-owned string from a character array and decompose automatically to it. And don't get me started on the fact that C++ doesn't have sprintf because of the obsession with sticking to the overly verbose and way too complicated streaming operators. Developers end up using c strings with sprintf to format text and then copy it back to a std::string just to work around that stupidity.
Most useful "String" methods are actually &str methods that you get access to through that deref trait.
Dereferencing a String doesn't return a raw pointer, I'm not sure where you got that idea.
Dereferencing a string does not return a raw pointer, that was exaggeration on my behalf. But a string is a container, so *string returns.... &str? But string.deref() returns str?
Don't get me wrong, I'm fully invested in the language [0], [1], [2], but it's got a lot of warts that could have been avoided by thinking bigger picture. So many APIs are restricted by thinking easy instead of big pre-1.0. Like str being hardcoded into APIs that should have been generic (FromStr vs From<&str>, .parse() vs .into()), shipping 1.0 without async/await, and the whole mess with strings.
0: https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is...
1: https://github.com/rust-lang/rfcs/issues?utf8=%E2%9C%93&q=is...
In the same way unique_ptr is a container.
> so string.deref() returns.... &str?
Yes? &str::deref() also returns &str, Vec::deref() returns &[], Box<T>::deref() returns &T.
That's literally how Deref is defined, Deref<Target=T>::deref() returns &T.
*String returns str.
> (FromStr vs From<&str>, .parse() vs .into())
These are not equivalent. From/Into are non-failing conversions, FromStr can fail.
What you're looking for is TryFrom/TryInto which are still not done 2 years into the RFC: https://github.com/sfackler/rfcs/blob/try-from/text/0000-try...
Typed that out too fast, yes, that's my problem. * String is one thing but String.deref() is another. But * is the dereference operator. Operator overloading ftw ;)
> What you're looking for is TryFrom/TryInto which are still not done 2 years into the RFC: https://github.com/sfackler/rfcs/blob/try-from/text/0000-try....
Sorry, yes, I actually opened an issue with my suggestions regarding that one with particular focus on the fallible vs infallible nature: https://github.com/rust-lang/rfcs/issues/2143
They're the same thing, Deref::deref() is just the operation which underlies the dereferencing operator.
Either way I don't see what's problematic about a string buffer deref'ing to a string.
Which ones are those? I can't think of any off the top of my head, though brains are fallible!
The closest you could get is automatically allocating &strs into Strings, but then you're introducing silent allocation, which has a host of its own problems.
> A constant reference to a string should automatically decompose into a view of that string and that should be that.
This is exactly what happens, through Deref coercions.
I absolutely don't think &str should silently allocate for converting to String. But I think &str should zero-allocation convert to &string (and bypass dealloc, too).
That would introduce special cases into the type system, adding complexity. String is a library type, so you can take a reference to it like any other type. We'd have to move String into the language for that to happen, and currently, the language itself knows nothing about allocation, so then we'd have to put allocation into the language, which would then change our story on embedded significantly... and then it'd be one of the only types that you couldn't take a reference to for some reason, which would affect generic APIs, etc...
Vec's "special case" is [].
And it's not that String "has" a special case, it's that str is a special fundamental case of the language in the same way i8 or () is and String exists to make it easier to work with (otherwise you'd have to deal with Box<str> and efficiently working with that would require going back and forth to Vec, except you'd have removed Vec since it'd be a special case of [] and where do you store capacities at this point?)
> C++ needs string vs string_view because it has no borrow checker, but rust could (theoretically) implement this without the need for two different types.
C++ has char* which conceptually underlies both string and string_view. Rust shoves char* in the unsafe corner but need something to replace it, something which not only means "a bag of bytes" ([u8] does that just fine) but text as in "actual proper utf8-encoded unicode text". That's str.
> no other data type does?
You could argue that slices are a primitive type to arrays (also a primitive type) and vectors (a library type).
> Why does there need to be a distinct data type for a non-owned view into an object?
The difference between owned and non-owned types is fundamental; how would you propose distinguishing them if not as part of the type? Both concepts are part of the language, but like any language, you can use its fundamental bits to build better abstractions.
Things which are implemented for Strings are those which actually require it. String derefs to &str so you can call any &str method on String, any trait implemented by &str is basically implemented by String, and if you need to pass &str and have a String you just &v.
> Deciding between two distinct types &str and &string (not mut &string) for your function's interface is nonsense.
There are very very few reasons to ever ask for an &String but then what, should the language somehow forbid regular references to a perfectly standard type?
> It makes no sense to have to _decide_ between which two views of a string that you can read-but-not-manipulate you want to use
&String is not a view of anything, it's a regular reference to a string living somewhere in memory.
> A constant reference to a string should automatically decompose into a view of that string and that should be that.
It does that if a function asks for an &str and you &s where s:String. All Rust doesn't do is remove &String from the language, in the same way string is a valid C++ construct.
> Additionally, that dereferencing a string returns a pointer... that makes no sense.
Dereferencing a String doesn't return a pointer. String is* a pointer, so you can deref' it to get the str behind it (which is not a pointer, it's the actual unsized string data).
There's really no decision to be made.If you don't want to mutate the argument, use &str, you can still call the function with an &String. If you need mutation, take ownership with String or a mutable ref with &mut String.
> Additionally, that dereferencing a string returns a pointer...
You can't deref a String, you can only deref a reference (&String), not an object. &String derefs to &str. String.str_method() where str_method takes &str works because it'll auto-ref String -> &String, and then deref to &str.
IMO you're making a mountain out of a molehill, it makes a lot of sense once you use it for any time at all.
You can absolutely deref a String. Not necessarily usefully (or to the satisfaction of the compiler) as it yields an unsized `str` (exactly the same as deref'ing an &str) but you can certainly do it.
let a = "foo".to_owned();
let b = &*a;
Incidentally you can also deref' a Vec, that yields a slice (actual sequence, not the commonly seen &[])