Genuinely serious since this is so much of a meme.
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.
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.
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.
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.
TBH Garbage collectors aren’t really the issue. There are plenty of Java/C#/Go apps that feel super snappy and have a relatively small memory footprint. Dynamic typing is a much bigger factor in performance than GCs. The issue is also that now everything needs to happen in the browser, because it’s the only “true” cross-platform solution for the moment. So lazy devs prefer running a full Chromium instance than using a native framework.
Also the reason is that since JS is the first language of a lot of devs (because in runs in the Web, and the NPM ecosystem is one of the easiest to get into) JS devs are cheap. On the other hand, other languages are much harder to get into.
Golang was created to be able to rival JS in terms of ease to get into, so it is gaining a lot of traction for backend stuff. However it doesn’t really have good ways to do GUIs, so for apps we may have to wait.
I don’t think one minute that Rust will ever become a mainstream language for writing GUI apps outside of specific cases where performance is primordial (browsers for example) because it is way too hard to get into and that means high costs of training/salaries.
However I completely believe that in the long terrm, Rust has the potential to completely replace C/C++. It’s actually easier to learn, easier to use, and its main feature (safety) will save companies a TON of money that would otherwise be spent debugging/dealing with bugs in production (including security issues). There are a few rough edges to fix, but we will get there (embedded targets, behing standardized and having other compilers that the official one).
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)
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.
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 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?
Not at all, There will be some language which half designed by AI, other half designed by Human.
