4 ms·

If Rust helps with their pains and they like Rust this seems very sensible. That's exactly why we have different languages and tools, because they adapt differ

If Rust helps with their pains and they like Rust this seems very sensible. That's exactly why we have different languages and tools, because they adapt differently to different projects, teams and problems. But as soon as you get into the silly "tool X is better period" arguments, then all the nuance of choosing the right tool for the job is lost.

dingdingdang 11mo ago
Sensible take, thank you. When HN get these "our project: from x to y language" frontpage stories I am always thinking that it would be far more exciting with "our project: 38.2% smaller code base by optimizing our dependency use", "our project: performance optimized by 16.4% by basic profiler use" or similar!
- staticassertion 11mo ago
  Isn't this just the same value judgment mistake? You're just presupposing that things like "smaller code base" are better in virtue of themselves the same way that "rewritten in Rust" might be as well. The parent poster's point is seemingly to reject "this is simply the better thing" (ie: "small code is better") and instead to focus on "for what we are doing it is the better thing". Why would "basic" profiler use be better than "niche" or "advanced" profiler use if for that context basic would actually have been inferior (for whatever value of basic we choose to go with)? It seems to me that the reality we're often confronted with is that "better" is contextual, and I would say that "basic" or "smaller" are contextual too.
- morkalork 11mo ago
  Is the trade off here having more secure code in exchange for added complexity/difficulty? This is a real question, has the Tor code itself been exploited by bad actors before? All the incedences I've seen in the news were some other software running over tor that would be exploited to phone home or give up user data.
  - uecker 11mo ago
    It seems they worry about it, which I can understand. But now with Rust I worry about about new logic bugs, supply chain issues, and lack of proper security updates.
    - steveklabnik 11mo ago
      Well, given that this has been going on for years, you can already start to empirically evaluate that question.
      - yjdiquhf 11mo ago
        > (So far, it's a not-very-complete client. But watch this space!)
        steveklabnik 11mo ago
        Yes, it's a beginning not the end. Or, you could look at other projects who have been using Rust for many years, and consider these factors there too. The folks who have have generally concluded the opposite.
        yjdiquhf 11mo ago
        [flagged]
        ue7gjelwjd 11mo ago
        [flagged]
        steveklabnik 11mo ago
        Do you think the sibling comment was flagged to "protect me" whatever that means, or is it because "Are you high on Prozac?" is not really a productive comment? EDIT: And now that I've scrolled down, I see you've left this comment many times as random replies. I'm sure those will get flagged, but for spam reasons, not due to some grand conspiracy.
- classicasp 11mo ago
  I think the chance that your Rust application is going to be more performant or efficient than C, is whether you are focused on writing performant and efficient code. Out-of-the-box, I’m guessing people will use too many cargo packages, each that are over-engineered or written by less-experienced developers, so it will be less efficient and less performant. In addition, you could more easily inadvertently introduce security problems. Is Rust the right choice for Tor? Sure. Is Tor the right choice for security? If they moved to Rust, they increased security risks to make it easier to manage and find help from younger less-experienced developers, so no.
  - gldrk 11mo ago
    Given how heavily most C programs lean on type erasure vs. monomorphization and how often they reimplement basic data structures, it's kind of a miracle they hold up against Rust/C++.
    - uecker 11mo ago
      Why? Monomorphization often leads to great results in microbenchmarks due to super-specialized code but also to bloat.
  - Yoric 11mo ago
    > I think the chance that your Rust application is going to be more performant or efficient than C, is whether you are focused on writing performant and efficient code. I believe that depends on the sophistication of algorithms. High-level algorithms (especially if they involve concurrency or parallelism) are much easier to write in Rust (or in C++) than in C, which gives them a pretty good chance to be at least as fast as any reasonably safe C implementation. For low-level algorithms, of course, it's really hard to beat polished C code. > Out-of-the-box, I’m guessing people will use too many cargo packages, each that are over-engineered or written by less-experienced developers, so it will be less efficient and less performant. I don't think that this is going to be a problem. The Tor Project developers I've interacted with sounded quite serious about security. Forbidding non-blessed cargo packages is pretty trivial. > In addition, you could more easily inadvertently introduce security problems. What do you mean?
- bluGill 11mo ago
  Sometimes language is a limiting factor and so you need to change languages before getting better. However this is rare.
YetAnotherNick 11mo ago
What are the project specific nuance you are talking about? Anything in this and linked post could be applied to any performant application which values memory safety. So unless they provide some Tor specific nuance, it's more or less applicable to wide range of applications.
letmetweakit 11mo ago
Why do you even bring this up, the blog post does not contain this message, they rewrote it to eliminate a class of bugs. They don’t bash C, so refrain yourself from mentioning what hypothetically could have been written…
- machomaster 11mo ago
  He wrote it because he has eyes and has seen how the typical conversations about switching to Rust often go.
- LexiMax 11mo ago
  Because Hacker News gamifies engagement, and they know that this kind of message tends to attract a lot of upvotes. The whole conversation tree is a carpet of land-mines, laid out in the hopes that someone steps on one so they can pounce. This sort of gamification of discourse is poison if you actually care about good faith or reasonable discussions. HN is not a good place for either.
GuB-42 11mo ago
I hate the "rewrite it in Rust" mentality, however, I think that in this particular case, Rust is the right tool for the job. The Rust specialty is memory safety and performance in an relatively unconstrained environment (usually a PC), with multithreading. Unsurprisingly, because that's how it started, that's what a web browser is. But Tor is also this. Security is extremely important as Tor will be under attack by the most resourceful hackers (state actors, ...), and the typical platform for Tor is a linux multicore PC, not some tiny embedded system or some weird platform, and because it may involve a lot of data and it is latency-sensitive, performance matters. I don't know enough of these projects but I think it could also take another approach and use Zig in the same way Tigerbeetle uses it. But Zig may lack maturity, and it would be a big change. I think it is relevant because Tigerbeetle is all about determinism: do the same thing twice and the memory image should be exactly the same. I think it has value when it comes to security but also fingerprinting resistance, plus, it could open the way for dedicated Tor machines, maybe running some RTOS for even more determinism.
- hgomersall 11mo ago
  FWIW, rust is great on a tiny embedded system.
  - udhghhe 11mo ago
    But with no_std, Rust is not memory safe, even when not using unsafe. It does have pattern matching and modules, however.
    - estebank 11mo ago
      > But with no_std, Rust is not memory safe, even when not using unsafe. What makes you say that?
      - yjdiquhf 11mo ago
        [flagged]
guywithahat 11mo ago
I had that thought too; the author claims tor suffers from user free bugs but like, really? A 20 year old code base with a massive supportive following suffers from basic memory issues that can often be caught with linters or dynamic analysis? Surely there are development issues I'm not aware of but I wasn't really sold by the article
- zelphirkalt 11mo ago
  That can easily happen in C programs. Some edge case doesn't really happen, unless you specifically craft inputs for that, or even sequences of inputs, and simply no one was aware for those 20 years, or no one tried to exploit that specific part of the code. With C you are never safe, unless you somehow proved the code to be free of such bugs.
  - uecker 11mo ago
    This is a bit of an exaggeration. Many types of bugs can also happen with Rust, and with you use unsafe or have some dependency that uses it, then also memory safety bugs. At the same time, it is possible to reduce the probability and impact of such bugs in C code in a reasonable way even without formal verification.
    - estebank 11mo ago
      Does every discussion of Rust and C need this recurring subthread conversation? It is approaching Groundhog Day levels of repetition. Yes, `unsafe` code can have memory safety bugs. Yes, `unsafe` doesn't mean "unsafe". Yes, a sufficiently advanced C-developer can have a sufficiently advanced C-codebase with reduced probability of bugs that might be even better than an insufficiently advanced Rust-developer. Yes, regular safe-Rust isn't the same formal verification. Yes, Rust doesn't catch every bug. On the other hand, most developers have no need of writing `unsafe` Rust. The same tools used for static and dynamic analysis of C codebases are available to Rust (ASAN and friends) and it is a good idea to use them when writing `unsafe` (plus miri). The reason I'm replying is that "the impact of Rust on memory safety" is always a conversation that gets outsized amounts of ink that it drains focus away from other things. I would argue that sum types and exhaustive pattern matching are way more important to minimize logic bugs, even if they aren't enough. You can still have a directory traversal bug letting a remote service write outside of the directory your local service meant to allow. You can still have TOCTOU bugs. You can still have DoS attacks if your codebase doesn't handle all cases carefully. Race conditions can still happen. Specific libraries might be able to protect from some of these, and library reuse increases the likelihood of of these being handled sanely (but doesn't ensure it). Rust doesn't protect against every potential logic error. It never claimed to, and arguing against it is arguing against a strawman. What safe-Rust does claim is no memory safety bugs, no data races, and to provide language and tooling features to model your business logic and deal with complexity.
concinds 11mo ago
We could move past all the unproductive, polarized online arguments if everyone accepted that: 1. Programmer skill and talent are not enough to achieve similar security properties with memory-unsafe languages as with memory-safe languages. 2. Therefore, "memory-safe languages are technically superior, period, for applications processing untrusted data where security is an important goal", is not an un-nuanced argument nor a Rust fanboy argument, but self-evident. That still leaves a lot of room for other languages (Rust is not my favorite language), but it pushes back against the developer equivalent of doctors and pilots resisting the adoption of checklists for decades because "I wouldn't make those kinds of mistakes so stop messing with my work".
- udhghhe 11mo ago
  Thing is, Rust is not a memory safe programming language. It's not even close to being one. > Diagnosing a Double-Free Concurrency Bug in Rust's Unbounded Channels https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/ https://materialize.com/blog/rust-concurrency-bug-unbounded-...
  - deleted 11mo ago
    [deleted]
- tialaramex 11mo ago
  C++ in particular has a thriving industry of people who'll come teach your team to write "proper" C++. You've probably heard that "It is difficult to get a man to understand something, when his salary depends on his not understanding it" and so of course we shouldn't expect such people to say "Don't write this in C++" when they can instead get paid to teach "How to write this in C++" for 2-3 days and feel like they made the world a better place on top. It so happens Rust is my favourite language, or at least, my favourite general purpose language, but it's also true that I am currently mostly paid to write C# and I see absolutely no reason why I'd say "No, this should be Rust" for most work I do in C#
- yjftsjthsd-h 11mo ago
  Almost? I'd fully support 1. Programmer skill and talent are not enough to achieve similar security properties with memory-unsafe languages as with memory-safe languages. 2. Therefore, "memory-safe languages are technically superior, period, for applications processing untrusted data where security is an important goal" but the problem entirely boils down to what comes next: 3a. Therefore everything should use rust. 3b. Therefore everything processing untrusted data where security is an important goal should use rust. (Some folks like to stretch what could possibly process untrusted data to turn this into 3a, but there is a difference.) 3c. Therefore most programs really should be written with a garbage-collector, or if they really need to be low-level or high performance they should use an appropriate stack to avoid gc while remaining safe (whether that's Rust, Ada+SPARK, formally-verified assembly, or whatever).
amelius 11mo ago
In this case Rust makes sense. However for the majority of UI projects it doesn't make sense. For UI you want to iterate quickly because requirements change often, and you want garbage collection to be able to move fast. At the same time, performance does not matter (low level stuff like bit blitting can be done by lower level libraries perhaps written in Rust or even at the hardware level). A language designed for systems programming makes zero sense there. Unfortunately, we see a lot of "This UI project now in Rust!" on HN, and people get annoyed by that, and I think rightfully so. People don't want to maintain code that was written in the wrong language, and that __will__ happen if other people pick a language for the wrong reasons.
- yjdiquhf 11mo ago
  I am confused by this comment on the project page. https://gitlab.torproject.org/tpo/core/arti https://gitlab.torproject.org/tpo/core/arti > (So far, it's a not-very-complete client. But watch this space!) Is that comment outdated? The blog post gave me a different impression. If Arti is not ready yet, shouldn't that have been made clear in the blog post and in the various posts here? Not directing it at you, amelius.
ls-a 11mo ago
I think companies hired too many Rust engineers, and now those engineers are writing technical blogs and making product decisions. We're seeing a lot of those everyday on HN first page

dingdingdang 11mo ago

Sensible take, thank you. When HN get these "our project: from x to y language" frontpage stories I am always thinking that it would be far more exciting with "our project: 38.2% smaller code base by optimizing our dependency use", "our project: performance optimized by 16.4% by basic profiler use" or similar!

staticassertion 11mo ago
Isn't this just the same value judgment mistake? You're just presupposing that things like "smaller code base" are better in virtue of themselves the same way that "rewritten in Rust" might be as well. The parent poster's point is seemingly to reject "this is simply the better thing" (ie: "small code is better") and instead to focus on "for what we are doing it is the better thing". Why would "basic" profiler use be better than "niche" or "advanced" profiler use if for that context basic would actually have been inferior (for whatever value of basic we choose to go with)? It seems to me that the reality we're often confronted with is that "better" is contextual, and I would say that "basic" or "smaller" are contextual too.
morkalork 11mo ago
Is the trade off here having more secure code in exchange for added complexity/difficulty? This is a real question, has the Tor code itself been exploited by bad actors before? All the incedences I've seen in the news were some other software running over tor that would be exploited to phone home or give up user data.
- uecker 11mo ago
  It seems they worry about it, which I can understand. But now with Rust I worry about about new logic bugs, supply chain issues, and lack of proper security updates.
  - steveklabnik 11mo ago
    Well, given that this has been going on for years, you can already start to empirically evaluate that question.
    - yjdiquhf 11mo ago
      > (So far, it's a not-very-complete client. But watch this space!)
      - steveklabnik 11mo ago
        Yes, it's a beginning not the end. Or, you could look at other projects who have been using Rust for many years, and consider these factors there too. The folks who have have generally concluded the opposite.
        yjdiquhf 11mo ago
        [flagged]
        ue7gjelwjd 11mo ago
        [flagged]
        steveklabnik 11mo ago
        Do you think the sibling comment was flagged to "protect me" whatever that means, or is it because "Are you high on Prozac?" is not really a productive comment? EDIT: And now that I've scrolled down, I see you've left this comment many times as random replies. I'm sure those will get flagged, but for spam reasons, not due to some grand conspiracy.
classicasp 11mo ago
I think the chance that your Rust application is going to be more performant or efficient than C, is whether you are focused on writing performant and efficient code. Out-of-the-box, I’m guessing people will use too many cargo packages, each that are over-engineered or written by less-experienced developers, so it will be less efficient and less performant. In addition, you could more easily inadvertently introduce security problems. Is Rust the right choice for Tor? Sure. Is Tor the right choice for security? If they moved to Rust, they increased security risks to make it easier to manage and find help from younger less-experienced developers, so no.
- gldrk 11mo ago
  Given how heavily most C programs lean on type erasure vs. monomorphization and how often they reimplement basic data structures, it's kind of a miracle they hold up against Rust/C++.
  - uecker 11mo ago
    Why? Monomorphization often leads to great results in microbenchmarks due to super-specialized code but also to bloat.
- Yoric 11mo ago
  > I think the chance that your Rust application is going to be more performant or efficient than C, is whether you are focused on writing performant and efficient code. I believe that depends on the sophistication of algorithms. High-level algorithms (especially if they involve concurrency or parallelism) are much easier to write in Rust (or in C++) than in C, which gives them a pretty good chance to be at least as fast as any reasonably safe C implementation. For low-level algorithms, of course, it's really hard to beat polished C code. > Out-of-the-box, I’m guessing people will use too many cargo packages, each that are over-engineered or written by less-experienced developers, so it will be less efficient and less performant. I don't think that this is going to be a problem. The Tor Project developers I've interacted with sounded quite serious about security. Forbidding non-blessed cargo packages is pretty trivial. > In addition, you could more easily inadvertently introduce security problems. What do you mean?
bluGill 11mo ago
Sometimes language is a limiting factor and so you need to change languages before getting better. However this is rare.

YetAnotherNick 11mo ago

What are the project specific nuance you are talking about? Anything in this and linked post could be applied to any performant application which values memory safety. So unless they provide some Tor specific nuance, it's more or less applicable to wide range of applications.

letmetweakit 11mo ago

Why do you even bring this up, the blog post does not contain this message, they rewrote it to eliminate a class of bugs. They don’t bash C, so refrain yourself from mentioning what hypothetically could have been written…

machomaster 11mo ago
He wrote it because he has eyes and has seen how the typical conversations about switching to Rust often go.
LexiMax 11mo ago
Because Hacker News gamifies engagement, and they know that this kind of message tends to attract a lot of upvotes. The whole conversation tree is a carpet of land-mines, laid out in the hopes that someone steps on one so they can pounce. This sort of gamification of discourse is poison if you actually care about good faith or reasonable discussions. HN is not a good place for either.

GuB-42 11mo ago

I hate the "rewrite it in Rust" mentality, however, I think that in this particular case, Rust is the right tool for the job. The Rust specialty is memory safety and performance in an relatively unconstrained environment (usually a PC), with multithreading. Unsurprisingly, because that's how it started, that's what a web browser is. But Tor is also this. Security is extremely important as Tor will be under attack by the most resourceful hackers (state actors, ...), and the typical platform for Tor is a linux multicore PC, not some tiny embedded system or some weird platform, and because it may involve a lot of data and it is latency-sensitive, performance matters. I don't know enough of these projects but I think it could also take another approach and use Zig in the same way Tigerbeetle uses it. But Zig may lack maturity, and it would be a big change. I think it is relevant because Tigerbeetle is all about determinism: do the same thing twice and the memory image should be exactly the same. I think it has value when it comes to security but also fingerprinting resistance, plus, it could open the way for dedicated Tor machines, maybe running some RTOS for even more determinism.

hgomersall 11mo ago
FWIW, rust is great on a tiny embedded system.
- udhghhe 11mo ago
  But with no_std, Rust is not memory safe, even when not using unsafe. It does have pattern matching and modules, however.
  - estebank 11mo ago
    > But with no_std, Rust is not memory safe, even when not using unsafe. What makes you say that?
    - yjdiquhf 11mo ago
      [flagged]

guywithahat 11mo ago

I had that thought too; the author claims tor suffers from user free bugs but like, really? A 20 year old code base with a massive supportive following suffers from basic memory issues that can often be caught with linters or dynamic analysis? Surely there are development issues I'm not aware of but I wasn't really sold by the article

zelphirkalt 11mo ago
That can easily happen in C programs. Some edge case doesn't really happen, unless you specifically craft inputs for that, or even sequences of inputs, and simply no one was aware for those 20 years, or no one tried to exploit that specific part of the code. With C you are never safe, unless you somehow proved the code to be free of such bugs.
- uecker 11mo ago
  This is a bit of an exaggeration. Many types of bugs can also happen with Rust, and with you use unsafe or have some dependency that uses it, then also memory safety bugs. At the same time, it is possible to reduce the probability and impact of such bugs in C code in a reasonable way even without formal verification.
  - estebank 11mo ago
    Does every discussion of Rust and C need this recurring subthread conversation? It is approaching Groundhog Day levels of repetition. Yes, `unsafe` code can have memory safety bugs. Yes, `unsafe` doesn't mean "unsafe". Yes, a sufficiently advanced C-developer can have a sufficiently advanced C-codebase with reduced probability of bugs that might be even better than an insufficiently advanced Rust-developer. Yes, regular safe-Rust isn't the same formal verification. Yes, Rust doesn't catch every bug. On the other hand, most developers have no need of writing `unsafe` Rust. The same tools used for static and dynamic analysis of C codebases are available to Rust (ASAN and friends) and it is a good idea to use them when writing `unsafe` (plus miri). The reason I'm replying is that "the impact of Rust on memory safety" is always a conversation that gets outsized amounts of ink that it drains focus away from other things. I would argue that sum types and exhaustive pattern matching are way more important to minimize logic bugs, even if they aren't enough. You can still have a directory traversal bug letting a remote service write outside of the directory your local service meant to allow. You can still have TOCTOU bugs. You can still have DoS attacks if your codebase doesn't handle all cases carefully. Race conditions can still happen. Specific libraries might be able to protect from some of these, and library reuse increases the likelihood of of these being handled sanely (but doesn't ensure it). Rust doesn't protect against every potential logic error. It never claimed to, and arguing against it is arguing against a strawman. What safe-Rust does claim is no memory safety bugs, no data races, and to provide language and tooling features to model your business logic and deal with complexity.

concinds 11mo ago

We could move past all the unproductive, polarized online arguments if everyone accepted that: 1. Programmer skill and talent are not enough to achieve similar security properties with memory-unsafe languages as with memory-safe languages. 2. Therefore, "memory-safe languages are technically superior, period, for applications processing untrusted data where security is an important goal", is not an un-nuanced argument nor a Rust fanboy argument, but self-evident. That still leaves a lot of room for other languages (Rust is not my favorite language), but it pushes back against the developer equivalent of doctors and pilots resisting the adoption of checklists for decades because "I wouldn't make those kinds of mistakes so stop messing with my work".

udhghhe 11mo ago
Thing is, Rust is not a memory safe programming language. It's not even close to being one. > Diagnosing a Double-Free Concurrency Bug in Rust's Unbounded Channels https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/ https://materialize.com/blog/rust-concurrency-bug-unbounded-...
- deleted 11mo ago
  [deleted]
tialaramex 11mo ago
C++ in particular has a thriving industry of people who'll come teach your team to write "proper" C++. You've probably heard that "It is difficult to get a man to understand something, when his salary depends on his not understanding it" and so of course we shouldn't expect such people to say "Don't write this in C++" when they can instead get paid to teach "How to write this in C++" for 2-3 days and feel like they made the world a better place on top. It so happens Rust is my favourite language, or at least, my favourite general purpose language, but it's also true that I am currently mostly paid to write C# and I see absolutely no reason why I'd say "No, this should be Rust" for most work I do in C#
yjftsjthsd-h 11mo ago
Almost? I'd fully support 1. Programmer skill and talent are not enough to achieve similar security properties with memory-unsafe languages as with memory-safe languages. 2. Therefore, "memory-safe languages are technically superior, period, for applications processing untrusted data where security is an important goal" but the problem entirely boils down to what comes next: 3a. Therefore everything should use rust. 3b. Therefore everything processing untrusted data where security is an important goal should use rust. (Some folks like to stretch what could possibly process untrusted data to turn this into 3a, but there is a difference.) 3c. Therefore most programs really should be written with a garbage-collector, or if they really need to be low-level or high performance they should use an appropriate stack to avoid gc while remaining safe (whether that's Rust, Ada+SPARK, formally-verified assembly, or whatever).

amelius 11mo ago

In this case Rust makes sense. However for the majority of UI projects it doesn't make sense. For UI you want to iterate quickly because requirements change often, and you want garbage collection to be able to move fast. At the same time, performance does not matter (low level stuff like bit blitting can be done by lower level libraries perhaps written in Rust or even at the hardware level). A language designed for systems programming makes zero sense there. Unfortunately, we see a lot of "This UI project now in Rust!" on HN, and people get annoyed by that, and I think rightfully so. People don't want to maintain code that was written in the wrong language, and that __will__ happen if other people pick a language for the wrong reasons.

yjdiquhf 11mo ago
I am confused by this comment on the project page. https://gitlab.torproject.org/tpo/core/arti https://gitlab.torproject.org/tpo/core/arti > (So far, it's a not-very-complete client. But watch this space!) Is that comment outdated? The blog post gave me a different impression. If Arti is not ready yet, shouldn't that have been made clear in the blog post and in the various posts here? Not directing it at you, amelius.

ls-a 11mo ago

I think companies hired too many Rust engineers, and now those engineers are writing technical blogs and making product decisions. We're seeing a lot of those everyday on HN first page