Live data from Hacker News

Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

github.com

211–220 of 234 posts

Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

#211
post #210

Earlier quoted context omitted.

That's my personal opinion after I've learned it and read Klabnik's book. I'm aware that other people's mileage differs. I'm listing a few reasons below. - Overall too complex - Wrong philosophy: demanding the user to solve problems instead of solving problems for the user - Trying to provide infinite backwards compatibility with crates, which leads to hidden bitrot - Slow compilation times - Claims to be "safe" but…

> Overall too complex Completely subjective. I've learned all there is to learn about Rust's syntax and most of its standard libraries, I think, and it's really not all that, in my personal opinion. There are certainly much more complex languages out there, even dynamic languages. I'd argue Typescript is more complex than Rust as a language . > Wrong philosophy: demanding the user to solve problems instead of solving…

That's a lengthy and passionate reply. The phrases "in my opinion" and "other people's mileage may differ" should have given away that my take was mostly subjective opinion. Rust is definitely not a language for me and would be a bad choice for the projects I'm working on. I continue to think it's totally overengineered. But, as noted before, other people's mileage may differ.

As long as the Rust fans stick to their favorite language, everybody can be happy.

Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

#212
post #199

Earlier quoted context omitted.

How is it overengineered?

That's my personal opinion after I've learned it and read Klabnik's book. I'm aware that other people's mileage differs. I'm listing a few reasons below. - Overall too complex - Wrong philosophy: demanding the user to solve problems instead of solving problems for the user - Trying to provide infinite backwards compatibility with crates, which leads to hidden bitrot - Slow compilation times - Claims to be "safe" but…

> Claims to be "safe" but allows arbitrary unsafe code, and it's everywhere.

Sigh. This is not true. Not the first part, and especially not the last part. `Unsafe` doesn't allow arbitrary, unsafe code. It resets the compiler to a level where most manually managed languages are all the time. You still have to uphold all guarantees the compiler provides, just manually. That's why Miri exists.

Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

#213

Earlier quoted context omitted.

That's my personal opinion after I've learned it and read Klabnik's book. I'm aware that other people's mileage differs. I'm listing a few reasons below. - Overall too complex - Wrong philosophy: demanding the user to solve problems instead of solving problems for the user - Trying to provide infinite backwards compatibility with crates, which leads to hidden bitrot - Slow compilation times - Claims to be "safe" but…

> Claims to be "safe" but allows arbitrary unsafe code, and it's everywhere. Sigh. This is not true. Not the first part, and especially not the last part. `Unsafe` doesn't allow arbitrary, unsafe code. It resets the compiler to a level where most manually managed languages are all the time . You still have to uphold all guarantees the compiler provides, just manually. That's why Miri exists.

[deleted]

Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

#214

Earlier quoted context omitted.

That's my personal opinion after I've learned it and read Klabnik's book. I'm aware that other people's mileage differs. I'm listing a few reasons below. - Overall too complex - Wrong philosophy: demanding the user to solve problems instead of solving problems for the user - Trying to provide infinite backwards compatibility with crates, which leads to hidden bitrot - Slow compilation times - Claims to be "safe" but…

> Claims to be "safe" but allows arbitrary unsafe code, and it's everywhere. Sigh. This is not true. Not the first part, and especially not the last part. `Unsafe` doesn't allow arbitrary, unsafe code. It resets the compiler to a level where most manually managed languages are all the time . You still have to uphold all guarantees the compiler provides, just manually. That's why Miri exists.

