7 ms·

I'm an old asm/C/C++ programmer (retired) who wanted to learn Rust but didn't make the effort because of all the stories about how hard it was to deal with the

I'm an old asm/C/C++ programmer (retired) who wanted to learn Rust but didn't make the effort because of all the stories about how hard it was to deal with the borrow checker. Then I realized that for a programmer like me that was used to managing memory in my head, the borrow checker would be a piece of cake. I wrote my first program in it and it was not hard at all. I get it that JavaScript/Python etc... programmers who always had a garbage collector might have trouble. It was so nice to have the compiler catch several stupid errors for me. If I were King of the world I would decree that all new public facing software with real world consequences had to be written in Rust. I'm pretty sure I read that Microsoft is looking at Rust to mitigate some of these issues. Edit: added "new" to make it clear I don't mean rewriting everything in Rust.

pjmlp 7y ago
Currently the biggest issues with the borrow checker are valid codes that it marks as invalid (polonius might fix those when it arrives), and self referencial structures like those using in UI frameworks callbacks.
londons_explore 7y ago
When you already have 10's of millions of lines of code written in C++, migrating to rust is no easy task... Microsoft already tried to migrate bits of userspace to C# in 2008 with windows vista, and that didn't exactly go well... They also tried to migrate UI stuff to HTML in 1998 (Windows explorer, Active desktop). Didn't work out great either. Perhaps 10 years is their corporate memory-span and we're overdue another try tho?
- okareaman 7y ago
  I'm not suggesting re writing everything. I'm suggesting that it's irresponsible to start a new project in an unsafe language when an equally efficient safe language is available.
  - vlovich123 7y ago
    This isn't a new project. Also tooling is a thing & in bigger companies you have to deal with inertia (retraining people is hard). I think at some point the bullet has to be bitten. I also think there's some value in figuring out how to write C/C++ -> Rust translators to automate some of this process. That's the only way we can get ahead of the curve.
    - HideousKojima 7y ago
      It's possible to migrate C to Rust function by function, not sure if anyone has figured out something similar for C++ yet though: https://github.com/carols10cents/rust-out-your-c-talk https://github.com/carols10cents/rust-out-your-c-talk
      - steveklabnik 7y ago
        There is also https://github.com/immunant/c2rust https://github.com/immunant/c2rust
  - Thaxll 7y ago
    Rust is not equal to C++, not even language wise and certainly not from a tool / pipeline / libraries / knowledge side. When you have legacy code, with millions line of code you just don't swap for something else for the sake of it might be better. Adding a new language in a medium / large company is not an easy task. I think Rust is a good contender for C++ "replacement" on the long term but it's a really difficult task and you need proper planning.
    - jodrellblank 7y ago
      > for the sake of it might be better. There are a billion Windows computers on the planet. Each time we have a buffer overrun which gives attackers access or lets them exfiltrate user data, real people are at risk. At risk of ID theft, of money theft, of scammers, of crypolockers, of extortion and blackmail, of company collapse and job loss, of stolen business secrets, of fines, and of wasted time. Each time we have an urgent patch, tens of thousands of IT people around the world have to hurry to patch/bodge/remediate/mitigate/educate systems with little warning and little testing, dragged away from whatever else they were doing. Microsoft have proven they can't do this competently in C++. Are we not long past the "might be better to have tools which check" speculation, and far into "definitely definitely definitely is better" by now? If not by now, what will it take to convince you? (I'm not saying "Definitely Rust", but something - Microsoft make implementations of C++, T-SQL, C#, F#, JS/TypeScript, VB.Net, and employ many top Haskell people at Microsoft Research, and various other languages, they aren't inexperienced at languages). it's a really difficult task and you need proper planning. Then they should hire good developers and plan properly? They are one of the richest companies on the planet who make some of the most popular programming languages and tools on the planet. They're not a poor-me charity case.
