Ephera
link
810M

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.

Dessalines
admin
link
810M

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.

@AgreeableLandscape
mod
admin
creator
link
4
edit-2
10M

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.

Dessalines
admin
link
410M

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.

Dreeg Ocedam
link
710M

Nushell doesn’t try to emulate Rust’s syntax in the shell though. It is just implemented in Rust. It’s main idea is more to have (sort of) typed data in pipes, instead of just binary like in the Unix shell.

I really like the idea behind Nushell because it could become a very expressive language to easily implement script that would normally require a more full blown language. For exemple, it could become super powerfull to manipulate CSV files.

@AgreeableLandscape
mod
admin
creator
link
310M

Just installed it, planning on trying it out!

@bluerabbit
link
710M

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.
@AgreeableLandscape
mod
admin
creator
link
3
edit-2
10M

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?

@bluerabbit
link
410M

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.

Ravn
link
610M

No, only those it’s better than, such as the C languages.

@Halbeard
link
410M

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.

Dreeg Ocedam
link
510M

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).

@curious
link
4
edit-2
10M

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).

Dessalines
admin
link
1410M

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.

Dreeg Ocedam
link
5
edit-2
10M

I fully agree with you. Making larger and more resource hungry apps only leads to a faster turnover of our devices, which leads to pollution also.

However, I don’t think that Rust is the solution for that. It is way too complex, which means that it is too expensive to use where performance doesn’t really bring money. I think that for that kind of stuff, Go is much more interesting. I think that if someone where to make good, cross-platform UI framework for Go (or maybe a language + framework with the simplicity of Go, since Go is not really UI oriented) it would be able to compete with Electron for apps like chat etc…

Maybe a functional language could actually have its place here.

@AgreeableLandscape
mod
admin
creator
link
410M

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.

Dessalines
admin
link
510M

I’d love if someone did that calculation too. Could be a LOT of watt-hours per day just wasted by things like discord.

Dreeg Ocedam
link
210M

IMO the biggest impact of those apps is that they push people to buy new computers/smartphones to be able to keep up the processing power and storage space required by theses apps.

This causes a lot more carbon emissions than the electricity required to run them.

@curious
link
210M

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.

@developred
link
3
edit-2
8M

deleted by creator

Dessalines
admin
link
210M

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.

@nutomic
mod
admin
link
410M

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.

@bluefish
banned
link
210M

Not at all, There will be some language which half designed by AI, other half designed by Human.

@Lowey
link
110M

No, it is a great addition not a replacement.

@developred
link
1
edit-2
8M

deleted by creator

Dreeg Ocedam
link
210M

Not always true: https://lemmy.ml/post/43856

@developred
link
1
edit-2
8M

deleted by creator

Dreeg Ocedam
link
310M

I think that Rust will slowly become the standard for implementing new stuff that require high performance, but they will mostly provide a higher level abstraction (in python for example) so that more scientists can use it.

Rust Programming
!rust
    • 0 users online
    • 7 users / day
    • 7 users / week
    • 13 users / month
    • 54 users / 6 months
    • 1225 subscribers
    • 281 Posts
    • 319 Comments
    • Modlog