gary17the

> I love the idea of Rust, but the language itself seems needlessly complex

Well, I have to agree Rust isn't one of the simplest PL-s on the planet. This is due to the fact that it is quite a modern PL and quite a versatile PL, supporting elements of functional programming, trait-oriented (conditional generics) programming, asynchronous programming, etc. and a capable standard library on top of it all. It takes, indeed, quite some time to take all of that Rust in. As a reward, you get a lot of expressiveness and the capability to discover a significant percentage (if not an overwhelming majority) of your programming mistakes at compile time as opposed to runtime (unit/integration tests or Q/A), which to me is priceless.

Nevertheless, from my experience, Rust is, at the same time, one of the most... "consistent", "predictable", "internally symmetric" PL-s I have ever seen. I consider Rust to be way easier to learn than, say, Swift.

> `let` patterns can be used as conditions in `if`

I somewhat cannot help it but feel that such an example should not be used in an introductory tutorial. `if let` is usually used to pattern-match a simple `enum`[1], not a complex `struct` that looks "dense" unless you're used to it.

[1] https://doc.rust-lang.org/book/ch06-03-if-let.html

Reference-counted[1], just like, say, Swift.

[1] https://en.wikipedia.org/wiki/Reference_counting

> what most people would like is rust minus borrowing

It's already possible. Use Rust reference-counted smart pointers[1] for shareable immutable references and internal mutability[2] for non-shareable mutable references checked at runtime instead of compile time.

[1] https://doc.rust-lang.org/book/ch15-04-rc.html

[2] https://doc.rust-lang.org/book/ch15-05-interior-mutability.h...

> got completely thwarted by the borrow checker

IMvHO, Rust Ownership and Lifetime rules aren't really that hard to learn. The only trick is that a programmer cannot learn Rust exclusively by trial-and-error (which programmers love to do), trying dozens of syntax combinations to see what works. A programmer is forced to learn Rust by RTFM (which programmers hate to do), in order to understand how Rust works. That's all there's to it. It's like trying to learn to play the guitar without reading a book on guitar cords, pulling guitar strings individually at random - the music just won't happen for quite a long time, unless you're Mozart. At any rate, one can always forget Rust references (i.e., raw pointers) and use Rust reference-counted smart pointers[1], effectively writing Rust analogously to Swift.

[1] https://doc.rust-lang.org/book/ch15-04-rc.html

> I (...) have an AM4 ASUS board

No, I never tried GPU passthrough with an AMD CPU, Intel only.

> Good joke, that really made me laugh :)

I've been forwarding an AMD GPU to both Windows and macOS for literally years across multiple Asus motherboards and, except for the specific problem of host sleep/wake, had no problems whatsoever, even considering I work under GPU-passthrough VMs whole-day, every-day. Perhaps try a recent Asus motherboard?

> have to dual-boot QEMU VMs or disable the passthrough

Yes, you would have to buy as many cheap, secondary GPUs as the number of virtual machines that you want to run in parallel.

> I really want proper GPU virtualisation...

Sure, I don't blame you - my point was that the only truly usable GPU virtualization solution available today is GPU passthrough and that GPU passthrough is much easier to setup than it is commonly perceived.

> See https://looking-glass.io/ to get around directly connecting monitors

Interesting, thanks for the link!

> Had problems with e.g. a forwarded rx580

I've been forwarding Sapphire Radeon RX 580 Pulse to both Windows and macOS for literally years and, except for the specific problem of host sleep/wake, had no problems whatsoever. Perhaps try an Asus motherboard?

> Things like Intel GVT-g and VirGL are better solutions, when they can be used.

Sure, when software solutions are available and stable (and there's no need for near-native GPU performance), they are definitely easier to work with. However, as of today, GPU passthrough is probably the only solution available for a daily driver.

Good point, but I believe that was a serious problem 10 years ago, while these days virtually any decent motherboard properly supports IOMMU, consumer-grade boards included - e.g. any Asus motherboard should work perfectly.

VirGL is definitely an interesting project, but all one has to do to get GPU passthrough working (from a Linux QEMU host to any guest OS) is: 1.) research a cheap, secondary GPU that is natively supported by the guest OS, 2.) plug such a secondary GPU into a PCIe slot on the host and hook it up to the primary monitor with a secondary cable (D-Sub vs. DVI, etc.), 3.) setup Linux to ignore the secondary GPU at boot and configure a QEMU VM for the GPU passthrough. The whole process takes perhaps [edit: "a few"] hours and as works flawlessly, with no stability issues [edit: "at least with Asus motherboards"]. (Switching across the two GPU cables can be accomplished in software by using Display Data Channel /DDC/ utilities and switching keyboard/mouse can be accomplished by using evdev /event device/ passthrough.) More information: https://github.com/kholia/OSX-KVM/blob/master/notes.md#gpu-p...

