8 ms·

My theory is that every technology that is too complex gets replaced with something that does the same thing more simply. You see this relentlessly in the JavaS

My theory is that every technology that is too complex gets replaced with something that does the same thing more simply. You see this relentlessly in the JavaScript ecosystem where waves of too-complex tools get rapidly replaced with something else, only to be swept away again when someone finds an even more simple way to do the same thing. This must be the fate of Rust - eventually it will be replaced with a language that gives the memory and thread safety without the melt-your-brain complexity. I want a simpler version of Rust. It's too hard. Is it possible to create a truly safe language without the dizzying complexity? Or is it the complexity a baseline requirement? I wonder if there is a subset of Rust that can be extracted someone into a new, minimal language with the core benefits.

goodpoint 4y ago
You want Nim.
echelon 4y ago
Writing Rust/Actix for server code is a breeze. There's zero complexity. It's practically Java, just with a more Ruby-like syntax. Entirely depends on what you're building. Edit: You can have a small Actix app up over the weekend and never touch "lifetimes" until you're ready.
- andrewstuart 4y ago
  After my initial failed attempt to learn Rust I then took a second shot at it by writing Actix web code and had alot more success. This is the path I would take if I was returning to Rust. Having said that, I felt that for the most part this approach was just avoiding the task of learning the complexities. But, I do believe that learning something hard starts by learning a little bit of it and building on that initial foothold.
- lossolo 4y ago
  > Entirely depends on what you're building. Exactly this, if you are building some CRUD app then it's as easy as using Java or Go etc, because basically there you have request -> contact some db -> return result, maybe do some processing of that data, so no need to fight borrow checker at all. But if you build something like multiplayer game server with lots of state of 3D world that constantly changes and interacts with itself, that is operating on self referencing data structures etc then it's not as easy as in GC language.
- brown 4y ago
  I could not disagree more. The moment you need to do something remarkably simple, such as string concatenation, you are confronted with the reality that Rust is a much lower level language.
  - rascul 4y ago
    In the simplest form, string concatenation is simple. https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f72521a8b1d86acb4b082326c36ec4e1 https://play.rust-lang.org/?version=stable&mode=debug&editio... I usually use concat() though. https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=78337475ece89b199a6249b4b3c90e78 https://play.rust-lang.org/?version=stable&mode=debug&editio...
- Thaxll 4y ago
  For simple CRUD app maybe, but the moment you start to do anything more complicated, aka manipulating data it's a complete different story.
- josephg 4y ago
  Part of my work involves the braid HTTP spec. Braid uses a custom server-sent events like protocol sent over long lived HTTP connections. I spent about a week trying to get this working using rust & actix. My code became mired in complex lifetimes, crazy iterators, Pin, async and Futures. Hundreds of lines of code later, I gave up and rewrote the whole thing in an hour or two, in about 30 lines of javascript. The whole experience was so bad I've sworn off using async rust entirely until a few more features land. Thankfully, apparently there GAT lands next release - although its not clear to me if it'll work for futures yet, or if thats a later goal. I love rust. But, wow.
- rascul 4y ago
  I don't know anything about Java or Ruby but I've tried several rust web frameworks and Actix is the one I always find myself using in the end.
eminence32 4y ago
>I want a simpler version of Rust. Some relevant reading: https://without.boats/blog/revisiting-a-smaller-rust/ https://without.boats/blog/revisiting-a-smaller-rust/
jjtheblunt 4y ago
> I want a simpler version of Rust. C arguably is, considering the analyses done on programs in C are not precluded from being super stringent, perhaps as stringent with compiler-specific flags?
aussiesnack 4y ago
I'm currently learning Rust (as a distinctly average programmer) and I think I agree. I put that so tentatively because I have experienced something of what Rust advocates claim - ie. when I've battled just trying to get a module to work at all for a while, but then when it does fit together (in a rather pleasing way, like gears snicking neatly together), it just continues to work. So I don't rule out the possibility that with more experience the fitting-together experiences will overtop the ugh-this-is-difficult ones, and I will become another Rust enthuser. But on the other hand I'm often driven mad by the complexity, not so much of the language, but the libraries. There are several very popular & foundational ones I've used where I've literally not once managed to get anything working by following the incomprehensible docs, only by chasing up blog and forum posts in the desperate hope of finding a usable snippet. Then there is the community, which despite its reputation for inclusiveness, is insufferably smug (for genuinely pleasant communities, try Elixir or Clojure). If you say something is difficult, they'll just inform you it's not, therefore by implication you must be thick or obtuse.
- Cyph0n 4y ago
  Out of curiosity, can you share examples of popular libraries that were difficult to get working correctly?
  - aussiesnack 4y ago
    One example - clap, which is by far the most commonly recommended cli args parsing library. Plain uses of the derive api are simple enough, but I found it a huge time suck to figure out how to do anything remotely different from the docs' examples. On my first 'real' Rust project, it took nearly half my time just figuring out how to deal with cli args. In retrospect I probably should have either used the Builder api (which is more explicit) or parsed the args manually. But I've experienced similar things repeatedly. Complexity seems to be tolerated (even vaunted) by the Rust dev community at large. I don't rule out that this may have good reasons behind it (the nature of Rust's natural domain, etc).
    - rascul 4y ago
