XCP-ng Initating Effort To Rewrite Xen Components In Rust

[darkonix]

The term objectively is deeply rooted into metaphysics and only works if you can close a system.

I objectively define objectively as my objetive opinion. Naturally everyone else opinion is not objectively and need to acknowledge my objectively better judgement.

[ssokolow]

Yes but the examples are all systems with a large public interface or an OS. Not all of the programs have that. It got common with the advent of the web technologies. If you would not have this large public interface you would not get all the problems. Web technologies have efficiency problems too. As an user I avoid web apps like milk and I am lactose intolerant. ;-) They are slow, eat my battery and work very often not offline. Actually when I need them most. And they save the my data in cloud. That are problems no computer language can fix.

The problem is that more and more stuff that wasn't designed to have a web interface is being retrofitted to have it via things like WebUSB, WebGPU, etc. ...so it's becoming important that every library or platform API be designed with that potential future in mind. libstagefright (hardware-acceleratable audio/video) has historically been one of Android's most visible sources of vulnerabilities and it may predate the HTML5 audio and video tags. (It's been too long since I checked the timeline on that.)

[patrick1946]

Plus, you have to recognize that a non-trivial slice of the people "pushing for Rust" are more just seeing Rust as the last building block needed to allow people to still see them as credible when they push against C, C++, or other languages that make memory-unsafety so easy.

For Android, the argument is "Rust or Java. Rust just allows us to broaden the rule we were already applying to more low-level components". The Chromium team wrote Safer Usage of C++ and Borrowing Trouble: The Difficulties Of A C++ Borrow-Checker about how much work they went through to make use of C++ safer and why it's still not enough. For parsers, Google was already experimenting with a compile-to-C language named WUFFS which enables guarantees even stricter than Rust at the expense of not being general-purpose. The NSA didn't argue for Rust specifically, but for ditching C and C++ in favour of memory-safe languages in general. etc. etc. etc.

Yes but the examples are all systems with a large public interface or an OS. Not all of the programs have that. It got common with the advent of the web technologies. If you would not have this large public interface you would not get all the problems. Web technologies have efficiency problems too. As an user I avoid web apps like milk and I am lactose intolerant. ;-) They are slow, eat my battery and work very often not offline. Actually when I need them most. And they save the my data in cloud. That are problems no computer language can fix.

[ssokolow]

Plus, you have to recognize that a non-trivial slice of the people "pushing for Rust" are more just seeing Rust as the last building block needed to allow people to still see them as credible when they push against C, C++, or other languages that make memory-unsafety so easy.

For Android, the argument is "Rust or Java. Rust just allows us to broaden the rule we were already applying to more low-level components". The Chromium team wrote Safer Usage of C++ and Borrowing Trouble: The Difficulties Of A C++ Borrow-Checker about how much work they went through to make use of C++ safer and why it's still not enough. For parsers, Google was already experimenting with a compile-to-C language named WUFFS which enables guarantees even stricter than Rust at the expense of not being general-purpose. The NSA didn't argue for Rust specifically, but for ditching C and C++ in favour of memory-safe languages in general. etc. etc. etc.

[patrick1946]

People is too sensitive these days. We should evaluate the language objectively independently of it's promoters.

I still remember the days of the netiquette. It was so much more pleasant and productive.

The term objectively is deeply rooted into metaphysics and only works if you can close a system. Even in physics it is hard. But how is that possible with something like a computer language? Maybe you can evaluate it economical but even that is very hard because you have to collect so much data. Computer languages are so context dependent that you can argue endlessly. ;-)

[mdedetrich]

Smalltalk is great but it was not just a language. It uses a virtual machine that preserves the status of every object persistentenly. This is significantly different form other languages that you could compile or interpret. I believe this was probably a bigger barrier to adoption.

I would argue the biggest developer to smalltalk is that most of the good implementations of it was commercial. Getting a machine with a good implementation of smalltalk was quite expensive and this really hurt the adoption.

While the persistent VM that preserved your environment was unconventional, I don't think that was a dealbreaker in this regard.

[darkonix]

Do you experienced the rise of Java? Actually it really reminds me to Rust except Java was much more successful in the beginning. New concept always look very convincing but only after they are used widely broad experience gets gathered with them and new concepts grow out from them.