Yeah, right. If website content and multimedia rendering alone is, demonstrably, not enough to saturate even a 10-year-old CPU/GPU under Linux, then no, it is not possible for "a new Mac" to be even faster at same content and multimedia rendering. It does not make any difference, productivity-wise, whether you render website content and multimedia at 60 fps, or 120 fps, or 240 fps - the eye perceives the same thing. Effectively, whatever you pay for "a new Mac" over the cost of a 10-year old, generic PC workstation is being used exclusively to accelerate macOS.

If you care about having the very latest versions of all apps, tools, compilers, etc. go with a "rolling distro" such as Manjaro (easier to setup) or Arch Linux (more advanced to administer). If you prefer upgrade stability (and a huge community with a lot of help), go with a "checkpoint distro" such as Ubuntu LTS (Long Term Support). For a desktop environment, I found LXQt (Ubuntu + LXQt = the Lubuntu distro) to be both very fast and quite modern-looking at the same time (especially if you invest some time into customizing it), while KDE Plasma (Ubuntu + KDE = the Kubuntu distro) is probably the best looking Linux out of the box, but somewhat more resource hungry. (More info at: https://distrowatch.com)

No, I don't think it's only about "more complex websites", "more taxing multimedia" and so on - it's more likely also macOS and Windows bloat and questionable software quality getting in the way. I recently installed Ubuntu Linux with the LXQt performance-oriented desktop environment on a 10-year-old Intel i7 2600 workstation back from 2011 (16 GB RAM, an Intel HD Graphics 2000 built-in GPU, an Intel SSD with specs archaic by today's standards) and the system is extremely fast and responsive at everything including web browsing, multimedia playback, IDE-based development (e.g., CodeBlocks), app launching, etc. Website content and multimedia rendering alone is not enough to saturate even a 10-year-old CPU/GPU.

I agree, I think the Rust Gods should think of some ingenious way (which actually seems to be the norm when it comes to the "thoughtfulness" of the Rust ecosystem) to do both library-style error handling (where specific error conditions have to be handled differently by a library consumer) as well as app-style error handling (where multiple error conditions can be handled pretty much the same way by an event loop), add it to the standard library and `clippy` out (lint) the livin' lights out of every other approach out there :).

Ok, let me rephrase: "[without using any instructional materials] the music will take an unusually long time before it happens, even if you're Mozart". Which seems to correspond to the problem that if you keep hacking at a Rust compiler without using any instructional materials, it will take an unusually long time before you eventually get the code to compile by trial and error.

> when I open a Rust project I cannot understand what the hell is going on (...) > Then you have to learn to map errors, boxing them, dyn dispatching (...) So it's not all "ownership and lifetimes".

I definitely see where you are coming from when it comes to PL syntax density and PL surface area in general, Rust or no Rust. I will probably surprise you when I admit that even though I have been coding C++ for decades and I learned Rust without any major problems, I lost my small personal war to become comfortable with the modern, newcomer-friendly, memory-managed... Swift. Yes, that great-for-your-first-PL Swift. I started out as a Swift aficionado, but with time I started hating the language exactly due to the fact that "I [opened] a [Swift] project [and] I [could not] understand what the hell [was] going on". The language was just too bloated and idiom-based. I gave Rust a shot and I learned Rust much more effortlessly, perhaps due to Rust's "consistency" and "predictability". My point: it might be that any modern PL can get pretty dense and broad due to the necessity of handling imperative, functional, generics, async, multi-threaded, a capable standard library, etc., while it might be just a myth that Rust is "harder to learn" than other modern PLs. For me personally, Rust "ownership and lifetimes" turned out to be easier to learn than Swift "feature set", but it might be just me.

> The worst part (for what learning regards) is that Rust doesn't forgive.

Yes, but this is the whole point of Rust! Rust tries very hard to shift bug detection from runtime to compile-time and the only way it can do that is by strictly enforcing a set of sometimes complex rules at compile time. However, it is common occurrence that it takes tenfold more time to find a bug in a piece of code (especially bugs related to unexpected memory mutation or multi-threaded memory access) than to write that piece of code in the first place. So, wrestling the Rust compiler is "a calculated cost" designed to be worth it in the end.