CountSessine 4y ago
I think any language that has the concept of storage classes will be complicated because you have to deal with copy versus move vs borrow semantics. Other languages get around this by just saying that primitives are on the frame and everything else is on the heap. Efficiency has its price.
- andrewstuart 4y ago
  As I understand it Rust is composed of 5 or 6 sub languages. I find it hard to believe that there's no way to get the benefits of Rust without 5 languages. Why can't a programming language be one language that does everything it needs to do? Seems crazy to me to have 5 or 6 sublanguages.
  - kibwen 4y ago
    > As I understand it Rust is composed of 5 or 6 sub languages. Where have you heard this? That's certainly not the case.
  - aussiesnack 4y ago
    Not quite sure what you mean by sublanguages - procedural and declarative macros perhaps? In any case I wonder about the simplicity/complexity dance. Simplification ends up with something like Lisp, in which you write DSLs that each has to be independently learned. Elixir does something similar. Some differentiation might just be a natural consequence of chasing ergonomics.
    - woodruffw 4y ago
      If I had to guess: Safe Rust, Unsafe Rust, proc macros, declarative macros, the attribute language, and maybe async Rust (although I'd really just consider this sugar on Safe Rust). I love Rust, but I would love to see more syntactic unification between these components. Both macro languages, in particular.
      - andrewstuart 4y ago
jerf 4y ago
"Is it possible to create a truly safe language without the dizzying complexity?" Yes! The good news is, they even already exist. There's even at least two variants of them: Pure immutable values (Haskell, Erlang) and languages that aren't pure functional but involve lots of little execution units that can't send mutable references between the units (Elixir, Pony) which when used even slightly properly makes unaccounted-for mutation a non-problem. Those are not intended as complete lists, either. I gather Clojure can be used to a large degree this way, for instance. Nor is this a full list of all the possible solutions, just the ones that leap to my mind. The bad news is, the complexity in Rust is still there for a reason. I see the earlier efforts as something like the same picture as Rust is trying to be, but blurred. Immutability and inability to mutate across threads at all both solve the safety problems, but with a bigger hammer and a blunter flattening of the problem space. Technically, Rust's greater complexity allows it to hug the true parameters of the safety problem space more closely. I suspect that tradeoff is fundamental and you can't have Rust's feature set without roughly equivalent complexity. Fortunately, not every language has to be Rust. Fortunately, Rust exists for those times when we really, really need it. There can't be one language to rule them all, and Rust isn't going to fill that nonexistent niche. That's OK. Rust only has to be the best Rust it can be, and those other languages can be the best languages they can be, and in the end that's just as good as it can get. (Also, while this isn't a solution to the safety problem, you can still get a lot of mileage by adopting solutions from those domains into languages that technically unsafe, but work fairly well if you program them with a collection of reasonably safe patterns. I work a lot in Go. It is not particularly safe, technically; safer than C but that's a low, low bar. But in practice I don't have a lot of safety problems with it because I spent years cutting my teeth on Erlang and Haskell and my designs are informed by that.)
- resonious 4y ago
  Aren't Haskell and Erlang both GC? I don't think anyone is touting Rust as newly immutable. The only differentiator (to my understanding) is Rust's safety without GC.
  - mikepurvis 4y ago
    I don't know that that's really the whole story. I mean, C++ has smart pointers that do reference counting, same as Rust's do. But C++ can't provide most of the rest of guarantees that Rust can, like that you didn't hold a reference to that argument, or return a pointer to a local variable that's about to go out of scope, or that these threads aren't both touching that thing at the same time.
xpressvideoz 4y ago
> My theory is that every technology that is too complex gets replaced with something that does the same thing more simply. If what you said was true, JavaScript itself should have been replaced by something simpler, which didn't happen. My theory is that when some technology is good enough, it gets stuck. The previous JavaScript tools got replaced because they were not good enough.
- int_19h 4y ago
  That doesn't explain why the replacement stuff keeps going in circles so persistently, though.
kibwen 4y ago
Did you bother to read the OP? The thesis is that Rust is actively reducing its own complexity by becoming more self-consistent over time, with fewer arbitrary restrictions about what can be used where.
yyyk 4y ago
Rust is rather lean - you'd have to give up something to simply. e.g. most simpler languages are GC languages. That said, GC shouldn't be a problem for 90% of apps. Now, it's not unlikely that eventually Rust will accrete enough baggage to need replacement too - I'm guessing we have 20 years minimum until that happens?
- jjtheblunt 4y ago
  It seems like a section of those enthused already left quite publically, maybe a couple years ago, once async was added with that syntax.
  - kibwen 4y ago
    I'm not entirely sure what this is referring to? If it's something about Rust's postfix await syntax, it's quite lovely in practice, and even if someone disagreed they wouldn't leave the language over something like that.
    - jjtheblunt 4y ago
      Scanning back over the past couple years, there's plenty of commentary about coloring in async Rust https://hn.algolia.com/?q=rust+async https://hn.algolia.com/?q=rust+async
slurpmaker 4y ago
It's really not that hard. You just need to practice a bit and get over some concepts. Highly recommend buying a rust book to supplement the online rust book, or getting involving the a forum/chatroom and asking questions. The community realizes it's a bit of a brain shock, but once you get over it, it's actually pretty easy to do 99% of the things you need to do. Even, easier than in other languages in a lot of cases. A few areas are tricky/hard, but if you walk before you run (which most people SHOULD do in other languages) it's entirely doable. The problem with an easier rust is... These are the rules for using your computer safely. Like, this is what you should be doing when reading/writing C code. Or C++. So learning rust is hard, but it makes you a better programmer faster IMO. Also... once you write rust code it's usually good, no weird surprises Saturday at 2:00am in production, it's just done and works. Anyway wishing you the best, but be careful asking for "an easier rust". An easier "Rust" probably isn't safe and you might as well just be writing any other language.
webkike 4y ago
If this is the case, why hasn’t math been replaced?
- kccqzy 4y ago
  Parts of math have been replaced. The original Maxwell's equations were replaced since the new ones were much simpler.
  - webkike 4y ago
    What part of rust do you think can be made simpler?
lumost 4y ago
The main advantage of rust is that you can “do anything” with it. It’s fast, it has deterministic performance, you can embed it, you can write low level code, you can write fancy high level code. Cpp devs never moved because there were always large projects chugging along in cpp and they always had the feeling that they knew what they were doing.
nu11ptr 4y ago
This exactly how I felt the first two times I tried it, but I never really just dove in. The third time I just dove in. The learning curve is straight up, but once you are over (took me about a month), Rust isn't really all that hard. I can write it as fast as I can write Python typically, so that friction you probably feel will go away...entirely. Sure, there are a few corner cases where the type system gets hard and the more you care about every cycle of performance the more of those you have, but if you are just looking to code Rust as a high level language, it really isn't that hard. Knowing that everything is likely to work when it compiles is really good feeling too. Tips/Concepts: - Form a mental model of the rules/memory model of the language, this will help you get to an understanding, and once you understand you don't have to remember the rules.. you could write them yourself. - The analogy I used to understand borrowing: it is like a read/write lock. Any data structure can be read any number of times (&), but it can only be written once at a time (&mut) - Borrowing "locks" the position of the data structure and this is one of my favorite features. Imagine you have a reference to the middle of a data structure and then it suddenly moves... this can't happen in Rust as borrows "lock" the struct from moving - Lifetimes aren't magic and you are in no way defining the lifetimes themselves with lifetime annotations. All you are doing is helping the compiler see which references are backed by what values already. Once you understand which these are lifetimes become easy. - Eventually you will have an aha moment.. and you will wonder what was so hard. You will have to think about memory in a lower level way, but only to learn it, after that it is just natural
- aussiesnack 4y ago
  > Rust isn't really all that hard. You don't find it hard. Many do.
  - kibwen 4y ago
    Yes, Rust is quite different from typical languages thanks to ownership and borrowing. It often takes people several attempts to learn it before their perspective shifts and it finally clicks for them. But this perception of Rust has less to do with Rust being "hard" than it has to do with Rust being "different". To be sure, Rust has hard parts even after you've internalized the differences, but IMO by that point it's not substantially different from mastering the hard parts of other languages (especially other systems languages, none of whom can get away with entirely sweeping the details of the machine under the rug).
rascul 4y ago
I'm just a hobby coder. Except for lifetimes and a bit of fighting with the borrow checker, the language came fairly easily for me. After banging my head against the borrow checker for a week or two at some point something switched in my brain and all of a sudden I wasn't fighting the borrow checker anymore. This was spending maybe 1-2 hours a day with rust. I don't often have a lot of time to write code. Everyone has their own experiences, though, and this is just mine.
deleted 4y ago
[deleted]
jasfi 4y ago
That's Nim.
azakai 4y ago
> I wonder if there is a subset of Rust that can be extracted someone into a new, minimal language with the core benefits. That is basically what Val aims to do: https://www.val-lang.dev/ https://www.val-lang.dev/ It has Rust-style ownership to guarantee memory safety, but without the complexity of lifetimes. There is still a borrow-checker-like component, but I believe it should be much simpler than Rust's (see e.g. "method bundles" and how they are called). Still in the research phase. It is an open question how well this approach scales.
verdagon 4y ago
Good news! Complexity isn't a baseline requirement: it's possible to make a language that has the basic patterns and benefits of an average Rust program. It's what we're doing in Vale [0]. It turns out, they key is to move some checks to run-time [1] to reduce complexity, move other checks instead to compile-time [2] where it doesn't increase complexity, and then make the borrow checker "opt-in" instead of forcing it to be used everywhere [3]. [0] https://vale.dev/ https://vale.dev/ [1] https://verdagon.dev/blog/generational-references https://verdagon.dev/blog/generational-references [2] https://verdagon.dev/blog/higher-raii-7drl https://verdagon.dev/blog/higher-raii-7drl [3] https://verdagon.dev/blog/zero-cost-refs-regions https://verdagon.dev/blog/zero-cost-refs-regions
- cercatrova 4y ago
  Just curious, why isn't Rust doing this currently? And could Rust adopt something similar to Vale's model?
  - gouda-gouda 4y ago
    Rust definitely has a mixture of runtime and static checks (Rc, RefCell, Arc, etc)
  - verdagon 4y ago
    Adding generational references needs to be built into the language at a very deep level to work properly, AFAICT. One can almost do it by using "side tables" but it would come at a rather high performance cost for Rust. Since generations are located inside / next to the object in Vale, we can take advantage of the cache to avoid any significant slowdowns. Additionally, one of the main benefits of this approach is simplicity for the user, and I'm not sure Rust can be made simpler by adding more mechanisms.
bsder 4y ago
> I want a simpler version of Rust. That's perfectly fine. However, without Rust, we cannot get there from here. Say what you will, but Rust is the first language to crack the Linux kernel monolanguage (I don't see Ada in the Linux kernel, for example). That's a good thing as the tooling will then be in place so that RustEasier(tm) doesn't have to go through such a slog to get used in the kernel. People forget that we went through a similar process with Linux on Alpha. The Alpha port cleaned up a lot of the x86-isms that allowed Linux to be ported to other architectures far more easily afterward.
fulafel 4y ago
> Is it possible to create a truly safe language without the dizzying complexity? In Rust the complexity comes from elsewhere (eg rejecting GC), there are lots of easier languages that match the safety. Rust is not really the paragon of safety, its guarantees are similar to easy languages like F# or even Java. And behind Ada.
- biorach 4y ago
  > And behind Ada. https://lwn.net/Articles/908057/ https://lwn.net/Articles/908057/ > The biggest problem of Ada IMO is that it was always supposed to be about safety, but it never addressed the most common source of bugs: pointer safety. Not even with SPARK. It's like discussing about how can you fortify the door in a house with three walls. I suspect they planned to solve it like everyone else (with tracing GC), but that never materialised (because most Ads users don't want tracing GC) thus was always kinda weird “safe” language which doesn't tackle the most common source of bugs. > Finally, in year 2020, it solved that problem. By picking ideas from Rust, of course. > But by that time momentum was lost and it would be very hard to overcome that “safe language without safety” stigma.
  - fulafel 4y ago
    Yep. Borrowing ideas is good and completely ok, as Rust also does copiously, this is how our languages improve. But of course Ada has a lot of other safety features that Rust does not.
pg_1234 4y ago
This is what Rust is ... the simpler, safer alternative to C++. It is possible that, for the demanding domain spaces that have historically required C++, Rust is the end of the line for how far you can dumb down a language and still have the required sophistication and performance.
eggy 4y ago
I feel the same way. I've dove in three or four times on Rust, but I get stuck learning Rust and not producing what I first set out to do in it. Currently, I have committed to learning Zig for my low-level or C-type projects, and I have been having fun. When I need what Rust claims to offer, I drop back to SPARK2014. A formally defined programming language with a set of verification tools. It meets all high integrity standards, and it has been around for a while with some helicopter operational code and the NATS iFACTS air traffic control system with over 500k lines of SPARK code. It's nice to see now that AdaCore is teaming up with Ferrous Systems[0] to try and bring some of this to Rust. It shows the Ada/SPARK community want to propagate high-integrity software and not just promote a PL. As much as I like terse and expressive languages like J or APL or Haskell even, I find SPARK2014 to be more writable, readable, and it covers Rust's domain, even embedded [1]. It's Pascal-like block structure with 'end' delineates the program structure nicely for me, and in my opinion, much easier to follow than Rust. Elixir has sort of won the BEAM PL of choice category (it has 'end' blocks too). I think Rust will only get more complex. A SPARK on BEAM would be something! [1] https://blog.adacore.com/how-to-prevent-drone-crashes-using-spark https://blog.adacore.com/how-to-prevent-drone-crashes-using-... [0] https://blog.adacore.com/adacore-and-ferrous-systems-joining-forces-to-support-rust https://blog.adacore.com/adacore-and-ferrous-systems-joining...
gorilla0 4y ago
I am personally still doubtful of Rust's adoption. I consider the 2008-2014 period the peak hype cycle for Haskell and don't see that it changed professional programming much. I predict it will be similar for Rust.
wink 4y ago
Now I'd be really interested in some examples (names/years) of your simplification of JS tools? theory, because as a semi-interested bystander it doesn't match my experience.
taylodl 4y ago
The funny thing is Rust adds a lot of complexity to solve the main problem it purports to solve: memory management. I spent the first 20 years of my career doing C/C++ development and we were able to "solve" that problem with far less complexity. Rust changed so much in the early days (I really hate the mantra of move fast and break things when it comes to programming languages) that I got tired of all the breaking changes and total disregard for backward compatibility. Which is cool if you're into that sort of thing, but I'm not. Maybe Rust has added more killer features since then warranting the complexity? I really don't know. I'd be interested in hearing are there other reasons for learning Rust other than just memory management? What other problems is Rust solving?
- drogus 4y ago
  I’m genuinly curious - how did you „solve” memory safety issues in C/C++?
  - taylodl 4y ago
    Sorry - got busy over the weekend. In the five different places I worked while using C++ the problem was solved with convention and discipline. When MFC came out it helped standardize memory management best practices and people began following them. Also, auto_ptr<> was a godsend!
npigrounet 4y ago

goodpoint 4y ago

You want Nim.

echelon 4y ago

Writing Rust/Actix for server code is a breeze. There's zero complexity. It's practically Java, just with a more Ruby-like syntax. Entirely depends on what you're building. Edit: You can have a small Actix app up over the weekend and never touch "lifetimes" until you're ready.

andrewstuart 4y ago
After my initial failed attempt to learn Rust I then took a second shot at it by writing Actix web code and had alot more success. This is the path I would take if I was returning to Rust. Having said that, I felt that for the most part this approach was just avoiding the task of learning the complexities. But, I do believe that learning something hard starts by learning a little bit of it and building on that initial foothold.
lossolo 4y ago
> Entirely depends on what you're building. Exactly this, if you are building some CRUD app then it's as easy as using Java or Go etc, because basically there you have request -> contact some db -> return result, maybe do some processing of that data, so no need to fight borrow checker at all. But if you build something like multiplayer game server with lots of state of 3D world that constantly changes and interacts with itself, that is operating on self referencing data structures etc then it's not as easy as in GC language.
brown 4y ago
I could not disagree more. The moment you need to do something remarkably simple, such as string concatenation, you are confronted with the reality that Rust is a much lower level language.
- rascul 4y ago
  In the simplest form, string concatenation is simple. https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f72521a8b1d86acb4b082326c36ec4e1 https://play.rust-lang.org/?version=stable&mode=debug&editio... I usually use concat() though. https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=78337475ece89b199a6249b4b3c90e78 https://play.rust-lang.org/?version=stable&mode=debug&editio...
Thaxll 4y ago
For simple CRUD app maybe, but the moment you start to do anything more complicated, aka manipulating data it's a complete different story.
josephg 4y ago
Part of my work involves the braid HTTP spec. Braid uses a custom server-sent events like protocol sent over long lived HTTP connections. I spent about a week trying to get this working using rust & actix. My code became mired in complex lifetimes, crazy iterators, Pin, async and Futures. Hundreds of lines of code later, I gave up and rewrote the whole thing in an hour or two, in about 30 lines of javascript. The whole experience was so bad I've sworn off using async rust entirely until a few more features land. Thankfully, apparently there GAT lands next release - although its not clear to me if it'll work for futures yet, or if thats a later goal. I love rust. But, wow.
rascul 4y ago
I don't know anything about Java or Ruby but I've tried several rust web frameworks and Actix is the one I always find myself using in the end.

eminence32 4y ago

>I want a simpler version of Rust. Some relevant reading: https://without.boats/blog/revisiting-a-smaller-rust/ https://without.boats/blog/revisiting-a-smaller-rust/

jjtheblunt 4y ago

> I want a simpler version of Rust. C arguably is, considering the analyses done on programs in C are not precluded from being super stringent, perhaps as stringent with compiler-specific flags?

aussiesnack 4y ago

I'm currently learning Rust (as a distinctly average programmer) and I think I agree. I put that so tentatively because I have experienced something of what Rust advocates claim - ie. when I've battled just trying to get a module to work at all for a while, but then when it does fit together (in a rather pleasing way, like gears snicking neatly together), it just continues to work. So I don't rule out the possibility that with more experience the fitting-together experiences will overtop the ugh-this-is-difficult ones, and I will become another Rust enthuser. But on the other hand I'm often driven mad by the complexity, not so much of the language, but the libraries. There are several very popular & foundational ones I've used where I've literally not once managed to get anything working by following the incomprehensible docs, only by chasing up blog and forum posts in the desperate hope of finding a usable snippet. Then there is the community, which despite its reputation for inclusiveness, is insufferably smug (for genuinely pleasant communities, try Elixir or Clojure). If you say something is difficult, they'll just inform you it's not, therefore by implication you must be thick or obtuse.

Cyph0n 4y ago
Out of curiosity, can you share examples of popular libraries that were difficult to get working correctly?
- aussiesnack 4y ago
  One example - clap, which is by far the most commonly recommended cli args parsing library. Plain uses of the derive api are simple enough, but I found it a huge time suck to figure out how to do anything remotely different from the docs' examples. On my first 'real' Rust project, it took nearly half my time just figuring out how to deal with cli args. In retrospect I probably should have either used the Builder api (which is more explicit) or parsed the args manually. But I've experienced similar things repeatedly. Complexity seems to be tolerated (even vaunted) by the Rust dev community at large. I don't rule out that this may have good reasons behind it (the nature of Rust's natural domain, etc).
  - rascul 4y ago