People have their context and it's all we have. If people argument from a different context it is easy to say that their context is an 'illusion' but my is 'fundamentally solid'. But you can never know because nobody can see the future except for a Messiah like figure. ;-)

I remember when I developed C applications with embedded SQL. Every vendor used a different propietary technology. With Infomix you could only build with a live connection to the server. I had to go the customer site to build. There was a preprocessor that generated unreadable c. And all the warts of C, like strings management, pointers, leaks, etc.

In comparison the same in Java was multiplatform, used a standard database driver in Java that was also portable. Easy string and memory management. It would have been just perfect for that use case.

[darkonix]

Smalltalk existed since the '70 but the syntax was really different.

Smalltalk is great but it was not just a language. It uses a virtual machine that preserves the status of every object persistentenly. This is significantly different form other languages that you could compile or interpret. I believe this was probably a bigger barrier to adoption.

I think the biggest drawback of Rust is some of their Evangelists overselling it aggressively. ;-)

People is too sensitive these days. We should evaluate the language objectively independently of it's promoters.

[mdedetrich]

Bear in mind three key details:

1. Java had massive promotional funding behind it from Sun Microsystems. Rust's rise has been more organic/viral.
2. Java was basically the first thing in its niche, and its growth was arrested partly by the rise of C#... which came about as Microsoft's "I'll build my own casino, with blackjack and hookers" after Sun sued them for trying to Embrace, Extend, Extinguish with Visual J++ and which also had massive promotional funding and platform tie-in behind it. Java also was hampered by Sun's over-dedication to "write once, run everywhere". (eg. The difficulty of integrating with POSIX APIs on POSIX's terms is which Richard Stallman never liked Java but did like Python. C# integrates with Windows APIs on Windows's terms and that's one big reason it's so popular.)
3. Rust is the first innovation in niches formerly unique to C and C++ to gain significant traction in decades. Assuming other factors don't halt its growth, it has the potential to be a huge success. (eg. D had potential, but the ecosystem split and the ""technically optional but, because so many third-party libraries rely on it, mandatory in practice" garbage collector killed its momentum.)

TL;DR: Sun pumped up Java with a massive promotional budget but then basically strangled it in the name of keeping it pure to their vision, so much of its momentum was transferred to C# as Microsoft's "Java by Microsoft®" after the Visual J++ lawsuit. If you count Java and C# as one phenomenon, it was hugely successful and cornered the "memory-safe application development" niche until node-webkit/Electron came around.

As a JVM/Java developer, I would add one thing that people commonly miss which I think is the biggest factor for Java's rise (especially in backend systems) and that is its memory model. Java's memory model in conjunction with GC allowed developers to write concurrent code that properly utilized many threads (not like Python with a GIL) and due to its GC is also largely safe (unlike C/C++). This was massive at the time Java was getting popular, because it was also at the same time you had many core server systems popping up and unlike nowadays where we have multi tenancy systems, back then hosting on premise (or in a data center) was the norm so you would have an entire multi-core server system for "yourself" (which means unless you feel like throwing performance off the table, you need to use all of those cores). Ontop of this most systems were monolithic/single process in design (idea being you had a single JVM VM per node that would take up almost all of the resources).

Combine that with a fairly easy to learn language and bobs your uncle.

[ssokolow]

I think the biggest drawback of Rust is some of their Evangelists overselling it aggressively. ;-)

I don't like the RIIR crowd either. I was among the /r/rust/ old-guard who were busy running damage control at the height of that.

When I say "Rust is the first innovation in niches formerly unique to C and C++ to gain significant traction in decades.", I'm referring to things like how Microsoft is apparently using it internally but won't say where, Google is praising the results of migrating parts of Android from C and C++ to Rust and preparing to use it in Chromium, and it's the first non-C, non-Assembly language where support is tentatively getting added to the Linux kernel.

The more "like Java was"-y stuff would be how Espressif has hired the guy who DIYed ESP32 Rust support on top of their Xtensa fork of LLVM (upstreaming in progress) so he can have a full-time job providing official Rust support for both Xtensa-based and RISC-V-based ESP32 models and how Infineon recently announced official Rust support for some of their lines of automotive-oriented microcontrollers.