Rust Core Team + Mozilla To Create A Rust Foundation

[emblemparade]

I find "low-level" and "high-level" to be confusing terms.

It understand "level" as referring not to the language's grammatical features, but rather to the runtime environment which it targets. So you can have a "high-level" language with fewer features than others (like Go) and a "low-level" language many more features than others (like Rust).

What primarily makes Rust "low-level" is that it does not use a garbage collector. This allows for "low-level" compatibility with the explicit memory allocation we find in most operating systems (malloc/free) in both kernel- and user-space. This makes Rust suitable, for example, for kernel and embedded development, in a way that Python and Java are not.

By the way, C++ is a tricky one to fit in this classification because it can do "low-level" due to its C roots though actually a lot of modern C++ is quite "high-level". C++ is a jack of all trades, for better or for worse.

Another by the way: "suitable" does not mean "perfect" or even "good". At least in systems programming C-style ABIs are standard, so you need to do some "wrapping" to call back and forth between C and Rust. C++ can be tricky in this respect, too.

[zoomblab]

So one organization that failed to sustain itself creates another organization in which they plan unload its burden. What confidence that creates for the new organization?

[bachchain]

What primarily makes Rust "low-level" is that it does not use a garbage collector. This allows for "low-level" compatibility with the explicit memory allocation we find in most operating systems (malloc/free) in both kernel- and user-space.

It's less about garbage collection and more about control over how data is represented and handled. In high level languages like Python or JavaScript, you basically have two number types: int and float. Their underlying representation and management is considered outside of the programmer's concern. With Rust or C, however, the programmer controls how many bytes it takes up, whether it's stack or heap allocated, if it's signed or unsigned, if and how it can be converted to other types, and when it ultimately gets destroyed.

[emblemparade]

It's less about garbage collection and more about control over how data is represented and handled. In high level languages like Python or JavaScript, you basically have two number types: int and float. Their underlying representation and management is considered outside of the programmer's concern. With Rust or C, however, the programmer controls how many bytes it takes up, whether it's stack or heap allocated, if it's signed or unsigned, if and how it can be converted to other types, and when it ultimately gets destroyed.

I agree. Specifically, array management (and that includes strings) is a big part of it. For example, "high-level" languages might automatically reallocate strings and arrays when you concatenate them. This makes them easier to work with, but also very difficult to integrate with other systems.

By the way, Python 3 is interesting here because it also automatically changes the bit-width of int and float types when there is an overflow. Convenient! But definitely incompatible with "low-level".

Thanks for the elaboration!

[zoomblab]

Mozilla likely did the same mistake again.
https://www.joelonsoftware.com/2000/...ver-do-part-i/

The programming language was not their problem. Proof, chrome is written in the same language (C++) and has always outperformed firefox. Rewriting their engine from scratch and also inventing a new programming language and then maintaining all that entailed was an endeavor that nearly killed them. Maybe the history of Netscape will repeat itself.

the problem that Firefox has is that it has failed to create a bigger ecosystem than merely a browser that costs a lot but nobody pays for it. In that respect IMO they should study what is wrong with their product with respect to programmers and then users. Why everybody adopt the chrome engine (again plain good old C/C++) but not the firefox engine. And what produxt they should offer to end user that has potential to be monetized and bring income, so that they are not reliant on 'donations' from their corporate competitors (google).

BTW I never trusted Rust as a language with long term future because I am old enough to have seen so many such endeavors and their outcome.

[stormcrow]

I find "low-level" and "high-level" to be confusing terms. It looks to me that they have mostly been stripped of any meaning, or are just being far too vague to compare different languages.
C++ does have foreach, generics (templates are just that, and C++20 concepts are not unlike Rust traits), iterators, even coroutines by now in C++20.
Borrow checking enforces safety that is not just useful to have a memory-safe program without a GC but also to have a safe program. That would be a "high-level" language feature. But then you have unsafe, which would be "low-level".
Dunno, I may be missing something.
Maybe these words made more sense in a world where anything that wasn't close to assembly was being called high-level, C included.
I mean, even in C#, you can do reasonably "low-level" stuff (and some stuff like "struct" have no other reason to exist than performance).

"X level" has been watered down a lot over the years by (sometimes deliberate) misuse. "Level" in this case always, and should only, refer to how close to the hardware an abstraction appears to be. All programming languages are, to varying degree, "higher" than the machine code that runs on the CPU, including the various assembly languages. This is on purpose because no one wants to be directly manipulating bits ala DEBUG & switches back in the very early days. Beyond that, which languages are "higher level" than others is to some degree subjective and depends on the criteria behind which the levels are defined. Like in many things, context is essential.

This "high level" versus "low level" debate has been going on for decades now, and it's become a common insult from some language fanatics to hurl at their counterparts to the point where it's near meaningless in common use, I agree. But if you carefully define and parameterize your statements and terms, then they are useful indicators in discussion of abstraction layers.

[Michael_S]

I think in a better form of our industry than the real world will ever see, we would all be using C/C++/Rust and similar languages all of the time. I work exclusively in garbage collected languages at my day job, because for so much of the market productivity is more valuable than efficiency. But it's a damn shame that a computer from 15 years ago has more computing power than home computer users could dream of 30 years ago but is still a worthless doorstop today.