CountSessine 4y ago

I think any language that has the concept of storage classes will be complicated because you have to deal with copy versus move vs borrow semantics. Other languages get around this by just saying that primitives are on the frame and everything else is on the heap. Efficiency has its price.

andrewstuart 4y ago
As I understand it Rust is composed of 5 or 6 sub languages. I find it hard to believe that there's no way to get the benefits of Rust without 5 languages. Why can't a programming language be one language that does everything it needs to do? Seems crazy to me to have 5 or 6 sublanguages.
- kibwen 4y ago
  > As I understand it Rust is composed of 5 or 6 sub languages. Where have you heard this? That's certainly not the case.
- aussiesnack 4y ago
  Not quite sure what you mean by sublanguages - procedural and declarative macros perhaps? In any case I wonder about the simplicity/complexity dance. Simplification ends up with something like Lisp, in which you write DSLs that each has to be independently learned. Elixir does something similar. Some differentiation might just be a natural consequence of chasing ergonomics.
  - woodruffw 4y ago
    If I had to guess: Safe Rust, Unsafe Rust, proc macros, declarative macros, the attribute language, and maybe async Rust (although I'd really just consider this sugar on Safe Rust). I love Rust, but I would love to see more syntactic unification between these components. Both macro languages, in particular.
    - andrewstuart 4y ago

jerf 4y ago

"Is it possible to create a truly safe language without the dizzying complexity?" Yes! The good news is, they even already exist. There's even at least two variants of them: Pure immutable values (Haskell, Erlang) and languages that aren't pure functional but involve lots of little execution units that can't send mutable references between the units (Elixir, Pony) which when used even slightly properly makes unaccounted-for mutation a non-problem. Those are not intended as complete lists, either. I gather Clojure can be used to a large degree this way, for instance. Nor is this a full list of all the possible solutions, just the ones that leap to my mind. The bad news is, the complexity in Rust is still there for a reason. I see the earlier efforts as something like the same picture as Rust is trying to be, but blurred. Immutability and inability to mutate across threads at all both solve the safety problems, but with a bigger hammer and a blunter flattening of the problem space. Technically, Rust's greater complexity allows it to hug the true parameters of the safety problem space more closely. I suspect that tradeoff is fundamental and you can't have Rust's feature set without roughly equivalent complexity. Fortunately, not every language has to be Rust. Fortunately, Rust exists for those times when we really, really need it. There can't be one language to rule them all, and Rust isn't going to fill that nonexistent niche. That's OK. Rust only has to be the best Rust it can be, and those other languages can be the best languages they can be, and in the end that's just as good as it can get. (Also, while this isn't a solution to the safety problem, you can still get a lot of mileage by adopting solutions from those domains into languages that technically unsafe, but work fairly well if you program them with a collection of reasonably safe patterns. I work a lot in Go. It is not particularly safe, technically; safer than C but that's a low, low bar. But in practice I don't have a lot of safety problems with it because I spent years cutting my teeth on Erlang and Haskell and my designs are informed by that.)

resonious 4y ago
Aren't Haskell and Erlang both GC? I don't think anyone is touting Rust as newly immutable. The only differentiator (to my understanding) is Rust's safety without GC.
- mikepurvis 4y ago
  I don't know that that's really the whole story. I mean, C++ has smart pointers that do reference counting, same as Rust's do. But C++ can't provide most of the rest of guarantees that Rust can, like that you didn't hold a reference to that argument, or return a pointer to a local variable that's about to go out of scope, or that these threads aren't both touching that thing at the same time.

xpressvideoz 4y ago

> My theory is that every technology that is too complex gets replaced with something that does the same thing more simply. If what you said was true, JavaScript itself should have been replaced by something simpler, which didn't happen. My theory is that when some technology is good enough, it gets stuck. The previous JavaScript tools got replaced because they were not good enough.

int_19h 4y ago
That doesn't explain why the replacement stuff keeps going in circles so persistently, though.

kibwen 4y ago

Did you bother to read the OP? The thesis is that Rust is actively reducing its own complexity by becoming more self-consistent over time, with fewer arbitrary restrictions about what can be used where.

yyyk 4y ago

Rust is rather lean - you'd have to give up something to simply. e.g. most simpler languages are GC languages. That said, GC shouldn't be a problem for 90% of apps. Now, it's not unlikely that eventually Rust will accrete enough baggage to need replacement too - I'm guessing we have 20 years minimum until that happens?

jjtheblunt 4y ago
It seems like a section of those enthused already left quite publically, maybe a couple years ago, once async was added with that syntax.
- kibwen 4y ago
  I'm not entirely sure what this is referring to? If it's something about Rust's postfix await syntax, it's quite lovely in practice, and even if someone disagreed they wouldn't leave the language over something like that.
  - jjtheblunt 4y ago
    Scanning back over the past couple years, there's plenty of commentary about coloring in async Rust https://hn.algolia.com/?q=rust+async https://hn.algolia.com/?q=rust+async

slurpmaker 4y ago

It's really not that hard. You just need to practice a bit and get over some concepts. Highly recommend buying a rust book to supplement the online rust book, or getting involving the a forum/chatroom and asking questions. The community realizes it's a bit of a brain shock, but once you get over it, it's actually pretty easy to do 99% of the things you need to do. Even, easier than in other languages in a lot of cases. A few areas are tricky/hard, but if you walk before you run (which most people SHOULD do in other languages) it's entirely doable. The problem with an easier rust is... These are the rules for using your computer safely. Like, this is what you should be doing when reading/writing C code. Or C++. So learning rust is hard, but it makes you a better programmer faster IMO. Also... once you write rust code it's usually good, no weird surprises Saturday at 2:00am in production, it's just done and works. Anyway wishing you the best, but be careful asking for "an easier rust". An easier "Rust" probably isn't safe and you might as well just be writing any other language.

webkike 4y ago

If this is the case, why hasn’t math been replaced?

kccqzy 4y ago
Parts of math have been replaced. The original Maxwell's equations were replaced since the new ones were much simpler.
- webkike 4y ago
  What part of rust do you think can be made simpler?

lumost 4y ago

The main advantage of rust is that you can “do anything” with it. It’s fast, it has deterministic performance, you can embed it, you can write low level code, you can write fancy high level code. Cpp devs never moved because there were always large projects chugging along in cpp and they always had the feeling that they knew what they were doing.

nu11ptr 4y ago

This exactly how I felt the first two times I tried it, but I never really just dove in. The third time I just dove in. The learning curve is straight up, but once you are over (took me about a month), Rust isn't really all that hard. I can write it as fast as I can write Python typically, so that friction you probably feel will go away...entirely. Sure, there are a few corner cases where the type system gets hard and the more you care about every cycle of performance the more of those you have, but if you are just looking to code Rust as a high level language, it really isn't that hard. Knowing that everything is likely to work when it compiles is really good feeling too. Tips/Concepts: - Form a mental model of the rules/memory model of the language, this will help you get to an understanding, and once you understand you don't have to remember the rules.. you could write them yourself. - The analogy I used to understand borrowing: it is like a read/write lock. Any data structure can be read any number of times (&), but it can only be written once at a time (&mut) - Borrowing "locks" the position of the data structure and this is one of my favorite features. Imagine you have a reference to the middle of a data structure and then it suddenly moves... this can't happen in Rust as borrows "lock" the struct from moving - Lifetimes aren't magic and you are in no way defining the lifetimes themselves with lifetime annotations. All you are doing is helping the compiler see which references are backed by what values already. Once you understand which these are lifetimes become easy. - Eventually you will have an aha moment.. and you will wonder what was so hard. You will have to think about memory in a lower level way, but only to learn it, after that it is just natural

aussiesnack 4y ago
> Rust isn't really all that hard. You don't find it hard. Many do.
- kibwen 4y ago
  Yes, Rust is quite different from typical languages thanks to ownership and borrowing. It often takes people several attempts to learn it before their perspective shifts and it finally clicks for them. But this perception of Rust has less to do with Rust being "hard" than it has to do with Rust being "different". To be sure, Rust has hard parts even after you've internalized the differences, but IMO by that point it's not substantially different from mastering the hard parts of other languages (especially other systems languages, none of whom can get away with entirely sweeping the details of the machine under the rug).

rascul 4y ago

I'm just a hobby coder. Except for lifetimes and a bit of fighting with the borrow checker, the language came fairly easily for me. After banging my head against the borrow checker for a week or two at some point something switched in my brain and all of a sudden I wasn't fighting the borrow checker anymore. This was spending maybe 1-2 hours a day with rust. I don't often have a lot of time to write code. Everyone has their own experiences, though, and this is just mine.

deleted 4y ago

[deleted]

jasfi 4y ago

That's Nim.

azakai 4y ago

> I wonder if there is a subset of Rust that can be extracted someone into a new, minimal language with the core benefits. That is basically what Val aims to do: https://www.val-lang.dev/ https://www.val-lang.dev/ It has Rust-style ownership to guarantee memory safety, but without the complexity of lifetimes. There is still a borrow-checker-like component, but I believe it should be much simpler than Rust's (see e.g. "method bundles" and how they are called). Still in the research phase. It is an open question how well this approach scales.

verdagon 4y ago

Good news! Complexity isn't a baseline requirement: it's possible to make a language that has the basic patterns and benefits of an average Rust program. It's what we're doing in Vale [0]. It turns out, they key is to move some checks to run-time [1] to reduce complexity, move other checks instead to compile-time [2] where it doesn't increase complexity, and then make the borrow checker "opt-in" instead of forcing it to be used everywhere [3]. [0] https://vale.dev/ https://vale.dev/ [1] https://verdagon.dev/blog/generational-references https://verdagon.dev/blog/generational-references [2] https://verdagon.dev/blog/higher-raii-7drl https://verdagon.dev/blog/higher-raii-7drl [3] https://verdagon.dev/blog/zero-cost-refs-regions https://verdagon.dev/blog/zero-cost-refs-regions

cercatrova 4y ago
Just curious, why isn't Rust doing this currently? And could Rust adopt something similar to Vale's model?
- gouda-gouda 4y ago
  Rust definitely has a mixture of runtime and static checks (Rc, RefCell, Arc, etc)
- verdagon 4y ago
  Adding generational references needs to be built into the language at a very deep level to work properly, AFAICT. One can almost do it by using "side tables" but it would come at a rather high performance cost for Rust. Since generations are located inside / next to the object in Vale, we can take advantage of the cache to avoid any significant slowdowns. Additionally, one of the main benefits of this approach is simplicity for the user, and I'm not sure Rust can be made simpler by adding more mechanisms.

bsder 4y ago

> I want a simpler version of Rust. That's perfectly fine. However, without Rust, we cannot get there from here. Say what you will, but Rust is the first language to crack the Linux kernel monolanguage (I don't see Ada in the Linux kernel, for example). That's a good thing as the tooling will then be in place so that RustEasier(tm) doesn't have to go through such a slog to get used in the kernel. People forget that we went through a similar process with Linux on Alpha. The Alpha port cleaned up a lot of the x86-isms that allowed Linux to be ported to other architectures far more easily afterward.

fulafel 4y ago

> Is it possible to create a truly safe language without the dizzying complexity? In Rust the complexity comes from elsewhere (eg rejecting GC), there are lots of easier languages that match the safety. Rust is not really the paragon of safety, its guarantees are similar to easy languages like F# or even Java. And behind Ada.

biorach 4y ago
> And behind Ada. https://lwn.net/Articles/908057/ https://lwn.net/Articles/908057/ > The biggest problem of Ada IMO is that it was always supposed to be about safety, but it never addressed the most common source of bugs: pointer safety. Not even with SPARK. It's like discussing about how can you fortify the door in a house with three walls. I suspect they planned to solve it like everyone else (with tracing GC), but that never materialised (because most Ads users don't want tracing GC) thus was always kinda weird “safe” language which doesn't tackle the most common source of bugs. > Finally, in year 2020, it solved that problem. By picking ideas from Rust, of course. > But by that time momentum was lost and it would be very hard to overcome that “safe language without safety” stigma.
- fulafel 4y ago
  Yep. Borrowing ideas is good and completely ok, as Rust also does copiously, this is how our languages improve. But of course Ada has a lot of other safety features that Rust does not.

pg_1234 4y ago

This is what Rust is ... the simpler, safer alternative to C++. It is possible that, for the demanding domain spaces that have historically required C++, Rust is the end of the line for how far you can dumb down a language and still have the required sophistication and performance.

eggy 4y ago

I feel the same way. I've dove in three or four times on Rust, but I get stuck learning Rust and not producing what I first set out to do in it. Currently, I have committed to learning Zig for my low-level or C-type projects, and I have been having fun. When I need what Rust claims to offer, I drop back to SPARK2014. A formally defined programming language with a set of verification tools. It meets all high integrity standards, and it has been around for a while with some helicopter operational code and the NATS iFACTS air traffic control system with over 500k lines of SPARK code. It's nice to see now that AdaCore is teaming up with Ferrous Systems[0] to try and bring some of this to Rust. It shows the Ada/SPARK community want to propagate high-integrity software and not just promote a PL. As much as I like terse and expressive languages like J or APL or Haskell even, I find SPARK2014 to be more writable, readable, and it covers Rust's domain, even embedded [1]. It's Pascal-like block structure with 'end' delineates the program structure nicely for me, and in my opinion, much easier to follow than Rust. Elixir has sort of won the BEAM PL of choice category (it has 'end' blocks too). I think Rust will only get more complex. A SPARK on BEAM would be something! [1] https://blog.adacore.com/how-to-prevent-drone-crashes-using-spark https://blog.adacore.com/how-to-prevent-drone-crashes-using-... [0] https://blog.adacore.com/adacore-and-ferrous-systems-joining-forces-to-support-rust https://blog.adacore.com/adacore-and-ferrous-systems-joining...

gorilla0 4y ago

I am personally still doubtful of Rust's adoption. I consider the 2008-2014 period the peak hype cycle for Haskell and don't see that it changed professional programming much. I predict it will be similar for Rust.

wink 4y ago

Now I'd be really interested in some examples (names/years) of your simplification of JS tools? theory, because as a semi-interested bystander it doesn't match my experience.

taylodl 4y ago

The funny thing is Rust adds a lot of complexity to solve the main problem it purports to solve: memory management. I spent the first 20 years of my career doing C/C++ development and we were able to "solve" that problem with far less complexity. Rust changed so much in the early days (I really hate the mantra of move fast and break things when it comes to programming languages) that I got tired of all the breaking changes and total disregard for backward compatibility. Which is cool if you're into that sort of thing, but I'm not. Maybe Rust has added more killer features since then warranting the complexity? I really don't know. I'd be interested in hearing are there other reasons for learning Rust other than just memory management? What other problems is Rust solving?

drogus 4y ago
I’m genuinly curious - how did you „solve” memory safety issues in C/C++?
- taylodl 4y ago
  Sorry - got busy over the weekend. In the five different places I worked while using C++ the problem was solved with convention and discipline. When MFC came out it helped standardize memory management best practices and people began following them. Also, auto_ptr<> was a godsend!

npigrounet 4y ago