> What’s hard is (...) [building] [code] under the constraints of these rules

Good point - I have to admit that, for example, the single-mutable-reference rule in Rust did force me to keep restructuring my code differently than I used to in other PLs and I did struggle with it to an extent.

It doesn't automatically mean, however, that Rust is (literally) "harder to learn than other PLs". It is possibly the question of whether "a programming concept is hard to learn since it cannot be painlessly brought over from previous experience" or "a programming concept is hard to learn since it is hard to understand in itself".

> Being a member of a super-elitist cabal that knows how to use Rust "properly" is not some point of pride

I'm not sure I follow you, since I am saying something exactly opposite: anyone, even a mediocre, 1-year-of-experience programmer can successfully learn Rust, if only he or she tries to read a book on Rust, instead of just randomly hacking at Rust code. No "super-elitist" brain required, just a switch of learning methodology.

> just look at Haskell

The problem with Haskell is that it requires a monumental, conceptual switch from imperative programming to functional programming, which has not happened anywhere yet outside of academia (well, perhaps with the exception of functional reactive UI programming, e.g., React Native, Swift Combine, etc.), so Haskell is a tough sell in "real world", commercial organizations. Rust does not have this problem, since Rust does not rely on any "code [structure] metrics" (did I understand this right?), but instead moves as much bug detection as possible from runtime to compile-time (especially for multi-threaded applications).

> [Rust's Ownership and Lifetime rules] come with a steep learning curve and have been repeatedly cited as a barrier to adopting Rust

Rust Ownership and Lifetime rules aren't really that hard to learn. The only trick is that a programmer cannot learn Rust exclusively by trial-and-error (which programmers love to do), trying dozens of syntax combinations to see what works. A programmer is forced to learn Rust by RTFM (which programmers hate to do), in order to understand how Rust works. That's all there's to it. It's like trying to learn to play the guitar without reading a book on guitar cords, pulling guitar strings individually at random - the music just won't happen, even if you're Mozart.

> “Linux is only free if your time has no value”

This motto, although actually true in the past, is probably no longer valid. Install the latest Ubuntu/Kubuntu with KDE/Plasma and you get a high performance, GUI-configurable, aesthetically pleasing desktop. You will need to drop down to the Linux command line only if you need to pull off some kind of advanced networking, virtualization, etc. setup. (While you're at it, switch to the free ZFS filesystem and enjoy disk bit rot checking without Windows Enterprise/Pro ReFS). The entire Linux system and almost all user apps upgrade automatically from a set of pre-defined online installer repositories. If you want to game, boot Linux on a CPU-integrated graphics card and pass-through your stand-alone GPU to a Windows-guest KVM-host (QEMU) virtual machine for 99% native gaming performance, no need to dual-boot.

> Rust and Swift have about the same amount of syntax

I wouldn't agree, I feel Swift has significantly more surface area than Rust.

But even syntax and standard libraries aside, I think that Rust is significantly more "explicit", "consistent" and "predictable" than Swift. I consider those to be very important qualities in a PL. Maybe that's why Rust was easier to learn and memorize than Swift (with the exception of the Rust borrow checker and lifetime annotations that indeed have to be well understood to be even usable).

But it might be just me.

> [Swift] values expressiveness, and having multiple ways to do things that means you can choose a nice way to express each line, rather than always being forced to write it the same way.

There are at least two major problems with this kind of PL design approach: 1.) when you work on a large codebase from multiple contributors, all the possible combinations of the available syntax and standard library calls will eventually get used, making your brain frustrate quickly when reading code written by others, and 2.) when you interview for a new job, all the possible combinations of the available syntax and standard library calls will eventually be asked about by interviewers, making you look and feel like an incompetent programmer.

I have to agree with the OP - Swift seems to be an unreasonably bloated PL. Unless one plans to work only with Swift all the time, learning all there is to learn about Swift on the way, it might be easier to just use Rust or Go.

> when [all Apple-chosen hardware features] [are] added in, the prices will be within a close margin

I do see your point, but even if that's so, the problem of Apple hardware inaccessibility to an average computer hardware buyer cannot be considered as "resolved" or "unavoidable", but only pivots from the circumstance of "Apple forcing high profit margins on hardware buyers" to "Apple forcing a set of (unwanted, yet costly) hardware features on hardware buyers" (through the lack of appropriately varied hardware models and hardware configuration options).