- ancarda 7y ago
  How about this - every time a problem like this is found, the affected component is rewritten in Rust. Kinda like how a bug should ideally be fixed by reproducing the issue with a unit test first - the test ensures that particular problem won't come back. AFAIK that's possible for C - a project can be rewritten in Rust one function at a time - but I acknowledge it may not be possible or practical for C++ or other languages. Thing is, there's going to be tons of old C in Windows that is perfectly safe. That code doesn't need to be changed - and with this model, it wouldn't be. What needs to be changed is components like SMB which has been the source of a few high profile vulnerabilities before.
  - muricula 7y ago
    When Rust calls into C code it completely loses almost all of its safety guarantees. Having a codebase which is half C and half Rust sounds worse to read and reason about than all either. Additionally, most Windows code is C++ with Windows specific language extensions (COM, Structured Exception Handling, and others). I think most C++ code should be rewritten in Rust library by library, but most software is not properly constructed as a series of libraries. And asking a business to rewrite working code in a brand new language instead of fixing a buffer overflow is a difficult ask.
    - pjmlp 7y ago
      Microsoft is already had an internal Rust summit, https://twitter.com/ryan_levick/status/1225837057186000896?s=19 https://twitter.com/ryan_levick/status/1225837057186000896?s... and are doing other experiences as well, https://www.infoq.com/news/2019/11/microsoft-exploring-rust-safety/ https://www.infoq.com/news/2019/11/microsoft-exploring-rust-... https://msrc-blog.microsoft.com/2019/11/07/using-rust-in-windows/ https://msrc-blog.microsoft.com/2019/11/07/using-rust-in-win... Kenny Kerr, the original author of C++/Winrt, which replaced C++/CX, has now turned into Rust. https://kennykerr.ca/2020/02/22/rust-winrt-coming-soon/ https://kennykerr.ca/2020/02/22/rust-winrt-coming-soon/ They are also motivated to actually make C safer, with Checked C project, something that ISO C doesn't seem to care that much. https://www.microsoft.com/en-us/research/project/checked-c/ https://www.microsoft.com/en-us/research/project/checked-c/ As per MSRC advisory, new code should be a mix of .NET, Rust or Core Guidelines compliant C++, depending on the use case.
- pjmlp 7y ago
  > Microsoft already tried to migrate bits of userspace to C# in 2008 with windows vista, and that didn't exactly go well.. If there was an actual support from WinDev they would have managed to pull it off, instead they sabotaged the effort and went on redoing those C# classes as COM objects in Vista until we got UWP instead. These kind of reboots do require a change of developer's generation to pull it off.
  - fps_doug 7y ago
    And now we got this fragments ecosystem of classic bare metal "Win32" apps, WinForms, WPF, UWP, and obviously a handful of 3rd party GUI libraries so vendors can completely redesign their UI so it is a special snowflake. C# in 2008 was too early. It was still slow and resource hungry since .NET wasn't that optimized, but also PCs were a lot slower. They sold Vista machines with 1GB of RAM back then. half of that was eaten by the system without opening any actual program you wanted to use. Using rust shouldn't significantly increase resource usage, and nobody is suggesting you go ahead and design yet another UI framework for it. I'm still perfectly fine with win32 apps today.
    - pjmlp 7y ago
      That was the thing, if WinDev was serious, they would have contributed to the .NET runtime improvements, like the SIMD support, AOT compilation or value type improvements in C# 7.x that came from Midori experience. Instead they made sure COM would save the day.
    - AnIdiotOnTheNet 7y ago
      > And now we got this fragments ecosystem of classic bare metal "Win32" apps, WinForms, WPF, UWP, and obviously a handful of 3rd party GUI libraries so vendors can completely redesign their UI so it is a special snowflake. What do you know, Microsoft really did embrace Linux, including its design mentality.
      - pjmlp 7y ago
        Actually, it was more like a return to Microsoft roots. https://en.wikipedia.org/wiki/Xenix https://en.wikipedia.org/wiki/Xenix
