Genuinely serious since this is so much of a meme.
I don’t, but I do think that humanity has produced a lot of terrible programming languages and Rust is not one of them.
So, it may not be the ideal tool for every job, but it gets a lot of stuff very right and really not a lot wrong.
Do you actually think that Rust can and should replace all or most other programming languages?
No, Rust is the wrong tool for that. Rust is a good choice if your working on low level code or have high speed requirements. Like 95% of the time it is a better decision to trade some speed and space for better productivity. I would even argue that we don’t push simplicity enough. Computers are becoming faster and faster, we should create simpler programming languages that use more resources.
In my ideal world we would write operating systems and drivers in Rust and all other things in a Lisp like language. Yes Lisp, because Lisp is decades ahead of what most other programming languages offer and at the same time Lisp is very simple at its core. The developer workflow is totally superior, to an extend, that when explaining it to a normal developer, it will be outside of the scope of understanding. Not because its difficult, but because it is so different. Too bad, that a lot of Lisp languages are outdated and have a not so practical std lib for today’s world. This doesn’t change the fact that Lisp is IMHO the best solution to programming humanity has invented. If you don’t believe me that Lisp like languages are so fare ahead, watch this talk . There are a lot of interesting and very good ideas outside of the usual programming world that should be used by the mainstream (no I don’t think Clojure is THE language, they just have some good videos online).
Computers are becoming faster and faster, we should create simpler programming languages that use more resources.
Devs thinking like this are the reason our chat apps and some text editors are in electron, wasting tons of system resources, by running what is essentially its own operating system, chromium.
Just to give an idea, here’s some things I have running on my laptop right now:
App | Ram
- | - Signal Desktop (Electron) | 368 Mb Lightcord (Discord, Electron) | 367 Mb Element (Electron) | 212 Mb
Before electron, back in the AIM / IRC / MSN messenger days, these were tiny programs easily runnable on a 256 MB ram machine.
This article is about website bloat, but it equally applies to so many of our chat apps that went from using system libraries and GUI frameworks, to the browser.
When an app is installed on millions of devices, making it more efficient can actually make a not insignificant difference in overall power consumption, and therefore environmental impact.
I’d love if someone did that calculation too. Could be a LOT of watt-hours per day just wasted by things like discord.
The KDE project has been focusing on sustainability, as a system efficiency metric, for some time now.
deleted by creator
Amen! Electron is a scourge. Look at MicroSIP, a full SIP chat and call client done in MFC. Exe is 3 MB, uses less that 10 MB RAM. Runs super stable, super quick (native GUI) and light enough to always be on.
deleted by creator
It seems like you misunderstood my point. By saying that we should use more resources to make computing simpler I meant something like using a garbage collector, which trades some computing cycles and memory for better productivity and not something like bloating stuff up by using Electron. A lot of programming languages where designed when computers where slower and had not much memory. I would happily give 5% of performance and memory to have another improvement in productivity like the invention of the garbage collector gave us.
… and now it actually feels more productive than Java.
Java has always been full of boilerplate code, therefor it never really was very productive (maybe when compared to C++). I don’t get why anyone still writes Java, when there is Kotlin.
- Java code is approximately 50% shorter than C++ code
- Kotlin code is approximately 50% shorter than Java code
- Haskell code is approximately 80% shorter than Kotlin code
→ what takes one pages in C++, takes 2-4 lines in Haskell.
To the Nushell discussion: Nu is my main shell and I have contributed a bit of code to it in the past.
deleted by creator
Yeah its hard to find these things, apparently privacy is better and they removed some of the tracking, but you still can’t be too sure.
I completely disagree with you on Rust productivity. Its true that there is a very steep learning curve, and during that time productivity can be low. But I have used Rust for almost one year now, and now it actually feels more productive than Java. Simply because entire classes of errors are eliminated, and I don’t have to debut them. Instead I can quickly iterate on high level changes. Runtime performance is nothing but a nice bonus.
I really like Rust but there are lots of situations I wouldn’t use it. Some examples:
- If I want very strict control over dependencies, a very small number of dependencies, or dependencies with specific/trusted origin.
- If I was building software that won’t be actively maintained for years but might need adjustments later. The Rust ecosystem is a fast-moving target and upgrading a library could cause a huge cascade of other changes.
- For the most hassle-free integration with an important library like Qt, particularly if a Qt GUI is the main point of my application.
- Most web front-end. Using WASM to control the DOM with glue code is using a sledgehammer to crack a nut.
- (?) Probably most event-driven apps like GUIs. Rust’s lifetimes mostly stay out of your way but they only work on the stack. Synchronisation between potentially multiple threads is very in-your-face and explicit, compared with say Java’s “synchronized” methods. It’s only early days for Rust GUI frameworks so I will wait and see. Maybe they’ll come up with something great.
I’m most curious about your thoughts on GUI apps: For Qt, is the main problem right now the fact that no complete bindings exist or is Rust fundamentally problematic for Qt integration? If Rust had a complete binding of Qt or GTK libraries, would you use Rust as opposed to the framework’s native language (C++ and C respectively)? What’s currently your favourite language for GUI development and what makes it suitable for GUI?
www.areweguiyet.com says that “Rust’s expressiveness and high level abstractions make it ideal for building intricate and complex user interfaces.” What do you think of this?
Most of my GUI experience is with Cocoa/UIKit (Mac/iOS). ObjC and Swift will let you play fast and loose with concurrent access to state and this is extremely convenient, though leaving the potential for a crash.
A Window might conceptually own a Button1 and Button2. So far this makes sense - if the Window is destroyed, its buttons should also be destroyed. Now imagine we attach an action to Button1 that disables Button2. Perhaps this “action” is a closure. Now we have an independent code block that has a reference to perform a mutating action on Button2. In ObjC you can simply do this by having a pointer to it. Rust won’t have a bar of it unless you use explicitly use reference counting and mutexes. It’s not just UI actions either - scheduled timers, URL downloaders and all kinds of other components need to take ownership of UI at spontaneous times.
Explicit mutexes aren’t the only option - the UI library could abstract over the UI elements so the mutexes are hidden from you - but then you’ve just replaced Rust semantics with Java/ObjC synchronisation so why are you writing Rust? Alternatively you could replace this very convenient event-driven design with a single “processing” function where you temporarily have mutable access to everything - I read about that in the design for one library. I didn’t like the sound of it.
There are options. None of them feels as ergonomic as the dangerous status quo that I’m used to. As I suggested, I’m not yet convinced Rust is a bad choice for this, but any library will have to think carefully to make this not suck. For now I would rather use a battle-tested option.
For Qt and GTK it would be okay if the bindings were high quality and there was good documentation/examples. I am skilled in neither and wouldn’t want the extra hassle of “making it work in Rust” unless this was outweighed by other advantages.
Unironically yes for me. At least out of the languages I’ve worked most in, when I have to go back to them, I find myself saying that rust did this much better.
I used to use duck typed languages for scripting, but those quickly grow complex to where you wish you had compile time type checking anyway.
Unfortunately the main GUI platforms today are the web, and mobile apps, and neither can really use rust yet.
What are your thoughts on a possible command line syntax derived from Rust? Kind of like how TempleOS (that really weird religious operating system created by one person) has a shell with C-like syntax, complete with include statements and semicolons after every command.
I hate bash/sh script’s syntax and really hate batch/powershell, but I don’t know if a Rust-based shell would be better.
I don’t know about syntax, there is this Nushell, which is a rust-based shell. I don’t know enough about what makes a good shell syntax to know whether rust-style would be a good fit there.
deleted by creator
Just installed it, planning on trying it out!
No, only those it’s better than, such as the C languages.
I don’t know if it can, but in an ideal world it or some other unmanaged language with high level features should. The world is polluted by too much managed code that draws too much power unnecessarily if it’s used more often than what development time went in.
deleted by creator
Programming languages are tools. And specific problems are better handle by its proper tools. Rust is great, but not for every-and-all problems.
As example, data exploration. For that I really prefer Python, the ergonomics are far better than Rust for this use case. (And even in this case, Rust can help with Polars)
No, it is a great addition not a replacement.
deleted by creator
deleted by creator
deleted by creator
deleted by creator
Not at all, There will be some language which half designed by AI, other half designed by Human.
