Rust-Written Redox OS 0.8 Released With i686 Support, Audio & Multi-Display Working

[mmstick]

Oh, and I have the final question: Is there an IDE for Rust that features code completion? Not the idiotic "wild guess" kind, but the full-analysis kind, where I can pick an identifier name from a tree of pop-up boxes. Also, debugging with a call stack window, variables window and pretty-printing are important to me. Preferably, it should be free and open-source.

Today, the standardized method of code completion in Rust is through Rust Analyzer, which is an official project maintained by the rust-lang team. It is an implementation of the Language Server Protocol. Any editor that supports LSP has a Rust plugin, and VS Code is probably the best example of that. The LSP can show inline type hints, highlight the precise characters and lines that are emitting warnings and errors, give code suggestions, documentation tooltips, goto, and it does give the drop down box of options as you type, and when you press the Ctrl + . shortcut.

IntelliJ decided to implement their own Rust plugin from scratch rather than relying on official LSP implementation.

[mmstick]

Both polymorphic caches ad vtables are "dynamic dispatch", so which one?
Polymorphic caches = Haskell ; vtables = C++.

Dynamic dispatch is most commonly achieved with an enum, which some academics call ADTs (algebraic data types). They're deconstructed with pattern matching and many people familiar with Haskell will feel right at home using these. No vtable or runtime type annotations needed.

It's rare to see it, but passing values as a `dyn Trait` — also known as a dynamic trait object, and usually constructed as `Box<dyn Trait>` — will have the compiler generate a vtable alongside the data that enables the functionality of the given trait. A value being passed in this manner could theoretically have multiple vtables if it's being passed into interfaces with different `dyn Trait` types, with one vtable per trait.

In most cases, static dispatch is the most common form that generics takes. No vtables are needed with that. Dynamic dispatch with trait objects is typically used to avoid static dispatch with functions, and to avoid polluting the type signature of a type containing a generic field.

[mmstick]

Ok, now I have a question (in order to avoid reading a big pile of documentation, lazy me).

It'd honestly be easier and quicker to skim through the Rust Book to find what you want to know, or asking questions on the Rust subreddit or Rust User's Forum.

- still the question remains: polymorphic caches or vtables? If there are polymorphic caches, can it do multiple dispatch?

Compile-time polymorphism when generic types are used, and dynamic dispatch when trait objects are used.

Why are types in a generic function erased? Is this something on a to-do list, or some strange kind of a design decision? I would certainly prefer that no type erasures are part of the language.

I think you need to first define what your definition of type erasure is, because the behavior of Rust is the same as other compiled languages. Except for trait objects, generics are used for compile-time code generation. Any time you call a generic function, the compiler automatically generates a unique function or type based on the types you supplied to it. Type metadata generally isn't needed by a compiled application. If you never write code that requires runtime type checking, then there's zero point in requiring type metadata to be attached to every value.

It's possible to create a variable that can be any type with runtime type-checking by passing it as a `&dyn Any` or `Box<dyn Any>`, but that's something that's very rarely if ever used by anyone in the real world outside of playground demos. It's more typical to see variables passed around as trait objects (`&dyn MyTrait`, `Box<dyn MyTrait>`), where the types are restricted to types implementing the given trait. Some people do like to do runtime type checking for errors though, since the error trait can retrieve the cause of an error as a `&dyn std::error::Error`, which you can upcast to a specific type implementing that implemented trait.

It got them faster than I thought possible.

These features were all implemented before Rust 1.0 released about 7 years ago. In recent times, async capabilities were implemented and Rust is now focused on improving the async story. It also just gained GATs (generic-associated types), which brings it closer to HKTs and enables even more advanced and ergonomic forms of async.

One such demanded feature is async methods in traits, which in practice can be achieved with a non-async method returning a `Box<dyn Future>`, but to be truly zero-cost it needed support for GATs and specializations. With GATs down, work on specialization can proceed to enable native syntax for async methods to work with zero cost.

[darkonix]

- "requiring type constraints on generics" - now I'm getting a bit suspicious. I don't want "generics" implemented with "type deletions", as in Java, I want generics to be like templates (i.e. automatically multiplicated code, depending on types). On the other hand, "type deletion" in Java is kind-of acceptable to me, so perhaps I could also accept it in Rust

This blog compares in detail Java and Rust generics: https://fasterthanli.me/articles/rust-vs-java-generics

It seems to answer your questions.

[ssokolow]

Ok, now I have a question (in order to avoid reading a big pile of documentation, lazy me).

I need (at the minimum):
- friend classes and friend functions
- multiple inheritance
- "shared" multiple inheritance (virtual base classes)
- at least, all the features of generic programming (templates)
- constexpr
- lambdas
- generic lambdas
- concepts (type constraints on templates)
- something resembling the Boost library

