Making The Case For Using Rust At Low Levels On Linux Systems

[unixfan2001]

This is a terrific account of possible reasons for the, apparent, success of rust.
You mention the CoC (and if add its actual enforcement) but I think, in one case, at least, its attempt to fit everyone in a square slot (I realize civility shouldn't be viewed as such but it's an imperfect world) led to the loss of a really brilliant developer/contributor. For people like that, imho, you should provide an alternate* slot.

*obviously, even for them, there are limits, but rudeness should be tolerated to degree that the person contributes

Are you suggesting we grant safespaces to people opposed to safespaces?

[codensity]

In a sense, mutability is "native" also to functional programming languages because it is possible to implement a Turing machine in a functional programming language.

A problem to solve is how create a compiler that can recognize the presence of Turing machines in functional programs and thus can generate efficient assembly code for such cases.

Sure, the notion of what it means to be purely functional is widely debated (hence Conal's often cited description of C as purely functional). Sometimes mutability and pointers are valuable for expressing an algorithm in which case having something functionally equivalent is fine, however I more often find that it's valuable for making something efficient. In the latter case I want a pointer into ram. I agree that it would be nice if we didn't need ST in Haskell or if we could somehow make all operations on immutable arrays efficient on von neumann machines (perhaps something like a linearity analysis is a good start). If that were the case however, could we not argue that immutable data structures are an efficient computational model of all phenomena of the world [with respect to mutable data structures]?

[codensity]

C++ isn't good for anything. There's good reason why everyone is moving away from C++ and using other languages instead, and why both Google and Mozilla decided to attempt to ditch their usage of C++ for Go and Rust respectively. C++ really isn't good for software libraries either due to C++ not having a stable exportable interface. That's a good reason why everyone writes their software libraries in C, and why all languages implement a C ABI as the foreign interface of choice. Rust, likewise, has the ability to export Rust libraries with a C interface, and many languages are now starting to take advantage of that, including Python and Ruby.

I think this is too strongly worded. I really like Rust so far (I'm an avid fper) but faulting C++ for lack of library support on one hand and praising Rust's ffi on the other is inconsistent. Rust largely copied the C++ approach to exporting functions and data, after all neither have an abi (however unlike Rust, C++ has proposals).

My biggest current complaint with Rust is that library support (Rust to Rust) is currently bad and as far as I can tell, not considered a problem (see: https://github.com/rust-lang/rust/issues/16402 and "non-goals" https://internals.rust-lang.org/t/pe...-the-plan/2767). Fetching the world and statically linking everything is such a boring solution. Imagine if libc were written in a way that required the machine to be rebuilt on update.

Cargo is a particularly badly designed, hyper-coupled tool requiring a python script (that appears to reimplement much of cargo, https://github.com/dhuseby/cargo-bootstrap) to bootstrap. As a package manager myself I'm not quite sure how to cope with rust software---some suggestions strike me as crazy, e.g.

In Debian's packaging solution for Rust they are not planning on installing Rust libraries globally, only Rust applications, so will not hit this problem. They will be packaging Rust libraries as source to a custom system location. When their package Rust applications are built, they will redirect cargo to look in that location for the source code to their dependencies, which will then be built and statically linked to the application. But the libraries will never be installed anywhere that could cause such a conflict.

Not even the rust compiler itself can be built if it's already installed system-wide.

In any case, if you want to look deeper into issues around packaging, at least there's work being done to address some issues (though personally it doesn't satisfy me): https://internals.rust-lang.org/t/pe...-the-plan/2767

I understand that to get really high-performance specialization as seen in C++ header libraries you're effectively statically linking but I feel like the community at large gives much thought to libraries and abi (e.g. pimpl).

[codensity]

Immutable data structures are an efficient computational model of just a restricted subset of phenomena of the world.

I sympathize with folks' potential feelings of frustration over generally widespread misunderstanding of functional programming (primarily Haskell) and purity (though personally I find laziness to be more annoying). Still, I find the above tautological and perhaps a bit too reductionist---sure efficient solutions are efficient solution, but what is the class of problems efficiently solved with persistent data structures? Prior to Okasaki's aggregation/work I'm sure most of us thought far fewer problems could be efficiently tackled than exist.

That being said, I take the sentiment. Working with the prototypical non-inductive data structures like graphs and matrices is a huge pain without mutation.

[totoz]

Although I do agree about C++ being unreadable for no reason when templates are come in place, I'd say that «verbosity» have little to do with code readability. More over, C++ with templates is verbose, too verbose!

The most readable language from ones that I know, in my opinion, is Haskell (so called ML-syntax), and it by no means is verbose, the code is very short. I even have for a year in mind the idea of creating a parser for a text editor, which would translate on the fly parts of code in C or C++ or C# or whatever, into Haskell like syntax look — i.e. the real code remains unchanged, it's just the reader sees it like this (the idea though not even close to its realization for a number of different reasons).

I'm not saying anything against Ada though, as I don't know this language.

In case of Ada, it push the "readability" up to that by just reading the code out loud, even a non-Ada developer can understand the algorithm.

[Hi-Angel]

The verbosity of Ada is intentional: since the language aimed to be used for safety critical systems, code readability and clarity was very important, even for some newcomers or people not familiar with the language (but with some IT skills, though). When I see modern C++, it's just klingon for non C++ developers. Even for me, although I did program in C++ for years a decade ago.

About tools, there's an IDE (GNAT Programming Studio) and an Eclipse plugin that you can get for free (GPL). And of course, Emacs ;-)

Although I do agree about C++ being unreadable for no reason when templates are come in place, I'd say that «verbosity» have little to do with code readability. More over, C++ with templates is verbose, too verbose!

The most readable language from ones that I know, in my opinion, is Haskell (so called ML-syntax), and it by no means is verbose, the code is very short. I even have for a year in mind the idea of creating a parser for a text editor, which would translate on the fly parts of code in C or C++ or C# or whatever, into Haskell like syntax look — i.e. the real code remains unchanged, it's just the reader sees it like this (the idea though not even close to its realization for a number of different reasons).

I'm not saying anything against Ada though, as I don't know this language.

[mmstick]

I moved from Gtk3 to Qt5 after dealing with it for like 2 years and finding out it's crap and at the time poorly supported on windows (at the time). The shittiest part is that it's written in C which is too low level, Python is a hog because it's interpreted that's one of the reasons Canonical couldn't keep up its software center because Python like any interpreted language only scales so much. And the C++ bindings to Gtk3 are crappy because they're still a wrapper around C logic with some bit of OO design. Anyone who tells me C++ isn't good for graphical apps, or any iteration of this idea, is only telling me he's not worth my time.

C++ isn't good for anything. There's good reason why everyone is moving away from C++ and using other languages instead, and why both Google and Mozilla decided to attempt to ditch their usage of C++ for Go and Rust respectively. C++ really isn't good for software libraries either due to C++ not having a stable exportable interface. That's a good reason why everyone writes their software libraries in C, and why all languages implement a C ABI as the foreign interface of choice. Rust, likewise, has the ability to export Rust libraries with a C interface, and many languages are now starting to take advantage of that, including Python and Ruby.

[mmstick]

Also, I find it irritating that, during the GTK+ 3.x series, it's become more and more difficult to maintain the desktop experience I had under GTK+ 2.x without regressions and their excuse is "GTK+ 3.x is an unstable series". If it's an unstable series, attack, name, and shame any distro which ships GNOME 3 as if it's a stable desktop! GNOME isn't the only consumer of the GTK+ APIs!

Like the LXDE developers, I'm in the process of upgrading from GTK+ 2.x to Qt 5.x and the main thing limiting my adoption of Rust is that, as someone focused on UI/UX design, most of my creations are I/O-bound things which glue together non-QML (QML native widget support is too immature) UI elements in novels ways, so my creations will be 99% PyQt regardless of whether I use Rust and adding another language just complicates the build process.

(I really want to be able to write pure Rust apps because the type system would greatly simplify the task of bringing all of my projects, old and new, up to my new unit testing standards... especially given how defining a state machine within Rust's type system lets you get compile-time validation of proper use of a wire protocol or file format.)

There's nothing stopping you from learning how to use GTK-rs with Rust to create a modern GTK3 application with client-sided decorations. It has better documentation than any of the pre-existing officially supported languages, the bindings are automatically generated and the API takes full advantage of Rust and it's powerful type system. I had zero issues with learning how to develop GTK3 applications for the first time, using Rust.

[mmstick]

Just C++, really?.

Also, from my little experience in both GTK and Qt, the last is better to code. E.g. I remember, as part of a student thesis, I was trying to fix a problem in GTK GUI of Yi with cursor, which doesn't become «big black box» in «normal mode», like it is in vim. Long story short, it turned out GTK didn't have that capability. In GVIM it is done via custom widget, and someone told a story, that for alike needs they hacked the mode of cursor when you press «Insert» key.

I also met some other problems, which I badly remember, but what I do remember — I googled whether they could be easily done in Qt, and yes, they are! Plus — though it is subjective — to me Qt apps looks much prettier than GTK ones. So I consider Qt to be better than GTK.

The only thing I'm miss in Qt, is that GTK allows creating global keybindings for textboxes via .gtkrc, e.g. for movement like in Emacs.

Perhaps you should have looked at your list more closely. The bindings that are available are largely incomplete QML bindings for all of those languages, and only Python and C# have Qt bindings, which are more than likely also incomplete. Creating bindings from software written in C++ isn't feasible, and hence almost all software libraries are written exclusively in C. GTK has a major advantage of being written in C and thus it is easier to develop bindings for, and can you really beat the documentation that GTK has with Rust now? I have met zero problems with developing GTK3 applications using Rust and Glade. The GTK-rs team has managed to perform a stellar job at abstracting the GTK API in a Rusty manner. Developing modern GTK3 applications with client-sided decorations is super simple.

[Steffo]

Runtime checks can be disabled at compile time, and Ada does also a lot of static checks and analysis at compile time.

GC is optional for Ada, and the GNAT compiler (probably the most popular compiler, based on GCC) does not provide one, so we can almost consider there is no GC unless you target a specific compiler.

Ok, you can disable run time checks, but how do you check then for data races? As far as I know, rust is the only language which can prevent data races at compile time.

The same is true for segmentation faults and dangling pointers without a GC. You can't compile code with rust if there is a possibility for a dangling pointer or segmentation faults.