I'm not bashing Python/C#/Node/PHP/whatever - the company or even open source project that sets out to build their app in C++ or Rust is likely to get crushed by the one that whips something together in Ruby and gets it in front of users in half the time. And I definitely appreciate the convenience of not managing memory or endianness and so forth. I also appreciate that many computing tasks are infrequently executed and short-lived. Rewriting all of the shell scripts on this Linux installation in C would probably save an insignificant amount of computing resources, because I have 1400 shell scripts under / but none of them run for more than a few seconds at a time.

I'm just tired of throwing out or donating working machines because of software bloat, and even more than that frustrated that I have 6 cores, 12 threads, an SSD, and 16GB of RAM and still have to wait 5 seconds for the machine to boot or a browser to open, and even longer for most games to load.

[Michael_S]

Mozilla likely did the same mistake again.
https://www.joelonsoftware.com/2000/...ver-do-part-i/

The programming language was not their problem. Proof, chrome is written in the same language (C++) and has always outperformed firefox. Rewriting their engine from scratch and also inventing a new programming language and then maintaining all that entailed was an endeavor that nearly killed them. Maybe the history of Netscape will repeat itself.

the problem that Firefox has is that it has failed to create a bigger ecosystem than merely a browser that costs a lot but nobody pays for it. In that respect IMO they should study what is wrong with their product with respect to programmers and then users. Why everybody adopt the chrome engine (again plain good old C/C++) but not the firefox engine. And what produxt they should offer to end user that has potential to be monetized and bring income, so that they are not reliant on 'donations' from their corporate competitors (google).

BTW I never trusted Rust as a language with long term future because I am old enough to have seen so many such endeavors and their outcome.

You've got it wrong, Mozilla never rewrote Firefox. They have been refactoring C++ as they want along. At the same time they created Rust and in some Firefox components they started adopting it. https://4e6.github.io/firefox-lang-stats/ less than 10% of Firefox is in Rust - and those components that are in Rust have excellent performance and stability.

The reason Firefox couldn't compete with Chrome in speed is that Firefox was based on a fork of Mozilla Suite, which was itself a fork of Netscape Communicator from 1996. Refactoring many millions of lines of 20+ year old code is a lot harder than writing something new in 2007. Mozilla has narrowed the performance gap with Chrome tremendously in the past five years, which is especially impressive considering that Google has far more money to throw at Chrome development.

Consider that Microsoft tried refactoring their Trident engine in Internet Explorer to match Chrome and they never could. They gave up and now Edge is based on the same code as Chrome. And they had far more money to throw at the problem than Mozilla, and they didn't introduce a new programming language. But they had the same problem - until they switched to a Chrome base, Edge was based on C++ code that traced it back to Internet Explorer in the mid 1990s. That's much harder to maintain.

Maybe Chrome will start buckling under its own weight when its code is 25 years old too.

[jacob]

It's pretty similar to python though except for use and mod being two different things while in python it's just import. With Rust 2018 you also no longer need to specify "external crate" so you can literally just use "use" the same way as with pythons "import" for external crates/modules. Otherwise lib.rs is same as __init__.py and main.rs is __main__.py.

IMHO the module system is probably the weakest part of Rust at the moment. Not only is it confusing and needlessly complicated (with all the relative paths, super:: and self::, note that the "self" keyword thus has two totally different meanings in the Rust language, so does "mod"), it's also extremely primitive. Basically it provides namespacing and nothing more. I still dream of Rust one day getting at least generic modules like Ada, or even going the full length and implement functors like OCaml.

[jacob]

I find "low-level" and "high-level" to be confusing terms. It looks to me that they have mostly been stripped of any meaning, or are just being far too vague to compare different languages.
C++ does have foreach, generics (templates are just that, and C++20 concepts are not unlike Rust traits), iterators, even coroutines by now in C++20.
Borrow checking enforces safety that is not just useful to have a memory-safe program without a GC but also to have a safe program. That would be a "high-level" language feature. But then you have unsafe, which would be "low-level".
Dunno, I may be missing something.
Maybe these words made more sense in a world where anything that wasn't close to assembly was being called high-level, C included.
I mean, even in C#, you can do reasonably "low-level" stuff (and some stuff like "struct" have no other reason to exist than performance).

I really don't know why people always compare C++20 concepts to Rust's traits. To me they are different beasts entirely. Traits serve three primary purposes in Rust. Depending of the context, can they provide 1) type coercion and subtyping, 2) Java-style interfaces and 3) dynamic dispatch (e.g. virtual methods in C++). On the other hand, C++20 concepts look like a form of duck typing that exists at a metaprogramming level (because that's what templates are, they are not really part of the C++ type system). You can use them in places where in Rust you would use traits, but that doesn't make them equivalent. In fact Rust doesn't really have anything directly similar to the concepts, probably the closest thing you could get would need to be something bespoke based on declarative macros.

DISCLAIMER: I've only read about the C++20 concepts, never really used them.