- gpderetta 7y ago
  I believe 10's of millions might be quite an underestimate.
JackC 7y ago
> I get it that JavaScript/Python etc... programmers who always had a garbage collector might have trouble. FWIW, as a JS/Python programmer I didn't run into borrow checker issues on my most recent Rust foray -- I think it's gotten easier over time with stuff like non-lexical lifetimes? What I did run into was differences in error handling. If you're used to exceptions it takes a while to get a feel for the variety of idioms that replace them, particularly the chains of and_then().unwrap_or().map().filter().ok().filter_map() that are more familiar for folks coming from pure functional languages.
- nicoburns 7y ago
  > If you're used to exceptions it takes a while to get a feel for the variety of idioms that replace them, particularly the chains of and_then().unwrap_or().map().filter().ok().filter_map() that are more familiar for folks coming from pure functional languages. Coming from JS, this felt familiar to me too: It's virtually identical to how handling errors in Promise chains works.
- twic 7y ago
  > FWIW, as a JS/Python programmer I didn't run into borrow checker issues on my most recent Rust foray -- I think it's gotten easier over time with stuff like non-lexical lifetimes? It also varies hugely according to what kind of program you're writing. Some programs naturally have borrowcheck-friendly structures, others don't. For example, i wrote a program which processes network packets. There is a main loop which reads packets, then passes them down a pipeline of filtering, extraction, and other processing, eventually sending out more network packets. From the compiler's point of view, the pipeline is just a series of nested function calls. Each call can safely borrow from any of the enclosing scopes. Some of the stages are stateful, but they manage their own state, copying data to and from the packets. There's nowhere in a program like this that you run into a problem with borrowing, it all just flows naturally.
jimmaswell 7y ago
I really wanted to give Rust a chance for the memory management but I just don't have the motivation to get past the absolutely bizarre syntax, naming conventions full of weird abbreviations like it's the 80s, and the inscrutable replacement for the OO everyone is familiar with. Every facet of the language feels like an exercise in NIH syndrome and it's just too much at once.
- steveklabnik 7y ago
  Almost all of these things come from other languages, some that have existed for decades. It's probably unfamiliar because you haven't run across them yet, which is fine!
  - deleted 7y ago
    [deleted]
- vmchale 7y ago
  > Every facet of the language feels like an exercise in NIH syndrome and it's just too much at once. Not really, a lot of things are taken from sensible theory (e.g. traits and typeclasses).
- skykooler 7y ago
  Coming from Python, Rust feels like C++ with a stricter compiler. It depends on how you look at it.
- wrs 7y ago
  > an exercise in NIH syndrome Don't fall into the trap of thinking the entire world is like what you can see from where you're standing. It's not really "not-invented-here", it's "not-invented-there", where "there" is wherever you're used to being. There aren't many unprecedented ideas in Rust.
- simias 7y ago
  A lot of the syntax was borrowed from C++ for better or worse. It does make the transition from C++ a lot easier but of course if you're not familiar with the language there'll be some friction. Beyond that there are things that Rust needs syntax for that simply doesn't exist in many other languages such as the Trait-based generics, modules (that didn't use to exist in C++) and of course lifetimes. Beyond that I can't help but feeling that you're following this (IMO) counterproductive cargo cult that holds that sigils are teh 3v1l and everything should be alphanumeric only. Python was at the forefront of this movement but it's now very popular. IMO it's completely counterproductive, even in Python case. It's form over function. You end up with a language where you have to be careful when you refactor because indentation becomes significant and no way to scope your variables properly. Or a language like JS where somebody genuinely thought that having arcane rules to automatically insert semicolons was a reasonable idea because "ewwww semicolons look ugly". It sure looks good if you want to get them tatooed, but in practice at best it's pointless and at worst it gets in the way. I'm all for descriptive variable and function names but the core syntax of the language is repeated all over the place all the time and benefits from concision. Having Rust spell out "function" instead of "fn" wouldn't disambiguate anything since you're exposed to it within 5 minutes in the language and you'll be super familiar with it very quickly. Having a shorthand means that it doesn't pollute the code listing and leaves more room for the actually important stuff. A lot of people like to point out Perl as an example of "sigil soup gone wrong" but I'd argue that it's not even the real problem here, Perl can become an unreadable mess because of all the "magic" it allows, meaning you can write code that seems to do absolutely nothing but actually does a whole lot (with things like the implied variable $_ for instance). If you look at an exhaustive list of Perl operators there are only a handful I'd personally consider questionable (like `x` and maybe `<=>`. Also some of the quoting q{} qq{} and qx{} are really obtuse).