Which is too bad, because if Apple hardware was appropriately inexpensive while delivering the features that I do care about, I would probably consider switching to their hardware and macOS as my primary O/S. (... But then again, maybe not - I really like the latest Linux KDE/Plasma.)

I don't know about cost effectiveness of Apple laptops, since I never use small-screen devices for daily work, but if you are willing to put together a desktop workstation with your own hands from components you hunt down individually at online sales and install the free Linux, you will not spend even half of the cost of a Mac Pro, which has not even been upgraded by Apple since 2019. The 2023 Mac Pro is to cost from $6K to the insane $10K.

iOS development has to be performed exclusively under macOS. Effectively, many iOS developers not only do not want to pay for Apple hardware that is usually grossly overpriced for its capabilities, but also strongly desire to use absolutely top-of-the-line non-Apple hardware that is way more powerful than what Apple is offering, to run their daily macOS development workstations.

... And hacking entire operating systems under virtual machines is just fun :).

Hmmmm, between Jan 2022 and Jan 2023, Rust has made the largest index jump within the Top 20, from 26 to 18 (8 notches), with all other languages making only single- or double-notch movements. Wonder if it means anything, considering the Change of only +0.11% with 0.61% Ratings.

> Rust code is almost as complex as C or C++ for any non-trivial application.

This is also, if not more, true for Swift as well. I've been working with both Swift and Rust (in addition to C++) for some time now and I find real-world, advanced Rust SIGNIFICANTLY easier to read and comprehend than real-world, advanced Swift. This is, IMHO, due to the fact that where Rust chooses to be syntactically simple, explicit and consistent, Swift chooses to be syntactically complex, idiom-based and feature-bloated. Sure, Swift code can look very modern and attractive at times, but usually when it comes to superficial code samples in Apple promotional videos. Otherwise, if you, say, look at a large codebase written by someone else, Swift reads just as badly as C++ complexity-wise.

Just my $0.02: start a side project and work on it evenings/weekends, while keeping your day job. Yes, it will be tough, but delaying it is not the best idea, since working overtime without burnout gets harder and harder as you get older. Make sure NOT to make the mistake of focusing only on the more enjoyable, technical side of the undertaking (read: exciting technologies and software development), but pay a lot of attention to the more boring, business side of your project (read: educating yourself on product/market fit, initial marketing strategies, growth hacking, etc.) Find out whether you are going to even enjoy the non-technical, business side of a startup. Realize that since you do not have a lot of money to burn and/or a lot of time to clock in, you will have to avoid huge mistakes and develop a very good business idea and a very good Minimal Value Product that will let you FEEL at least SOME startup traction early on; otherwise, if your side project never gets at least a bit exciting relatively early on, you will just get tired of it all and dump it. (Or not, which would be a valuable lesson as well: the one that you get addicted to running your own businesses.)

It's possible to run the entire Kubuntu system with `apt` and/or local `deb` packages only - I uninstalled `snapd` a long time ago.

macOS UI capabilities aside, I have to mention that the latest Kubuntu 22.04 Long Term Support (LTS) 2022 release with KDE Plasma 5.24 is a fantastic upgrade. The system is snappy, much more so than under the previous Kubuntu 20.04 2020 release. Moreover, the 5.15 Linux kernel seems to be handling huge memory allocations for virtual machines an order of magnitude faster than the previous 5.4 kernel.

If you are tired of macOS, I wholeheartedly recommend giving Kubuntu 22.04 LTS a try. (You can always buy a second GPU and run macOS inside a QEMU virtual machine, 99% stable at native UI speeds with GPU passthrough.)

Intro/conceptual: "A Firehose of Rust, for busy people who know some C++"[1]. Beginner's: "Rhymu's Videos"[2] and/or "Doug Milford" videos[3], advanced: "Jon Gjengset" videos[4]. Finally, "The Little Book of Rust Books"[5].

Rust is easy to learn by studying (in order to understand its unique concepts such as the borrow checker and lifetime annotations), but Rust is hard to learn by experimentation alone (trying 100 different syntax variations to see what compiles).

[1] https://www.youtube.com/watch?v=FSyfZVuD32Y

[2] https://www.youtube.com/c/rhymu8354/videos

[3] https://www.youtube.com/channel/UCmBgC0JN41HjyjAXfkdkp-Q/vid...

[4] https://www.youtube.com/c/JonGjengset/videos

[5] https://lborb.github.io/book/