> By using Rust for both our frontend and backend, we have a unified stack of Rust everywhere, simplifying our hiring.<p>> I can write web apps in another language than JavaScript<p>> I can write web apps that are fast<p>Yeah, this is what's worrying me. If you look at rerun.io website, you will notice that it's built with Next.js, i.e. is using a React framework to build pages that have no interactivity whatsoever. Next.js is used for the blog, despite it being just a collection of simple static html pages. Meanwhile, the user has to download around 200kB of javascript for no reason whatsoever; and the only reward that they get for their trouble is an avalanche of javascript errors in the browser console [0].<p>Is the Rust/wasm future going to look like that?<p>[0] - <a href="https://i.imgur.com/TpYW0Rj.png" rel="nofollow">https://i.imgur.com/TpYW0Rj.png</a>
I've started working in Rust too and I too find it a tremendous breath of fresh air. It's the first time I've been excited about a new programming language in many years.<p>C++ promised to be a language that was both high performance and very expressive but I always found it very difficult to work at a high level of abstraction in C++. The sharp details always stab through.<p>Rust code, on the other hand, often doesn't look much more elaborate than code I write in much higher level languages but it's far, far faster and I feel more confident in its correctness.<p>Too bad most of the Rust jobs right now seem to be in crypto.
> Rust's enums and exhaustive match statement are just amazing<p>ADTs + pattern matching are the killer feature set that makes the more popular functional languages so damn pleasant to use, and they're starting to spread to more and more languages. I suspect that, 50 years from now, we'll look back and see them as the key paradigm shift of this era.
> There is of course some legitimate worry that the Rust crate ecosystem could devolve into the crazy left-pad world of npm, and it is something to be wary about, but so far the Rust crates keep an overall high quality.<p>Note that the particular case of left-pad cannot happen with crates.io/cargo, because once published, you cannot unpublish a crate. You can 'yank' it, in which case it will not be resolved by Cargo.toml, but if you put it in Cargo.lock directly (IIUC) it will still work. So we can't have someone pulling a crate and crashing half the ecosystem.<p>We can however still have lots of other problems that plague all package management systems. Check out `cargo-crev`!!!! It's an awesome idea I'm always plugging to solve the lack of trust in an open library repository. It requires people to participate though.
> Rust's enums and exhaustive match statement are just amazing, and now that I'm using them daily I can barely imagine how I could live without them for so long.<p>I feel this! I absolutely love rust's fancy enums - i.e. not just a set of constants, but where each variant can be a full fledged type of its own, and how you have to handle every case whenever you're matching on it. It dovetails absolutely wonderfully with non-nullability and errors as values. This is probably the main nice-to-have in a language for me. Unfortunately, I don't really work in a low-level domain so I'm not sure the extra complexity of manually managing memory is worth it to me.<p>Do any other higher-level languages have rust-style enums with exhaustiveness checking? I only know of Haskell and Ocaml. Actually, I suppose TypeScript has something kind of similar.
> Safety and speed<p>One thing I can't seem to find a quick answer to from the Rust crowed is how does Rust handle dynamic lifetimes? It seems like it does not; it simply prevents you from referring to objects that have a dynamic lifetime not known at compile time.<p>You either have to use 'unsafe' or use the 'handles' pattern where you have what amounts to a custom allocator but the compiler does not know that it's an allocator so it can't prevent 'use after free' bugs.<p>I suppose you can also use Rc, but isn't that essentially a garbage collection scheme, with similar performance characteristics? (AFAICT a reference counting scheme must be able to nullify all references to an object when it's deallocated, so deallocations can become arbitrarily expensive).<p>Am I missing something?
> Floating point behavior<p>Since 1.62 there have been a native way of doing it with the `total_cmp` method [0] on floating points which can be used to at least sort it quite easily, but cannot really use it in collections like BTreeMap.<p>[0]: <a href="https://doc.rust-lang.org/std/primitive.f64.html#method.total_cmp" rel="nofollow">https://doc.rust-lang.org/std/primitive.f64.html#method.tota...</a>
As someone who's not the biggest fan of Rust because of its complexity. There is a big reason to use it today. If you need to use something that has safety guarantees where it's possible to achieve acceptable performance in certain classes of programs where languages like golang, nim or crystal have trouble achieving then I just don't see any other options out there certainly not one with as many libraries available as rust.<p>Maybe I can use a combination like c and lua to get the right trade offs between safety and performance in the necessary parts of my program but I'm not that confident that I can reach either safety or acceptable performance doing that.<p>Maybe, I could use C and some kind of static analyzer to find all of my memory bugs. Again, I'm
not confident I would succeed there. I might also need a fuzzer to do it.
At this point I'm trading a complicated language for a easy fast language with extra complicated operations that may or may not give me the outcome of memory safety.
Most benefits of Rust are true, except in some cases it does not allow you to compile an absolutely valid and safe program like here <a href="https://github.com/rust-lang/rust/issues/47680" rel="nofollow">https://github.com/rust-lang/rust/issues/47680</a> - unfortunately you don't have freedom of code design decisions! I see some possible problems with refactoring, extending logic and functionality, and lots of issues with async code design and readability.<p>For me, Rust looks like a temporary step before the next language.
I don't understand why everyone seems to ignore Ada? Granted I am completely new to it, but from what I see it is years ahead of Rust in terms of safety (it can <i>prove</i> correctness!! Rust is only heading into that direction).<p>Yes syntax is verbose, but I dare to believe there must be another blocker than just syntax?
> We've had fast languages like C and C++, and then we've had safe languages like Lisp, Java, and Python. The safe languages were all slower.<p>Them's fightin' words. SBCL (Lisp) totally screams with speed as far as I've been able to tell.
I just bootstrapped Rustc 1.58 using only GCC and mrustc sources on an 8 core 16 thread machine with 32 GB memory and lot's of disk space. It took 20 hours.<p>If you think Rust is bloated, I agree.
As a developer who mainly writes front end apps with Javascript (but with experience in a lot of other languages), I started to learn Rust for an app I want to build.<p>The issue is that the app itself will not really be needing maximum performance and I much more concerned about the safety aspects Rust brings. But I guess the safety aspects would be the same with me using Python for example.<p>Why I want to learn Rust is because it could help me in the front end aspect and I think it's a language that has a bright future.<p>Am I crazy to spend the time to get effecient in Rust and write my app I want to write in Rust instead of Python? Is there any other benefits of using Rust that I don't see as a beginner? I am afraid that I'll just waste a bunch of time just because I want to learn Rust and think it's cool but ultimately it will slow me down to such an extent that my app never sees the light of day or that it increases general development time.<p>Thanks in advance for all potential responses
I saw a YT video about how safe Rust is. I want to give it a try but I do mainly web applications, where I use Spring Boot and front-end frameworks. From what I have read Rust is better for system level or regular applications (not web apps). Can modern web applications be built efficiently with Rust? And by efficiently I mean, is the ecosystem there (libraries and tools).<p>I imagine the following would be needed..<p>1) Spring MVC like library for interfacing with HTTP requests.<p>2) DB ORM or ORM like. DB libraries for any possible DB.<p>3) centralized logging. e,g, Logback that forwards all logs to ELK.<p>4) Dependency injection.<p>5) Versatile configuration system. Similar to Spring configurations.<p>6) AWS SDK.<p>7) Commons like libs like Guice or Apache Commons.<p>stuff like that.
I've heard about Web Assembly/Wasm many times. I thought it was a new kind of JS framework, so I did not pay attention since I am not a JS developer. However, after seeing the egui.rs demo [1], I was impressed! Now, I am interested in knowing more about programming languages that compiles to Wasm. Is it possible to create that sort of UI using other programming languages?<p>[1] <a href="https://www.egui.rs/" rel="nofollow">https://www.egui.rs/</a>
For someone like me that's an experienced programmer but relatively new to Rust, what are some open source Rust projects that could benefit from some help?
Honestly, this kind of breathless adulation is off-putting to me.<p>> If I'm honest, the main reason is because I love Rust.<p>That's nice if it works for you, but I'm looking to build and maintain software well and efficiently. I don't want a programming language I can love I want a tool. (BTW, old and tired but true: don't love things that can't love you back.)
In "Oral History of Bjarne Stroustrup" Bjarne describes his goal for C++, which was abstractions with zero runtime cost : <a href="https://www.youtube.com/watch?v=ZO0PXYMVGSU" rel="nofollow">https://www.youtube.com/watch?v=ZO0PXYMVGSU</a><p>I understand Rust is fast, but how does it do with complex abstractions?
One issue with egui and shoving the whole page into a canvas element is accessibility -- having just a canvas element is a screen reader's worst nightmare