fortran77 7y ago
There's no reason Samba can't be user-mode and written in C#/.net. Even safer!
ksk 7y ago
Why limit developers freedom? If it were so simple with no negative consequences, people would be using Rust already.
fpgaminer 7y ago
> but didn't make the effort because of all the stories about how hard it was to deal with the borrow checker. Then I realized that for a programmer like me that was used to managing memory in my head, the borrow checker would be a piece of cake. Yeah as you've alluded to Rust _feels_ harder, but is easier if one considers the entire effort curve of a project. Rust front loads the problem solving so the hard work is at the beginning of the project instead of C/C++ with its long tail of debugging that takes up 90% of one's effort. Of course, if you don't know that the hard work at the beginning is going to pay off it's hard to commit to it. And coders don't know that until they've tried it. It's why I think Go is a good stepping stone to Rust. Go is easier to get into and useful in its own right, but most importantly it introduces the concept of "if it compiles, it runs" to coders who are used to compilers that fight against them (ala C/C++, Java, Python, JavaScript, etc). Once someone has a taste for helpful compilers I think it's easier for them to swallow Rust. In particular that idea that the borrow checker is there to _help_ you and the supposed "difficulty" of working with it is more about the compiler being transparent with you, instead of the C/C++ way of looking at your broken program and just shrugging and going "Okay, if you say so...".
- pjmlp 7y ago
  Not only Go, any memory safe with AOT to native code toolchains.
- Terr_ 7y ago
  > front loads the problem solving Indeed, and I think this principle applies to other things, like statically-checked type systems. You have to decide types early, but it means a huge class of bugs becomes a non-issue.
IshKebab 7y ago
This is really misleading and I wish people would stop but for some reason everyone is like "Rust is actually easy! You already have to think about borrowing and lifetimes in C/C++ - Rust just makes it explicit.". I love Rust, but that is nonsense. First of all it's a reasonable complicated language even without lifetimes and the borrow checker, but let's ignore that. My issue with this sentiment is that it ignores the fact that the borrow checker isn't smart enough to prove that loads of perfectly valid programs are valid. A simple example: `a[0].foo = a[1].foo;`. Perfectly valid. No memory errors. But Rust isn't smart enough to know, and so it really does make things harder than in C/C++. This isn't a criticism of Rust at all. I think it is a worthwhile tradeoff to get memory safety. I just wish people would stop pretending that it isn't a tradeoff at all!
- lonelappde 7y ago
  How do you copy data from one array of structs to another in rust? Also, if foo is a non-shared pointer that copy doesn't seem safe.
  - steveklabnik 7y ago
    > How do you copy data from one array of structs to another in rust? Depends on exactly what you mean; if you're trying to say, replace one part of an array with another, you would use copy_from_slice https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=e29e9522d81d3cbe3960e842de758d4b https://play.rust-lang.org/?version=stable&mode=debug&editio... (or clone_from_slice if your struct isn't Copy) Also, your parent is just plain incorrect, Rust does let you do that https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=b9d788265b3881a282e46d201dd0b2e5 https://play.rust-lang.org/?version=stable&mode=debug&editio...
    - IshKebab 7y ago
      Sorry, you are correct. I was thinking of situations like this: fn assign(a: &mut Bar, b: &Bar) { a.foo = b.foo; } assign(&mut a[0], &a[1]); Bit contrived - next time Rust stops me doing something simple I will note it down! Again to be clear, I'm not saying that there's anything wrong with Rust here.
