10 ms·

Maybe I'm the only one, but I have a very hard time grasping all the functionality/concepts offered by Rust. I really like the safety guarantees offered at com

Maybe I'm the only one, but I have a very hard time grasping all the functionality/concepts offered by Rust. I really like the safety guarantees offered at compile time, and really do think that we should move away from C-like languages if we ever want to control the tsunami of security flaws, but I can't stop wondering if Rust isn't (perhaps needlessly) complicating things and scaring off (non-C++) programmers.

wtetzner 7y ago
What are the concepts you have trouble with?
nicoburns 7y ago
Have you read the Rust book? I came to Rust from JavaScript, having never written more than "hello world" in C++ and found it pretty approachable.
zengid 7y ago
I don't think you're alone in being put off by the complexity of the language. I think once you get over the hump things start to click. The mindset that has helped me is to say, "Ok, this syntax might sometimes look familiar, but this language is COMPLETELY DIFFERENT from anything else I know, so I can't use my usual metaphors/analogies and need to use a clean slate". Then you can look at things like Ownership, Traits, and Pattern Matching and see how the whole language is built up around a few key ideas (with a lot of subtle variations) and then it might start to click. You need to give it a lot of time. Some of the ideas are really not familiar. I don't think Rust presents some of the ideas perfectly, but I can imagine that in 20 years there might be a whole slew of languages that borrowed ideas from rust and maybe make them appear more idiomatic.
- vthriller 7y ago
  > this language is COMPLETELY DIFFERENT from anything else I know Rust itself borrows a lot from functional programming while also topping the story with lesser-known things like lifetimes, so no wonder it feels alien to a lot of people. In fact, the following: > I can imagine that in 20 years there might be a whole slew of languages that borrowed ideas from rust is actually already happening, except it's FP that's inspiring contemporary language designers (including Rust team). To me personally even limited familiarity with Haskell probably helped a lot back when I started tinkering with Rust, it all felt more familiar to me than to average C or Python dev.