What's the current status of Rust on each one of those features?

• All things within the same module (i.e. namespace) are effectively friends. A module can either be a file or a mod MODNAME { ... } block inside a file.
• Rust isn't a traditional OOP language and instead follows a design more along the lines of Haskell's typeclasses. Rust's trait system allows multiple inheritance and you can write default implementations of functions in a trait (like an abstract class), but Rust only does interface inheritance (eg. anything that implements Error must also implement Display). If you want implementation inheritance, you need to use a third-party crate like delegate. Traits are different enough from classical inheritance that it's better to just read up on them rather than trying to explain things point-form. On the plus side, you can impl your own traits on other people's types, which is how the Serde crate retrofits serialization and deserialization onto standard library types. Also, you can #[derive(...)] for various traits when there's a simple, obvious way to implement a trait based on the implementations of that same trait for the data type's members. (eg. #[derive(Debug)] will generate a debug formatter for a struct or enum which delegates to the Debug implementations of the fields and requires them to be present.)
• Rust has type-constrained generics and hygienic, AST-based macros for generic programming.
• Rust's approach to constexpr is that you can write const fn instead of fn when declaring functions if you only call functions or methods which are also const fn. Then, once you've explicitly promised that as part of your API using const fn, the function is eligible to be called in constant initializers. Every new release of Rust includes the announcement of a few more standard library functions/methods being made const.
• Rust does have lambdas. They're relied on heavily in things like the iterator API.
• Rust's lambdas are type-inferred (auto) by default but I've never needed to look into whether you can use generics when explicitly specifying type signatures.
• Rust requires type constraints on its generics. The caller chooses whether to monomorphize or use dynamic dispatch. (And you never have to worry about whether a struct is POD because the vtable is handled by using a (data, vtable) fat pointer, not by stuffing it into the struct instance.) If you want to use duck-typing, you have to use Rust's AST-based macro system or implement something yourself using the Any trait, which enables runtime-checked downcasting.
• The Rust ecosystem generally doesn't like big, monolithic libraries and attempts to create such "extended standard library" compilations have withered due to lack of interest, given the quality of the dependency management, including things like the cargo vendor command. However, the contents of Boost do exist. Here's a post I made nine months ago in response to someone else asking about a Boost equivalent. See also https://blessed.rs/

[Waethorn]

Learn what euphemism means. People say I2C when they actually mean SMBus. There aren't a lot of other I2C-style busses in an x86 computer. This isn't an ARM SoC.

Nobody actually follows the standards microsoft sets out. No modern computer is modern, everybody cheats on compliance.

Everything you just stated is just completely unfactual.

[mmstick]

Truthfully, every algorithm and real world project with complexity is going to much more difficult to implement in C++ than Rust. There's a reason why Rust has been ranked as the most loved programming language by Stack Overflow for seven years in a row, and why people constantly rant about how productive they are with it. The mythical 10X programmer is just a normal programmer writing software in Rust.

[ssokolow]

That's interesting. I'll certainly look into that problem a bit.

Most of my projects are single-threaded, or they have some minimal amount of multi-threading, so I wasn't thinking about that kind of a problem before.

In fact, "Quantum CSS" (Firefox's current CSS engine) is the Rust-written CSS code from Servo. As for "they had massive trouble implementing it performant and threadsafe in C++"...

By 2017, Mozilla had made two previous attempts to parallelize the style system using C++. Both had failed.

-- Implications of Rewriting a Browser Component in Rust

TL;DR: It's about how rewriting something in Rust doesn't obviate the need to watch out for reintroducing logic bugs when doing a rewrite.

[Anux]

To get back to your question "what if a language enables you to use better algorithms that would have been to toublesome in other languages", I don't quite get what kind of algorithm would be "troublesome" to implement in C++?

Look at Mozillas servo project, they had massive trouble implementing it performant and threadsafe in C++. That's one of the reasons they supported/used rust, becuse thread safety is really hard in C++ but you get it for free in rust.

[Developer12]

Except for every name brand PC OEM shipping right now that doesn't exclusively bundle Linux, meaning about 95% of PC's on the market, with Mac's making up the majority of the rest. PS/2 and ISA are not used in these. And I2C still isn't the same as SMBus. Read the docs on the links. Even going back as 2004, they show the differences between I2C bus and SMBus. They aren't the same technology - never were. It's like claiming USB "is the same as a Parallel Port". They're not. Stop pretending that they are, or that Windows logo certification isn't a major contributing factor to the way PC's are designed, to make an argument. You're just making yourself look silly.

Learn what euphemism means. People say I2C when they actually mean SMBus. There aren't a lot of other I2C-style busses in an x86 computer. This isn't an ARM SoC.

Nobody actually follows the standards microsoft sets out. No modern computer is modern, everybody cheats on compliance.