4 ms·

This post gives me extremely little hope. One one hand… ok, let’s say it’s an engineering post written by devs for devs. OKAY, talk about Rust if you like. Dev

This post gives me extremely little hope. One one hand… ok, let’s say it’s an engineering post written by devs for devs. OKAY, talk about Rust if you like. Devs might be more interested in the cause than the effect. On the other hand… is this written for devs? Seems written for users. And I for one don’t give one half of one shit what language you use as a customer. It’s a post about Exchange, I don’t want to hear about new fangled language. I don’t pay you use a specific language, I pay you to deliver a specific feature… now obviously I don’t pay them in anything but time, donation, and reputation. But I think the point applies. No one but Rust Evangelicals care about doing something over in Rust. There isn’t a single end feature that you can deliver in Rust but not C. It reads to me like the developers are nerding out on a detail while being slightly uncommitted to the thing they “are paid to make”. I have to agree with the other users that MS has already set an EOL on the feature that TB is planning to use. So… woohoo Rust?

diarrhea 3y ago
> There isn’t a single end feature that you can deliver in Rust but not C. There are! Namely, when it’s open source with volunteer-ish developers, who cannot be arsed to not use Rust, as it’s simply that much more pleasant to be spending your time with. So in some sense, it’s either done in Rust because the implementers want to for one reason or another, or just not at all, as no one can be forced.
- SV_BubbleTime 3y ago
  That isn’t even remotely a counter to what I said. There is not end feature you can do in Rust that you cannot do in C. End of story. Cool, it’s popular among enthusiasts. That’s fine.
  - small_scombrus 3y ago
    > There is not end feature you can do in Rust that you cannot do in C. Sure, but you could create the whole thing in brainfuck if you really wanted to. Having something be nice to work with or extend is genuinely a feature
    - SV_BubbleTime 3y ago
      Right. So talking to you users about a feature, then spending the who time talking about Rust… tells me you have devs needing out and don’t actually care about the feature. Which they are telling you in multiple ways by talking about on-prem, EWS, Rust. Kind of like that was what my post was about.
sunshowers 3y ago
While it's all software that compiles down to assembly in the end, there's a lot of code that is monstrously difficult to do in C, especially at scale, but relatively straightforward to do in Rust with 1-5% of the dev time. There are also many skilled developers who would simply refuse to do a project like this in C, but would be happy to do it in Rust. As a simple example, writing portable I/O code can be a huge burden in C, but has been abstracted away through libraries like mio in Rust.
- SV_BubbleTime 3y ago
  Code compiles down to machine code. Not assembly. If I give you assembly and disassembly, you’ll prefer the former. Ok. You find it difficult to do things in C. Understood. I believe the topic is of end features, bit maintenance or abstraction.
  - deleted 3y ago
    [deleted]