forkexec 7y ago
I wouldn't let that get in your way. Try it rather than let your preconceptions tell you "no."

pjmlp 7y ago

Currently the biggest issues with the borrow checker are valid codes that it marks as invalid (polonius might fix those when it arrives), and self referencial structures like those using in UI frameworks callbacks.

londons_explore 7y ago

When you already have 10's of millions of lines of code written in C++, migrating to rust is no easy task... Microsoft already tried to migrate bits of userspace to C# in 2008 with windows vista, and that didn't exactly go well... They also tried to migrate UI stuff to HTML in 1998 (Windows explorer, Active desktop). Didn't work out great either. Perhaps 10 years is their corporate memory-span and we're overdue another try tho?

okareaman 7y ago
I'm not suggesting re writing everything. I'm suggesting that it's irresponsible to start a new project in an unsafe language when an equally efficient safe language is available.
- vlovich123 7y ago
  This isn't a new project. Also tooling is a thing & in bigger companies you have to deal with inertia (retraining people is hard). I think at some point the bullet has to be bitten. I also think there's some value in figuring out how to write C/C++ -> Rust translators to automate some of this process. That's the only way we can get ahead of the curve.
  - HideousKojima 7y ago
    It's possible to migrate C to Rust function by function, not sure if anyone has figured out something similar for C++ yet though: https://github.com/carols10cents/rust-out-your-c-talk https://github.com/carols10cents/rust-out-your-c-talk
    - steveklabnik 7y ago
      There is also https://github.com/immunant/c2rust https://github.com/immunant/c2rust
- Thaxll 7y ago
  Rust is not equal to C++, not even language wise and certainly not from a tool / pipeline / libraries / knowledge side. When you have legacy code, with millions line of code you just don't swap for something else for the sake of it might be better. Adding a new language in a medium / large company is not an easy task. I think Rust is a good contender for C++ "replacement" on the long term but it's a really difficult task and you need proper planning.
  - jodrellblank 7y ago
    > for the sake of it might be better. There are a billion Windows computers on the planet. Each time we have a buffer overrun which gives attackers access or lets them exfiltrate user data, real people are at risk. At risk of ID theft, of money theft, of scammers, of crypolockers, of extortion and blackmail, of company collapse and job loss, of stolen business secrets, of fines, and of wasted time. Each time we have an urgent patch, tens of thousands of IT people around the world have to hurry to patch/bodge/remediate/mitigate/educate systems with little warning and little testing, dragged away from whatever else they were doing. Microsoft have proven they can't do this competently in C++. Are we not long past the "might be better to have tools which check" speculation, and far into "definitely definitely definitely is better" by now? If not by now, what will it take to convince you? (I'm not saying "Definitely Rust", but something - Microsoft make implementations of C++, T-SQL, C#, F#, JS/TypeScript, VB.Net, and employ many top Haskell people at Microsoft Research, and various other languages, they aren't inexperienced at languages). it's a really difficult task and you need proper planning. Then they should hire good developers and plan properly? They are one of the richest companies on the planet who make some of the most popular programming languages and tools on the planet. They're not a poor-me charity case.
