
Rust needs to run, and be easy to use, on every platform - dsr12
https://internals.rust-lang.org/t/rust-needs-to-run-and-be-easy-to-use-on-every-platform/6935
======
the_grue
I'm a big fan of Rust, used it for several projects already, loved it. Too bad
much of the systems programming is currently tied to C/C++ infrastructure.
There is only so far you can get with FFI. Most likely not far enough to write
a Linux kernel driver and many other things, unfortunately. Here's hoping the
situation changes now that Rust is attracting so much attention.

~~~
ethelward
> Most likely not far enough to write a Linux kernel driver

Well...
[https://github.com/saschagrunert/kmod](https://github.com/saschagrunert/kmod)

~~~
the_grue
Heh, but it doesn't do anything, does it? Because to do anything, it needs to
interoperate with native datastructures and functions. There you go...

------
leshow
If not for Rust, I never would have believed systems programming would be
accessible to me, at least not in any time frame I was comfortable investing.

------
nrclark
For the Rustaceans out there, are there any plans to start getting Rust
libraries packaged for Linux distros?

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.

~~~
steveklabnik
We've long worked with distros, each of them has different policies, and so
does things differently. For example,
[https://crates.io/crates/debcargo](https://crates.io/crates/debcargo) is a
tool created by Debian for this purpose. [https://pagure.io/fedora-
rust/rust2rpm](https://pagure.io/fedora-rust/rust2rpm) is Fedora's.

------
SloopJon
The last time I looked at Rust platforms, I was kind of surprised that AIX
wasn't on the list at all.

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.

~~~
steveklabnik
Does LLVM have an AIX backend? That'd be the major blocker.

IBM just published this today:
[https://www.ibm.com/developerworks/opensource/library/os-
dev...](https://www.ibm.com/developerworks/opensource/library/os-developers-
know-rust/index.html?ca=drs-)

No idea what that means in general, but it's gotta be good in some sense!

------
iTokio
I thought that without runtime rust would be easy to compile to bare
webassembly (no emscripten).

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.

~~~
steveklabnik
Wasm is an intense focus of this year. There's a _ton_ of activity going on.
We'll get there!

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.

------
dsincl12
... and strings need to be unified and fixed fast. Anything involving string
manipulation is pure pain and is wasting a ton of time at the moment.

~~~
weirdwitch
No thanks. Rust made the right call by distinguishing between owned (String)
and borrowed (str) strings. Even C++ is moving in that direction now, by
finally adding string_views
([https://en.cppreference.com/w/cpp/string/basic_string_view](https://en.cppreference.com/w/cpp/string/basic_string_view))

~~~
ComputerGuru
That's not the problem. There absolutely should be two different types (and I
don't even care that the names are so poor). But half the rust APIs take one
type and the other take another (even when the string isn't manipulated or
stored in any way, shape, or form). Some interfaces are only implemented for
string and others only for &str.

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.

~~~
weirdwitch
Anything implemented for &str is automatically implemented for String, because
String implements Deref<Target=str>.

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.

~~~
ComputerGuru
Yes, anything implemented for &str is automatically implemented for String...
except some API are stupidly implemented for &string instead. And you can't
pattern match strings properly (think some `for in`) without first explicitly
converting to &str.

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...](https://github.com/rust-
lang/rust/issues?utf8=%E2%9C%93&q=is%3Aissue+author%3Amqudsi)

1: [https://github.com/rust-
lang/rfcs/issues?utf8=%E2%9C%93&q=is...](https://github.com/rust-
lang/rfcs/issues?utf8=%E2%9C%93&q=is%3Aopen+author%3Amqudsi+)

2: [https://crates.io/search?q=neosmart](https://crates.io/search?q=neosmart)

~~~
masklinn
> But a string is a container

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...](https://github.com/sfackler/rfcs/blob/try-
from/text/0000-try-from.md)

~~~
ComputerGuru
> * String returns str.

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...](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](https://github.com/rust-
lang/rfcs/issues/2143)

~~~
masklinn
> Typed that out too fast, yes, that's my problem. * String is one thing but
> String.deref() is another. But * is the dereference operator.

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.