nikolay 7y ago
Try the Rust track: https://exercism.io/tracks/rust https://exercism.io/tracks/rust
jug 7y ago
I can’t help but find it a bit like an academic project; a proof of concept. I suppose the complexity of it is warranted to help both you and the compiler from acknowledging unsafe code and get better error messages, so maybe the question is not whether Rust needs to be like this, but whether I as a developer need Rust.
pjmlp 7y ago
If someone can do systems programming with FreePascal/Delphi, Modula-3, .NET Native, D, Swift, Ada,... They will be almost at home with Rust. The biggest hurdle is dealing with the borrow checker when writing GUI code (hello Rc<RefCell<T>>), but for other kind of applications it is quite ok. Also it speaks a lot that Ada, C++, Swift are adopting the same ideas regarding the borrow checker, even if implementation has some constraints given backwards compatibility.
- stochastic_monk 7y ago
  In what way do you think C++ is borrowing the idea of a borrow-checker? Smart pointers pre-date Rust.
  - pjmlp 7y ago
    Visual Studio and clang are introducing a borrow checker in their static analysis tools. If you leave it on as part of the build you get an similar experience (note on similar, they aren't bullet proof due to language semantics). There are a couple of conference talks about them. Naturally smart pointers predate Rust, I used them back when Windows 3.1 was considered recent, alongside OWL. However they aren't the same thing, introduce runtime overhead and don't prevent use-after-free, or use-after-move.
    - stochastic_monk 7y ago
      That makes more sense, though not actually part of the language. Smart pointers were the only thing close that came to mind for that reason. I’ve used the Clang experimental lifetime analyzer on Godbolt, and I welcome improved tooling.
    - yakubin 7y ago
      One thing about static analysis tools that seems to be easily forgotten about in discussions about rust vs other languages is that those tools are trivially ignorable. If your CI pipeline doesn't let you get a binary for a given milestone, because the code doesn't pass static analysis, unit/integration tests etc. people will just disable it for myriads of reasons not the least of which will be "management wanted it to be done by yesterday and it compiles, so it's probably ok", "it's probably false positives again [yeah, right...]", "this is the test that fails from time to time, it's probably nothing". A compilation error is a much better protection from the social pitfalls of programming in a corporate environment. So yup, you have all those wonderful tools at your disposal in the C/C++ which I guarantee you will ignore or be forced to ignore at your peril.
pdpi 7y ago
Your comment prompted me to look at Rust's release history. In the whole of the history, I can spot maybe a handful of changes that made the language non-trivially harder for a beginner. Everything else either makes the language easier (by making things more predictable), or is a net neutral. Most of the language-level changes are about enabling current features to work in more scenarios, such that coming across new features tends to feel more like "oh I hadn't realised I could do this" than "what does syntax thing mean?"
0815test 7y ago
Rust is a lot simpler than C++. Broadly speaking. the only 'complications' it has over C are those that are actually needed to support its patterns of memory-safety-guarantees-through-RAII. The only real alternative is GC languages, and those have their own sorts of very real complications that do absolutely scare off performance-oriented folks. The biggest problem with Rust right now is actually its novelty and lack of maturity, that makes using it at this time a lot more problematic than it should be. But Java and Python were once "new and unproven" languages, too.
- pjmlp 7y ago
  While I agree in general, just wanted to make the heads up that not all GC enable languages are made alike and a couple of them do allow for C style low level programming. Usually the performance folks that get scared are the ones that put all of them into the same basket.
- ahartmetz 7y ago
  There is certainly much more accumulated cruft in C++, but you can write your C++ program ignoring most of it. You will have to deal with some of Rust's harder parts rather soon.
  - roca 7y ago
    You can write a C++ program ignoring most of it, but when you go to work on someone else's C++ program, or import someone else's C++ code (i.e. most real-world programming) you will have to deal with it. And when you're not working alone you will spend a lot of energy discussing which C++ subset you will use, and enforcing that.
- blub 7y ago
  C++ has accumulated complexity over decades, and the committee is working on making things easier for beginners. Usually it works, mine-fields like string_view aside. Rust has accumulated its complexity over four years, and it's already comparable to C++. The thing that worries me the most about Rust, is how the language will look like in another 10 years.
mamcx 7y ago
This >I have a very hard time grasping all the functionality/concepts is (partially) because this > if we ever want to control the tsunami of security flaws Most focus in how the borrow checker work "against" you but that is not even the harder. Performance and how manage memory are more "painfull" in rust. BECAUSE NOBODY KNOW HOW DO FAST & SAFE CODE. Not ALL the time. Without extra help of the compiler your assumptions can get wrong in invisible ways... Rust WANNA: - See what is costly - See what is unsafe or not - See what own what - See what is on heap or stack The borrow checker is just a part of it. From https://this-week-in-rust.org/blog/2019/07/02/this-week-in-rust-293/ https://this-week-in-rust.org/blog/2019/07/02/this-week-in-r... Python and Go pick up your trash for you. C lets you litter everywhere, but throws a fit when it steps on your banana peel. Rust slaps you and demands that you clean up after yourself. – Nicholas Hahn
- hu3 7y ago
  > Python and Go pick up your trash for you. > C lets you litter everywhere, but throws a fit when it steps on your banana peel. > Rust slaps you and demands that you clean up after yourself. > – Nicholas Hahn This is brilliant and will save me time explaining language differences. Thanks for sharing.
  - kbenson 7y ago
    Python and Go pick up your trash for you, but sometimes they get in your way while they do so. If you generate a lot of trash, you might find yourself stopped quite often. C lets you litter everywhere, but if you or anyone else steps on your trash it will tackle you to the ground. Usually. Sometimes it ignores the first 10 times and does it on the eleventh. Rust snatches up your trash as soon as you're done with it, but if it can't reason well about when you'll be done using it, it will make you fill out a form explaining how you plan to use it. It will also slap you silly if you try to deviate from that plan.
baq 7y ago
Rust makes you think about certain things that you should be thinking about anyway when coding in C/C++ but sometimes forget about it. IMHO this makes it easier for someone who's never programmed in C/C++ to learn Rust than for a veteran in either of these - unless that person adhered religiously to certain rules of handling pointers.
m12k 7y ago
I mean, C++ programmers are exactly the correct audience for a language like this - there are many other options for memory safety if you can live with a garbage collector[1]. But writing safe C++ is much, much, much more complex than than writing okay-ish C++. The way I see it, Rust has basically taken a lot of the best practices required to write sane C++ (e.g. RAII) and formalized them in a way where the compiler can enforce them. That means in order to write ANY Rust code at all, you have to adapt a lot of best practices all at once. That's not very beginner friendly, and will probably lead to cognitive overload in most - you certainly don't get the same freedom you get in other languages where you can implement something in dozens of ways, because most of those ways won't compile here. So I'm not saying they shouldn't keep working on the ergonomics and learnability of the language, but I think a lot of these complexities are essential to the task of writing sane programs while dealing with raw memory, and the fact that they have been named, formalized and checked by the compiler is entirely a good thing - and if that means the programmer has to know about them, then that's ok. [1] Sidenote - I find it really fascinating how Rust can also use the stronger static checks to prevent things like race conditions in a way few (/no?) other languages can.
- pjmlp 7y ago
  Thing is many of Rust features could probably be enforced with a static analysis tool, which a large majority unfortunately ignores. So you either have a C++ shop where everyone is on board regarding security, with the caveat of third party dependencies, or no one cares and writes something along the lines of C with C++ compiler, without any kind of static analysis. Relying on external tooling means it usually gets ignored if it is not enforced. After all C's first version of lint goes back to 1979. Sadly JetBrains latest questionnaire results prove exactly that. So having safety as integral part of the language semantics matters a lot. Defaults matter.
  - staticassertion 7y ago
    > Thing is many of Rust features could probably be enforced with a static analysis tool, which a large majority unfortunately ignores. But it definitely can't be? There are plenty of open source projects (Chromium, Firefox) that develop and leverage state of the art static analysis tools and best practices. It's very clearly not enough, and the costs (built/ test time) are really significant.
alex_duf 7y ago
As much as I like the language I actually don't think it's for everyone. If your program is running on the server reading from a DB and producing simple JSON (like I assume most of HN's audience), rust is probably not what you want. There's plenty of more pragmatic approaches. At least I think it's not the right language for my employer's department (and it pains me to say that) If what you want is to write code that runs on bare metal then consider Rust
- Const-me 7y ago
  > If what you want is to write code that runs on bare metal then consider Rust The closest I was to bare metal, i.e. code that works without an OS, when I developed stuff for “small” MCUs, like Intel MCS51, Motorola COP8. Rust supports none of them: https://forge.rust-lang.org/platform-support.html https://forge.rust-lang.org/platform-support.html I’ve developed for Nintendo Wii, nominally there’s an OS but it’s very “thin” one, mostly statically linked libraries provided by Nintendo. Rust can’t compile for that platform either, it only supports PowerPC Linux. I’m currently working on low-level software working on bare Linux kernel. Rust apparently supports ARM Linux, but C libraries are literally everywhere, both kernel APIs and user mode: drm, kms, gles, udev, freetype, low-level kernel stuff like tons of ioctl calls for SPI and USB I/O, wpa_supplicant, and more. That’s too much native C stuff to integrate together, using a foreign language causes too much friction. I can think of bare metal software for which Rust is good. If I would work on x86 bare metal hypervisor, I would look at Rust very closely. Platform support is good, not much libraries are needed, and the project is extremely security sensitive so using Rust will probably pay off in the long run. But I don’t think that’s a rule, looks like an exception to me.
  - alex_duf 7y ago
    I guess this shows my ignorance of low level computing! I used "bare metal" wrong even though Rust can do it. I wanted to point at a lower abstraction level than a typical corporate application, but higher than bare metal. Something just above the OS, like any command line.
  - roca 7y ago
gameswithgo 7y ago
while it would be nice to have a simple, C like language, with memory safety, but without GC, it may not be possible. Some of the complexity of Rust is to help deal with life of borrow checker land. There are some middle ground options though, like Zig, which is a nice simple C like language with less undefined behavior and no nulls. so safer, but not offering memory safety.
- Rusky 7y ago
  There is a lot of unexplored wiggle room in the design of borrow checking that might get closer to what you want. For example, Rust puts &T and &mut T at the forefront, which leads to a slightly alien way of handling aliasing- it's all or nothing. This makes some things feel way harder than they are in C, but helps out the optimizer (every pointer is now restrict/noalias). A different language could emphasize (the equivalent of) &Cell<T>, which allows shared mutability but restricts certain "shape changing" mutations. Most of those C patterns would feel easy again, with a bit less of Rust's non-safety-essential guarantees.
  - 0815test 7y ago
    Cell<T> (1) is not safe to reference across threads, and (2) can only mutate via the equivalent of a memcpy. It can be useful in many ways, but there is a real sense in which &T and &mut T (which would probably be called &uniq T, if Rust devs cared about theoretical cleanness over reusing short keywords!) are truly fundamental.
    - Rusky 7y ago
      Point 2 is only a limitation of the current standard library, not of the language-level model. It has even been relaxed recently, so you can go from a &Cell<[T]> to a &[Cell<T>]: https://github.com/rust-lang/rust/pull/61620 https://github.com/rust-lang/rust/pull/61620 The same could be done for struct fields if the type system knew about it, and the whole thing could just use normal syntax. Sharing between threads still needs &T or &mut T (or an owned value), but that's not usually involved in the painful cases.
staticassertion 7y ago
Your post is kind of vague. Rust was hard to grasp, and then I learned it, and now it isn't. I don't find anything about the language to be particularly more complex than, say, Python or C++.
OrangeManBad 7y ago
As someone who's definitely not a 'fanboy' of Rust (and also has an advanced degree in CS) I assure you- no. Rust isn't needlessly complex- it does the bare minimum in most cases.
hector_villa 7y ago
>complicating things and scaring off (non-C++) programmers. On the contrary, Rust allow us (non C++ programmers) to use a system language without fear of breaking something. I'm a Rust developer with Ruby background and loving the language more and more.
- ngrilly 7y ago
  Did you have background with languages other than Ruby before starting with Rust? Languages like C++, D, Haskell, OCaml or maybe C#?
Aardappel 7y ago
It is definitely possible to have Rust's compile time lifetime analysis while having a less complicated language that mostly deals memory automatically: https://aardappel.github.io/lobster/memory_management.html https://aardappel.github.io/lobster/memory_management.html

wtetzner 7y ago

What are the concepts you have trouble with?

nicoburns 7y ago

Have you read the Rust book? I came to Rust from JavaScript, having never written more than "hello world" in C++ and found it pretty approachable.

zengid 7y ago

I don't think you're alone in being put off by the complexity of the language. I think once you get over the hump things start to click. The mindset that has helped me is to say, "Ok, this syntax might sometimes look familiar, but this language is COMPLETELY DIFFERENT from anything else I know, so I can't use my usual metaphors/analogies and need to use a clean slate". Then you can look at things like Ownership, Traits, and Pattern Matching and see how the whole language is built up around a few key ideas (with a lot of subtle variations) and then it might start to click. You need to give it a lot of time. Some of the ideas are really not familiar. I don't think Rust presents some of the ideas perfectly, but I can imagine that in 20 years there might be a whole slew of languages that borrowed ideas from rust and maybe make them appear more idiomatic.

vthriller 7y ago
> this language is COMPLETELY DIFFERENT from anything else I know Rust itself borrows a lot from functional programming while also topping the story with lesser-known things like lifetimes, so no wonder it feels alien to a lot of people. In fact, the following: > I can imagine that in 20 years there might be a whole slew of languages that borrowed ideas from rust is actually already happening, except it's FP that's inspiring contemporary language designers (including Rust team). To me personally even limited familiarity with Haskell probably helped a lot back when I started tinkering with Rust, it all felt more familiar to me than to average C or Python dev.

nikolay 7y ago

Try the Rust track: https://exercism.io/tracks/rust https://exercism.io/tracks/rust

jug 7y ago

I can’t help but find it a bit like an academic project; a proof of concept. I suppose the complexity of it is warranted to help both you and the compiler from acknowledging unsafe code and get better error messages, so maybe the question is not whether Rust needs to be like this, but whether I as a developer need Rust.

pjmlp 7y ago

If someone can do systems programming with FreePascal/Delphi, Modula-3, .NET Native, D, Swift, Ada,... They will be almost at home with Rust. The biggest hurdle is dealing with the borrow checker when writing GUI code (hello Rc<RefCell<T>>), but for other kind of applications it is quite ok. Also it speaks a lot that Ada, C++, Swift are adopting the same ideas regarding the borrow checker, even if implementation has some constraints given backwards compatibility.

stochastic_monk 7y ago
In what way do you think C++ is borrowing the idea of a borrow-checker? Smart pointers pre-date Rust.
- pjmlp 7y ago
  Visual Studio and clang are introducing a borrow checker in their static analysis tools. If you leave it on as part of the build you get an similar experience (note on similar, they aren't bullet proof due to language semantics). There are a couple of conference talks about them. Naturally smart pointers predate Rust, I used them back when Windows 3.1 was considered recent, alongside OWL. However they aren't the same thing, introduce runtime overhead and don't prevent use-after-free, or use-after-move.
  - stochastic_monk 7y ago
    That makes more sense, though not actually part of the language. Smart pointers were the only thing close that came to mind for that reason. I’ve used the Clang experimental lifetime analyzer on Godbolt, and I welcome improved tooling.
  - yakubin 7y ago
    One thing about static analysis tools that seems to be easily forgotten about in discussions about rust vs other languages is that those tools are trivially ignorable. If your CI pipeline doesn't let you get a binary for a given milestone, because the code doesn't pass static analysis, unit/integration tests etc. people will just disable it for myriads of reasons not the least of which will be "management wanted it to be done by yesterday and it compiles, so it's probably ok", "it's probably false positives again [yeah, right...]", "this is the test that fails from time to time, it's probably nothing". A compilation error is a much better protection from the social pitfalls of programming in a corporate environment. So yup, you have all those wonderful tools at your disposal in the C/C++ which I guarantee you will ignore or be forced to ignore at your peril.

pdpi 7y ago

Your comment prompted me to look at Rust's release history. In the whole of the history, I can spot maybe a handful of changes that made the language non-trivially harder for a beginner. Everything else either makes the language easier (by making things more predictable), or is a net neutral. Most of the language-level changes are about enabling current features to work in more scenarios, such that coming across new features tends to feel more like "oh I hadn't realised I could do this" than "what does syntax thing mean?"

0815test 7y ago

Rust is a lot simpler than C++. Broadly speaking. the only 'complications' it has over C are those that are actually needed to support its patterns of memory-safety-guarantees-through-RAII. The only real alternative is GC languages, and those have their own sorts of very real complications that do absolutely scare off performance-oriented folks. The biggest problem with Rust right now is actually its novelty and lack of maturity, that makes using it at this time a lot more problematic than it should be. But Java and Python were once "new and unproven" languages, too.

pjmlp 7y ago
While I agree in general, just wanted to make the heads up that not all GC enable languages are made alike and a couple of them do allow for C style low level programming. Usually the performance folks that get scared are the ones that put all of them into the same basket.
ahartmetz 7y ago
There is certainly much more accumulated cruft in C++, but you can write your C++ program ignoring most of it. You will have to deal with some of Rust's harder parts rather soon.
- roca 7y ago
  You can write a C++ program ignoring most of it, but when you go to work on someone else's C++ program, or import someone else's C++ code (i.e. most real-world programming) you will have to deal with it. And when you're not working alone you will spend a lot of energy discussing which C++ subset you will use, and enforcing that.
blub 7y ago
C++ has accumulated complexity over decades, and the committee is working on making things easier for beginners. Usually it works, mine-fields like string_view aside. Rust has accumulated its complexity over four years, and it's already comparable to C++. The thing that worries me the most about Rust, is how the language will look like in another 10 years.

mamcx 7y ago

This >I have a very hard time grasping all the functionality/concepts is (partially) because this > if we ever want to control the tsunami of security flaws Most focus in how the borrow checker work "against" you but that is not even the harder. Performance and how manage memory are more "painfull" in rust. BECAUSE NOBODY KNOW HOW DO FAST & SAFE CODE. Not ALL the time. Without extra help of the compiler your assumptions can get wrong in invisible ways... Rust WANNA: - See what is costly - See what is unsafe or not - See what own what - See what is on heap or stack The borrow checker is just a part of it. From https://this-week-in-rust.org/blog/2019/07/02/this-week-in-rust-293/ https://this-week-in-rust.org/blog/2019/07/02/this-week-in-r... Python and Go pick up your trash for you. C lets you litter everywhere, but throws a fit when it steps on your banana peel. Rust slaps you and demands that you clean up after yourself. – Nicholas Hahn

hu3 7y ago
> Python and Go pick up your trash for you. > C lets you litter everywhere, but throws a fit when it steps on your banana peel. > Rust slaps you and demands that you clean up after yourself. > – Nicholas Hahn This is brilliant and will save me time explaining language differences. Thanks for sharing.
- kbenson 7y ago
  Python and Go pick up your trash for you, but sometimes they get in your way while they do so. If you generate a lot of trash, you might find yourself stopped quite often. C lets you litter everywhere, but if you or anyone else steps on your trash it will tackle you to the ground. Usually. Sometimes it ignores the first 10 times and does it on the eleventh. Rust snatches up your trash as soon as you're done with it, but if it can't reason well about when you'll be done using it, it will make you fill out a form explaining how you plan to use it. It will also slap you silly if you try to deviate from that plan.

baq 7y ago

Rust makes you think about certain things that you should be thinking about anyway when coding in C/C++ but sometimes forget about it. IMHO this makes it easier for someone who's never programmed in C/C++ to learn Rust than for a veteran in either of these - unless that person adhered religiously to certain rules of handling pointers.

m12k 7y ago

I mean, C++ programmers are exactly the correct audience for a language like this - there are many other options for memory safety if you can live with a garbage collector[1]. But writing safe C++ is much, much, much more complex than than writing okay-ish C++. The way I see it, Rust has basically taken a lot of the best practices required to write sane C++ (e.g. RAII) and formalized them in a way where the compiler can enforce them. That means in order to write ANY Rust code at all, you have to adapt a lot of best practices all at once. That's not very beginner friendly, and will probably lead to cognitive overload in most - you certainly don't get the same freedom you get in other languages where you can implement something in dozens of ways, because most of those ways won't compile here. So I'm not saying they shouldn't keep working on the ergonomics and learnability of the language, but I think a lot of these complexities are essential to the task of writing sane programs while dealing with raw memory, and the fact that they have been named, formalized and checked by the compiler is entirely a good thing - and if that means the programmer has to know about them, then that's ok. [1] Sidenote - I find it really fascinating how Rust can also use the stronger static checks to prevent things like race conditions in a way few (/no?) other languages can.

pjmlp 7y ago
Thing is many of Rust features could probably be enforced with a static analysis tool, which a large majority unfortunately ignores. So you either have a C++ shop where everyone is on board regarding security, with the caveat of third party dependencies, or no one cares and writes something along the lines of C with C++ compiler, without any kind of static analysis. Relying on external tooling means it usually gets ignored if it is not enforced. After all C's first version of lint goes back to 1979. Sadly JetBrains latest questionnaire results prove exactly that. So having safety as integral part of the language semantics matters a lot. Defaults matter.
- staticassertion 7y ago
  > Thing is many of Rust features could probably be enforced with a static analysis tool, which a large majority unfortunately ignores. But it definitely can't be? There are plenty of open source projects (Chromium, Firefox) that develop and leverage state of the art static analysis tools and best practices. It's very clearly not enough, and the costs (built/ test time) are really significant.

alex_duf 7y ago

As much as I like the language I actually don't think it's for everyone. If your program is running on the server reading from a DB and producing simple JSON (like I assume most of HN's audience), rust is probably not what you want. There's plenty of more pragmatic approaches. At least I think it's not the right language for my employer's department (and it pains me to say that) If what you want is to write code that runs on bare metal then consider Rust

Const-me 7y ago
> If what you want is to write code that runs on bare metal then consider Rust The closest I was to bare metal, i.e. code that works without an OS, when I developed stuff for “small” MCUs, like Intel MCS51, Motorola COP8. Rust supports none of them: https://forge.rust-lang.org/platform-support.html https://forge.rust-lang.org/platform-support.html I’ve developed for Nintendo Wii, nominally there’s an OS but it’s very “thin” one, mostly statically linked libraries provided by Nintendo. Rust can’t compile for that platform either, it only supports PowerPC Linux. I’m currently working on low-level software working on bare Linux kernel. Rust apparently supports ARM Linux, but C libraries are literally everywhere, both kernel APIs and user mode: drm, kms, gles, udev, freetype, low-level kernel stuff like tons of ioctl calls for SPI and USB I/O, wpa_supplicant, and more. That’s too much native C stuff to integrate together, using a foreign language causes too much friction. I can think of bare metal software for which Rust is good. If I would work on x86 bare metal hypervisor, I would look at Rust very closely. Platform support is good, not much libraries are needed, and the project is extremely security sensitive so using Rust will probably pay off in the long run. But I don’t think that’s a rule, looks like an exception to me.
- alex_duf 7y ago
  I guess this shows my ignorance of low level computing! I used "bare metal" wrong even though Rust can do it. I wanted to point at a lower abstraction level than a typical corporate application, but higher than bare metal. Something just above the OS, like any command line.
- roca 7y ago

gameswithgo 7y ago

while it would be nice to have a simple, C like language, with memory safety, but without GC, it may not be possible. Some of the complexity of Rust is to help deal with life of borrow checker land. There are some middle ground options though, like Zig, which is a nice simple C like language with less undefined behavior and no nulls. so safer, but not offering memory safety.

Rusky 7y ago
There is a lot of unexplored wiggle room in the design of borrow checking that might get closer to what you want. For example, Rust puts &T and &mut T at the forefront, which leads to a slightly alien way of handling aliasing- it's all or nothing. This makes some things feel way harder than they are in C, but helps out the optimizer (every pointer is now restrict/noalias). A different language could emphasize (the equivalent of) &Cell<T>, which allows shared mutability but restricts certain "shape changing" mutations. Most of those C patterns would feel easy again, with a bit less of Rust's non-safety-essential guarantees.
- 0815test 7y ago
  Cell<T> (1) is not safe to reference across threads, and (2) can only mutate via the equivalent of a memcpy. It can be useful in many ways, but there is a real sense in which &T and &mut T (which would probably be called &uniq T, if Rust devs cared about theoretical cleanness over reusing short keywords!) are truly fundamental.
  - Rusky 7y ago
    Point 2 is only a limitation of the current standard library, not of the language-level model. It has even been relaxed recently, so you can go from a &Cell<[T]> to a &[Cell<T>]: https://github.com/rust-lang/rust/pull/61620 https://github.com/rust-lang/rust/pull/61620 The same could be done for struct fields if the type system knew about it, and the whole thing could just use normal syntax. Sharing between threads still needs &T or &mut T (or an owned value), but that's not usually involved in the painful cases.

staticassertion 7y ago

Your post is kind of vague. Rust was hard to grasp, and then I learned it, and now it isn't. I don't find anything about the language to be particularly more complex than, say, Python or C++.

OrangeManBad 7y ago

As someone who's definitely not a 'fanboy' of Rust (and also has an advanced degree in CS) I assure you- no. Rust isn't needlessly complex- it does the bare minimum in most cases.

hector_villa 7y ago

>complicating things and scaring off (non-C++) programmers. On the contrary, Rust allow us (non C++ programmers) to use a system language without fear of breaking something. I'm a Rust developer with Ruby background and loving the language more and more.

ngrilly 7y ago
Did you have background with languages other than Ruby before starting with Rust? Languages like C++, D, Haskell, OCaml or maybe C#?

Aardappel 7y ago

It is definitely possible to have Rust's compile time lifetime analysis while having a less complicated language that mostly deals memory automatically: https://aardappel.github.io/lobster/memory_management.html https://aardappel.github.io/lobster/memory_management.html