ancarda 7y ago
How about this - every time a problem like this is found, the affected component is rewritten in Rust. Kinda like how a bug should ideally be fixed by reproducing the issue with a unit test first - the test ensures that particular problem won't come back. AFAIK that's possible for C - a project can be rewritten in Rust one function at a time - but I acknowledge it may not be possible or practical for C++ or other languages. Thing is, there's going to be tons of old C in Windows that is perfectly safe. That code doesn't need to be changed - and with this model, it wouldn't be. What needs to be changed is components like SMB which has been the source of a few high profile vulnerabilities before.
- muricula 7y ago
  When Rust calls into C code it completely loses almost all of its safety guarantees. Having a codebase which is half C and half Rust sounds worse to read and reason about than all either. Additionally, most Windows code is C++ with Windows specific language extensions (COM, Structured Exception Handling, and others). I think most C++ code should be rewritten in Rust library by library, but most software is not properly constructed as a series of libraries. And asking a business to rewrite working code in a brand new language instead of fixing a buffer overflow is a difficult ask.
  - pjmlp 7y ago
    Microsoft is already had an internal Rust summit, https://twitter.com/ryan_levick/status/1225837057186000896?s=19 https://twitter.com/ryan_levick/status/1225837057186000896?s... and are doing other experiences as well, https://www.infoq.com/news/2019/11/microsoft-exploring-rust-safety/ https://www.infoq.com/news/2019/11/microsoft-exploring-rust-... https://msrc-blog.microsoft.com/2019/11/07/using-rust-in-windows/ https://msrc-blog.microsoft.com/2019/11/07/using-rust-in-win... Kenny Kerr, the original author of C++/Winrt, which replaced C++/CX, has now turned into Rust. https://kennykerr.ca/2020/02/22/rust-winrt-coming-soon/ https://kennykerr.ca/2020/02/22/rust-winrt-coming-soon/ They are also motivated to actually make C safer, with Checked C project, something that ISO C doesn't seem to care that much. https://www.microsoft.com/en-us/research/project/checked-c/ https://www.microsoft.com/en-us/research/project/checked-c/ As per MSRC advisory, new code should be a mix of .NET, Rust or Core Guidelines compliant C++, depending on the use case.
pjmlp 7y ago
> Microsoft already tried to migrate bits of userspace to C# in 2008 with windows vista, and that didn't exactly go well.. If there was an actual support from WinDev they would have managed to pull it off, instead they sabotaged the effort and went on redoing those C# classes as COM objects in Vista until we got UWP instead. These kind of reboots do require a change of developer's generation to pull it off.
- fps_doug 7y ago
  And now we got this fragments ecosystem of classic bare metal "Win32" apps, WinForms, WPF, UWP, and obviously a handful of 3rd party GUI libraries so vendors can completely redesign their UI so it is a special snowflake. C# in 2008 was too early. It was still slow and resource hungry since .NET wasn't that optimized, but also PCs were a lot slower. They sold Vista machines with 1GB of RAM back then. half of that was eaten by the system without opening any actual program you wanted to use. Using rust shouldn't significantly increase resource usage, and nobody is suggesting you go ahead and design yet another UI framework for it. I'm still perfectly fine with win32 apps today.
  - pjmlp 7y ago
    That was the thing, if WinDev was serious, they would have contributed to the .NET runtime improvements, like the SIMD support, AOT compilation or value type improvements in C# 7.x that came from Midori experience. Instead they made sure COM would save the day.
  - AnIdiotOnTheNet 7y ago
    > And now we got this fragments ecosystem of classic bare metal "Win32" apps, WinForms, WPF, UWP, and obviously a handful of 3rd party GUI libraries so vendors can completely redesign their UI so it is a special snowflake. What do you know, Microsoft really did embrace Linux, including its design mentality.
    - pjmlp 7y ago
      Actually, it was more like a return to Microsoft roots. https://en.wikipedia.org/wiki/Xenix https://en.wikipedia.org/wiki/Xenix
gpderetta 7y ago
I believe 10's of millions might be quite an underestimate.

JackC 7y ago