jcranmer 3y ago
> No one but Rust Evangelicals care about doing something over in Rust. There isn’t a single end feature that you can deliver in Rust but not C. Strictly speaking, no. But there are many ways that the quality of life of writing code is so much higher in Rust than C. A non-exhaustive stuff of just the things I've done in my most recent project: * String handling. C's idiomatic string interface (i.e., null-terminated strings) is a dumpster fire of an interface that makes security vulnerabilities far more likely. And the set of string functions in the C standard library are a joke. * For that matter, memory management. Sure, I can write malloc and free manually, and have to manually remember whenever I get a pointer whether or not I'm responsible for freeing it, or if the pointer is only valid until the next function call, or stuff like that. But scale that to 100KLOC, and the ability of programmers to remember all of those details turns out to shockingly poor. Meanwhile, in Rust, it's a compiler error if you get it wrong, rather than being a crash or worse. * Asynchronous programming. Rust has built-in coroutine support; C does not. * Better idiomatic error handling. Handling an error in Rust is very often just a single ? character. No more chance of gotofail! * Newtypes, which are a godsend if you want to implement a parse-don't-validate strategy. * Better threading support. Rust has a much richer standard library for writing multithreaded applications, and it provides much better compiler support for it (Send and Sync traits are absolute godsends for annotating what can and can't be used from multiple threads). And if you go out into common crates... rayon is a better way to do embarrassingly parallel code than OpenMP is, especially if you want to do fancy stuff like non-trivial reductions. (Side note: the first successful attempt at a multithreaded HTML rendering engine was written in Rust, and that's not for a lack of trying with C++ code. That is how much of a godsend Rust ends up being.) I am by no means a member of the Rewrite-it-in-Rust brigade; I'm pretty sober about the costs of rewrites and the benefits you'd get from such a thing. However, I will say that Rust is generally a superior option than C/C++ if you're doing parsing code (which means you're dealing with untrusted input that you really want to be sure isn't going to go haywire on unexpected input). And for email protocols, where you deal with a lot of mixed binary and text in the same stream, Rust's string handling support is in a sweet spot, especially compared to most other safe VM languages which have different types for binary strings and text strings. Also, knowing enough of the Thunderbird internals to know what code already does need to be rewritten, I'm fairly confident of where I can sensibly propose that things ought to be written in Rust in lieu of C++ or JS.
tiptup300 3y ago
Not to speak negative on you, most likely you have many years with C/C++, but I've been wanting to learn c++ for a long time. I learned the language but getting into a project or parsing through old code I'm still not getting into it. But having picked up a rust book. Maaan. It's so nice. Just the ways it goes about so many things are so inline with the concepts I've already been incorporating into my code for the past 4 years or so. Just really brings a lot of things together into such a nice package. Not to say that you should inherently like rust yourself, it's fine to be indifferent. Either way, heh. .... So... woohoo Rust?

diarrhea 3y ago

> There isn’t a single end feature that you can deliver in Rust but not C. There are! Namely, when it’s open source with volunteer-ish developers, who cannot be arsed to not use Rust, as it’s simply that much more pleasant to be spending your time with. So in some sense, it’s either done in Rust because the implementers want to for one reason or another, or just not at all, as no one can be forced.

SV_BubbleTime 3y ago
That isn’t even remotely a counter to what I said. There is not end feature you can do in Rust that you cannot do in C. End of story. Cool, it’s popular among enthusiasts. That’s fine.
- small_scombrus 3y ago
  > There is not end feature you can do in Rust that you cannot do in C. Sure, but you could create the whole thing in brainfuck if you really wanted to. Having something be nice to work with or extend is genuinely a feature
  - SV_BubbleTime 3y ago
    Right. So talking to you users about a feature, then spending the who time talking about Rust… tells me you have devs needing out and don’t actually care about the feature. Which they are telling you in multiple ways by talking about on-prem, EWS, Rust. Kind of like that was what my post was about.

sunshowers 3y ago

While it's all software that compiles down to assembly in the end, there's a lot of code that is monstrously difficult to do in C, especially at scale, but relatively straightforward to do in Rust with 1-5% of the dev time. There are also many skilled developers who would simply refuse to do a project like this in C, but would be happy to do it in Rust. As a simple example, writing portable I/O code can be a huge burden in C, but has been abstracted away through libraries like mio in Rust.

SV_BubbleTime 3y ago
Code compiles down to machine code. Not assembly. If I give you assembly and disassembly, you’ll prefer the former. Ok. You find it difficult to do things in C. Understood. I believe the topic is of end features, bit maintenance or abstraction.
- deleted 3y ago
  [deleted]

jcranmer 3y ago

> No one but Rust Evangelicals care about doing something over in Rust. There isn’t a single end feature that you can deliver in Rust but not C. Strictly speaking, no. But there are many ways that the quality of life of writing code is so much higher in Rust than C. A non-exhaustive stuff of just the things I've done in my most recent project: * String handling. C's idiomatic string interface (i.e., null-terminated strings) is a dumpster fire of an interface that makes security vulnerabilities far more likely. And the set of string functions in the C standard library are a joke. * For that matter, memory management. Sure, I can write malloc and free manually, and have to manually remember whenever I get a pointer whether or not I'm responsible for freeing it, or if the pointer is only valid until the next function call, or stuff like that. But scale that to 100KLOC, and the ability of programmers to remember all of those details turns out to shockingly poor. Meanwhile, in Rust, it's a compiler error if you get it wrong, rather than being a crash or worse. * Asynchronous programming. Rust has built-in coroutine support; C does not. * Better idiomatic error handling. Handling an error in Rust is very often just a single ? character. No more chance of gotofail! * Newtypes, which are a godsend if you want to implement a parse-don't-validate strategy. * Better threading support. Rust has a much richer standard library for writing multithreaded applications, and it provides much better compiler support for it (Send and Sync traits are absolute godsends for annotating what can and can't be used from multiple threads). And if you go out into common crates... rayon is a better way to do embarrassingly parallel code than OpenMP is, especially if you want to do fancy stuff like non-trivial reductions. (Side note: the first successful attempt at a multithreaded HTML rendering engine was written in Rust, and that's not for a lack of trying with C++ code. That is how much of a godsend Rust ends up being.) I am by no means a member of the Rewrite-it-in-Rust brigade; I'm pretty sober about the costs of rewrites and the benefits you'd get from such a thing. However, I will say that Rust is generally a superior option than C/C++ if you're doing parsing code (which means you're dealing with untrusted input that you really want to be sure isn't going to go haywire on unexpected input). And for email protocols, where you deal with a lot of mixed binary and text in the same stream, Rust's string handling support is in a sweet spot, especially compared to most other safe VM languages which have different types for binary strings and text strings. Also, knowing enough of the Thunderbird internals to know what code already does need to be rewritten, I'm fairly confident of where I can sensibly propose that things ought to be written in Rust in lieu of C++ or JS.

tiptup300 3y ago

Not to speak negative on you, most likely you have many years with C/C++, but I've been wanting to learn c++ for a long time. I learned the language but getting into a project or parsing through old code I'm still not getting into it. But having picked up a rust book. Maaan. It's so nice. Just the ways it goes about so many things are so inline with the concepts I've already been incorporating into my code for the past 4 years or so. Just really brings a lot of things together into such a nice package. Not to say that you should inherently like rust yourself, it's fine to be indifferent. Either way, heh. .... So... woohoo Rust?