Either it's safe or it's unsafe. If you use the keyword "unsafe" it should definitely not mean "safe" (and it doesn't, but you seem to suggest it).

Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

#215

Earlier quoted context omitted.

> Claims to be "safe" but allows arbitrary unsafe code, and it's everywhere. Sigh. This is not true. Not the first part, and especially not the last part. `Unsafe` doesn't allow arbitrary, unsafe code. It resets the compiler to a level where most manually managed languages are all the time . You still have to uphold all guarantees the compiler provides, just manually. That's why Miri exists.

Either it's safe or it's unsafe. If you use the keyword "unsafe" it should definitely not mean "safe" (and it doesn't, but you seem to suggest it).

I think you're intentionally misreading everything people are saying to you.

Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

#216

Earlier quoted context omitted.

> Claims to be "safe" but allows arbitrary unsafe code, and it's everywhere. Sigh. This is not true. Not the first part, and especially not the last part. `Unsafe` doesn't allow arbitrary, unsafe code. It resets the compiler to a level where most manually managed languages are all the time . You still have to uphold all guarantees the compiler provides, just manually. That's why Miri exists.

Either it's safe or it's unsafe. If you use the keyword "unsafe" it should definitely not mean "safe" (and it doesn't, but you seem to suggest it).

You're being obtuse. Terms have contexts. It is unsafe in the sense that C++ is unsafe, in that you may cause undefined behavior which can't be entirely checked by the compiler. You're back to what Valgrind/C++ -wall/UBSan provide.

"Unchecked" or "Unconfirmed" would've perhaps been better choices, but Rust considers all other manual memory and reference management unsafe, so the word stuck.

Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

#217

Earlier quoted context omitted.

Either it's safe or it's unsafe. If you use the keyword "unsafe" it should definitely not mean "safe" (and it doesn't, but you seem to suggest it).

You're being obtuse. Terms have contexts. It is unsafe in the sense that C++ is unsafe, in that you may cause undefined behavior which can't be entirely checked by the compiler. You're back to what Valgrind/C++ -wall/UBSan provide. "Unchecked" or "Unconfirmed" would've perhaps been better choices, but Rust considers all other manual memory and reference management unsafe, so the word stuck.

I'm not being obtuse at all, I'm using the term exactly in the same way as you use it. By the way, the fact that Rust allows unsafe code by itself is not a problem. Although there are fully memory safe languages, many good languages allow unsafe code. Ada also allows unsafe constructions via pragmas. The problem is that, much unlike Ada programmers, Rust programmers use unsafe code extensively. That's the whole point. It's everywhere.

Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

#218
post #215

Earlier quoted context omitted.

Either it's safe or it's unsafe. If you use the keyword "unsafe" it should definitely not mean "safe" (and it doesn't, but you seem to suggest it).

I think you're intentionally misreading everything people are saying to you.

It's really just you and another Rust fan, there's no need to further discuss this among the three of us. I think I've made it extensively clear - based on the above reasons - that I believe it's a horrible programming language and people using it now will regret it in 10 years or so.

Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

#219
post #215

Earlier quoted context omitted.

I think you're intentionally misreading everything people are saying to you.

It's really just you and another Rust fan, there's no need to further discuss this among the three of us. I think I've made it extensively clear - based on the above reasons - that I believe it's a horrible programming language and people using it now will regret it in 10 years or so.

You're welcome to read the rustnomicon to learn about the topic you're discussing. Having written C and C++ for almost 15 years and doing extensive embedded work with it, I'm very secure in my decision to use Rust. But I'm capable of doing research to learn about it and to be somewhat involved in the development, mostly as an observer, to see both the direction it's moving and the overall process and meticulousness with which it's developed, to make an informed decision.

It doesn't seem you're making an informed statement at all anywhere in this thread, choosing instead to be hung up on semantics rather than the facts plainly laid out for you.

If that makes me an "enthusiast" then so be it.

Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

#220

Earlier quoted context omitted.

You're being obtuse. Terms have contexts. It is unsafe in the sense that C++ is unsafe, in that you may cause undefined behavior which can't be entirely checked by the compiler. You're back to what Valgrind/C++ -wall/UBSan provide. "Unchecked" or "Unconfirmed" would've perhaps been better choices, but Rust considers all other manual memory and reference management unsafe, so the word stuck.

I'm not being obtuse at all, I'm using the term exactly in the same way as you use it. By the way, the fact that Rust allows unsafe code by itself is not a problem. Although there are fully memory safe languages, many good languages allow unsafe code. Ada also allows unsafe constructions via pragmas. The problem is that, much unlike Ada programmers, Rust programmers use unsafe code extensively. That's the whole point…

Alright, we’ve arrived at a point where I‘m going to ask you for a source. You‘re being willfully ignorant. I explained that „unsafe“ is not used in the Rust community like you think it is, and that the compiler provides verification of safe Rust types in unsafe blocks.

The only times I‘ve used unsafe code is for FFI and very rarely on bare metal machines.

A common Rust programmer will never use unsafe. They will use safe abstractions by the standard library. There is no need for direct use of unsafe in application code, and only very rarely in library code.

In fact, [1] reports that most unsafe calls in libraries are FFI calls into existing C/C++ code or system calls.

[1]: https://foundation.rust-lang.org/news/unsafe-rust-in-the-wil...

Post reply on HN