> I get it that JavaScript/Python etc... programmers who always had a garbage collector might have trouble. FWIW, as a JS/Python programmer I didn't run into borrow checker issues on my most recent Rust foray -- I think it's gotten easier over time with stuff like non-lexical lifetimes? What I did run into was differences in error handling. If you're used to exceptions it takes a while to get a feel for the variety of idioms that replace them, particularly the chains of and_then().unwrap_or().map().filter().ok().filter_map() that are more familiar for folks coming from pure functional languages.

nicoburns 7y ago
> If you're used to exceptions it takes a while to get a feel for the variety of idioms that replace them, particularly the chains of and_then().unwrap_or().map().filter().ok().filter_map() that are more familiar for folks coming from pure functional languages. Coming from JS, this felt familiar to me too: It's virtually identical to how handling errors in Promise chains works.
twic 7y ago
> FWIW, as a JS/Python programmer I didn't run into borrow checker issues on my most recent Rust foray -- I think it's gotten easier over time with stuff like non-lexical lifetimes? It also varies hugely according to what kind of program you're writing. Some programs naturally have borrowcheck-friendly structures, others don't. For example, i wrote a program which processes network packets. There is a main loop which reads packets, then passes them down a pipeline of filtering, extraction, and other processing, eventually sending out more network packets. From the compiler's point of view, the pipeline is just a series of nested function calls. Each call can safely borrow from any of the enclosing scopes. Some of the stages are stateful, but they manage their own state, copying data to and from the packets. There's nowhere in a program like this that you run into a problem with borrowing, it all just flows naturally.

jimmaswell 7y ago

I really wanted to give Rust a chance for the memory management but I just don't have the motivation to get past the absolutely bizarre syntax, naming conventions full of weird abbreviations like it's the 80s, and the inscrutable replacement for the OO everyone is familiar with. Every facet of the language feels like an exercise in NIH syndrome and it's just too much at once.

steveklabnik 7y ago
Almost all of these things come from other languages, some that have existed for decades. It's probably unfamiliar because you haven't run across them yet, which is fine!
- deleted 7y ago
  [deleted]
vmchale 7y ago
> Every facet of the language feels like an exercise in NIH syndrome and it's just too much at once. Not really, a lot of things are taken from sensible theory (e.g. traits and typeclasses).
skykooler 7y ago
Coming from Python, Rust feels like C++ with a stricter compiler. It depends on how you look at it.
wrs 7y ago
> an exercise in NIH syndrome Don't fall into the trap of thinking the entire world is like what you can see from where you're standing. It's not really "not-invented-here", it's "not-invented-there", where "there" is wherever you're used to being. There aren't many unprecedented ideas in Rust.
simias 7y ago
A lot of the syntax was borrowed from C++ for better or worse. It does make the transition from C++ a lot easier but of course if you're not familiar with the language there'll be some friction. Beyond that there are things that Rust needs syntax for that simply doesn't exist in many other languages such as the Trait-based generics, modules (that didn't use to exist in C++) and of course lifetimes. Beyond that I can't help but feeling that you're following this (IMO) counterproductive cargo cult that holds that sigils are teh 3v1l and everything should be alphanumeric only. Python was at the forefront of this movement but it's now very popular. IMO it's completely counterproductive, even in Python case. It's form over function. You end up with a language where you have to be careful when you refactor because indentation becomes significant and no way to scope your variables properly. Or a language like JS where somebody genuinely thought that having arcane rules to automatically insert semicolons was a reasonable idea because "ewwww semicolons look ugly". It sure looks good if you want to get them tatooed, but in practice at best it's pointless and at worst it gets in the way. I'm all for descriptive variable and function names but the core syntax of the language is repeated all over the place all the time and benefits from concision. Having Rust spell out "function" instead of "fn" wouldn't disambiguate anything since you're exposed to it within 5 minutes in the language and you'll be super familiar with it very quickly. Having a shorthand means that it doesn't pollute the code listing and leaves more room for the actually important stuff. A lot of people like to point out Perl as an example of "sigil soup gone wrong" but I'd argue that it's not even the real problem here, Perl can become an unreadable mess because of all the "magic" it allows, meaning you can write code that seems to do absolutely nothing but actually does a whole lot (with things like the implied variable $_ for instance). If you look at an exhaustive list of Perl operators there are only a handful I'd personally consider questionable (like `x` and maybe `<=>`. Also some of the quoting q{} qq{} and qx{} are really obtuse).

fortran77 7y ago

There's no reason Samba can't be user-mode and written in C#/.net. Even safer!

ksk 7y ago

Why limit developers freedom? If it were so simple with no negative consequences, people would be using Rust already.

fpgaminer 7y ago

> but didn't make the effort because of all the stories about how hard it was to deal with the borrow checker. Then I realized that for a programmer like me that was used to managing memory in my head, the borrow checker would be a piece of cake. Yeah as you've alluded to Rust _feels_ harder, but is easier if one considers the entire effort curve of a project. Rust front loads the problem solving so the hard work is at the beginning of the project instead of C/C++ with its long tail of debugging that takes up 90% of one's effort. Of course, if you don't know that the hard work at the beginning is going to pay off it's hard to commit to it. And coders don't know that until they've tried it. It's why I think Go is a good stepping stone to Rust. Go is easier to get into and useful in its own right, but most importantly it introduces the concept of "if it compiles, it runs" to coders who are used to compilers that fight against them (ala C/C++, Java, Python, JavaScript, etc). Once someone has a taste for helpful compilers I think it's easier for them to swallow Rust. In particular that idea that the borrow checker is there to _help_ you and the supposed "difficulty" of working with it is more about the compiler being transparent with you, instead of the C/C++ way of looking at your broken program and just shrugging and going "Okay, if you say so...".

pjmlp 7y ago
Not only Go, any memory safe with AOT to native code toolchains.
Terr_ 7y ago
> front loads the problem solving Indeed, and I think this principle applies to other things, like statically-checked type systems. You have to decide types early, but it means a huge class of bugs becomes a non-issue.

IshKebab 7y ago

This is really misleading and I wish people would stop but for some reason everyone is like "Rust is actually easy! You already have to think about borrowing and lifetimes in C/C++ - Rust just makes it explicit.". I love Rust, but that is nonsense. First of all it's a reasonable complicated language even without lifetimes and the borrow checker, but let's ignore that. My issue with this sentiment is that it ignores the fact that the borrow checker isn't smart enough to prove that loads of perfectly valid programs are valid. A simple example: `a[0].foo = a[1].foo;`. Perfectly valid. No memory errors. But Rust isn't smart enough to know, and so it really does make things harder than in C/C++. This isn't a criticism of Rust at all. I think it is a worthwhile tradeoff to get memory safety. I just wish people would stop pretending that it isn't a tradeoff at all!

lonelappde 7y ago
How do you copy data from one array of structs to another in rust? Also, if foo is a non-shared pointer that copy doesn't seem safe.
- steveklabnik 7y ago
  > How do you copy data from one array of structs to another in rust? Depends on exactly what you mean; if you're trying to say, replace one part of an array with another, you would use copy_from_slice https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=e29e9522d81d3cbe3960e842de758d4b https://play.rust-lang.org/?version=stable&mode=debug&editio... (or clone_from_slice if your struct isn't Copy) Also, your parent is just plain incorrect, Rust does let you do that https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=b9d788265b3881a282e46d201dd0b2e5 https://play.rust-lang.org/?version=stable&mode=debug&editio...
  - IshKebab 7y ago
    Sorry, you are correct. I was thinking of situations like this: fn assign(a: &mut Bar, b: &Bar) { a.foo = b.foo; } assign(&mut a[0], &a[1]); Bit contrived - next time Rust stops me doing something simple I will note it down! Again to be clear, I'm not saying that there's anything wrong with Rust here.

forkexec 7y ago

I wouldn't let that get in your way. Try it rather than let your preconceptions tell you "no."