6 ms·

>a crashed program is a crashed program whether I dereferenced a null pointer or was poking around in a slice with multi-byte Unicode characters in it Most of

>a crashed program is a crashed program whether I dereferenced a null pointer or was poking around in a slice with multi-byte Unicode characters in it Most of the biggest advances in software engineering are because of increased modularity. One of the best traditional ways to increase modularity is the ability to define and call functions. But any isolation between these "function" modules is only possible if you can at least factor out things into a function mechanically without introducing crashes (for example because of memory unsafety--modularity would fly out of the window right there). >Rust is cool for so many great reasons that get talked about so little because everyone seems too busy acting superior about memory safety. Talk about traits! Or Cargo! Or the cool async stuff! Anything but another lecture on memory safety. It's better not to dilute the message. All these other things are nice-to-have gimmicks. But the memory safety is a game-changer. It does no good to advertise 230 features at the same time. No one will remember. Advertise the killer feature. And that's the lifetime stuff, which gives you memory AND THREAD safety.

benreesman 4y ago
Rust isn't a startup business or (one hopes) a religion, or an MLM, or a home for sale. It's a useful tool among many. Why do people say things like: "It's better not to dilute the message"? Better for who? That's sales/marketing language, not engineering language. "The message"? Pardon my Francais, but WTF?
- dannymi 4y ago
  >Why do people say things like: "It's better not to dilute the message"? >Better for who? Better for everyone. When talking about a new thing, it would be really silly to emphasize how nice the logo is, how nice the package it comes in is, look at the awesome tape the box is closed with etc. If I turn the product off it even turns off! Look at the nice rounded corners of the device! It even can do async! Just like Javascript and .NET. Who cares! What is the main strength of the tool, the pain point it was made to eliminate? Lead with that. > That's sales/marketing language, not engineering language. Leading with the actual technical novelty that actually advances the state of the art in production compilers is marketing? Well, I guess it's good marketing in a way. The user will find cargo on their own in 5 minutes.
  - benreesman 4y ago
    I mean "message" how you want, HN is hosted in a free country. But N=1 for you: as a serious polyglot user of Rust who knows it well and uses it all the time: this shit is a huge turnoff. It's a programming language. On a long enough timeline all the motivated hackers will end up knowing many programming languages well, they all have pros and cons. Trying to boil important engineering decisions down to a tweet so that we can stay "on message" comes off like something someone would do if they were selling books or training or consulting services attached to a technology, which a priori gives them an agenda other than giving good advice. So to keep it short: help people pick the right tool for the job without an agenda.
    - bluejekyll 4y ago
      Rust is a programming language. It’s the right tool for the job of programming. It happens to have a lot of features that make it a very good programming language. I think you’re wrong about the language and community, though. It’s killer feature is it’s safety, be it memory, data race, or type. These are the reasons I was interested in learning the language. The fact that the tools make that easier is why I was able to struggle through the new concepts and actually be able to build useful things with it. If the fact that people enjoy something as a general community turns you off, that’s not the community’s problem.
    - jamincan 4y ago
      I think you have a point. Rust is primarily focused on being a systems language, and memory safety is the killer feature it brings to the table in that domain. But we know that Rust is being used in areas where its qualities as a systems language are less important. Why, for example, would a Python developer pick up Rust? Probably because of the really strict typing addressing a major pain point for most Python developers and the trait system being somewhat analogous to Protocols, which any Python developer who has chafed with the dynamic typing is almost certainly already familiar with. With good library support for interfacing between the two, it's a more natural coupling than most people would think on the face of it. That said, while I don't think a Python developer reaches for Rust because of memory safety, I do think it's still an important factor as it provides the guard rails that make it so someone who has primarily used a GC language and not had to concern themselves as much with managing memory can start using Rust knowing that the compiler is not going to let them accidentally shoot them in the foot when it comes to memory management.
pjmlp 4y ago
Rust's thread safety only applies to the special case of those threads accessing in process data segments. Rust's type system can do very little to help when those threads are accessing the same record on a database without transactions, OS IPC on shared memory, manipulating files without locks, handling hardware signals, handling duplicate RPC calls,... Yeah but that ultimately requires an unsafe block, kind of true, except no one reads the code of all crates they depend on, and the direct dependencies might be safe in what concerns the direct consumers.
- bluejekyll 4y ago
  This is a point that you constantly bring up in these threads, do you think most developers believe that data race safety should extend beyond the bounds of the process? One thing that Rust’s type system does allow you to do is define a consistent manner in which to access external systems, even add types that will mimic the same safety. Is it perfect? Will it protect you from a different process working against the DB? Will it enforce things in the other process? No. But will it give you higher level semantics to be able to construct a better model for operating against that external system? Yes.
  - pjmlp 4y ago
    Yes, when they care about data consistency in distributed systems. Maybe many Rust devs don't care.
    - bluejekyll 4y ago
      So what is your point? You’re changing the goal posts on safety and it’s a pointless reductive argument. Even if we account for everything, solar storms will eventually flip bits unexpectedly. Does that make Rust’s guarantees worthless?
      - pjmlp 4y ago
        The goal posts stay on the same place. There are ways towards data corruption where Rust's fearsome concurrency is of no help.
nyanpasu64 4y ago
rustc rejects the resulting program if you mechanically factor out a function accessing &mut self, into a function holding mutable borrows to half the fields calling another function which access the other half of fields (or vice versa, the caller holding &field calling a method mutating other fields). This requires the more complex transformation of passing individual fields into the subfunction (more work, but sometimes easier to read), or waiting for Rust to add partial borrows. Note I've never actually hit this case myself, though I've heard it's an issue people run into.
- estebank 4y ago
  The third option is to use a wrapper type with internal mutability, but that is to be done very sparingly.

benreesman 4y ago

Rust isn't a startup business or (one hopes) a religion, or an MLM, or a home for sale. It's a useful tool among many. Why do people say things like: "It's better not to dilute the message"? Better for who? That's sales/marketing language, not engineering language. "The message"? Pardon my Francais, but WTF?

dannymi 4y ago
>Why do people say things like: "It's better not to dilute the message"? >Better for who? Better for everyone. When talking about a new thing, it would be really silly to emphasize how nice the logo is, how nice the package it comes in is, look at the awesome tape the box is closed with etc. If I turn the product off it even turns off! Look at the nice rounded corners of the device! It even can do async! Just like Javascript and .NET. Who cares! What is the main strength of the tool, the pain point it was made to eliminate? Lead with that. > That's sales/marketing language, not engineering language. Leading with the actual technical novelty that actually advances the state of the art in production compilers is marketing? Well, I guess it's good marketing in a way. The user will find cargo on their own in 5 minutes.
- benreesman 4y ago
  I mean "message" how you want, HN is hosted in a free country. But N=1 for you: as a serious polyglot user of Rust who knows it well and uses it all the time: this shit is a huge turnoff. It's a programming language. On a long enough timeline all the motivated hackers will end up knowing many programming languages well, they all have pros and cons. Trying to boil important engineering decisions down to a tweet so that we can stay "on message" comes off like something someone would do if they were selling books or training or consulting services attached to a technology, which a priori gives them an agenda other than giving good advice. So to keep it short: help people pick the right tool for the job without an agenda.
  - bluejekyll 4y ago
    Rust is a programming language. It’s the right tool for the job of programming. It happens to have a lot of features that make it a very good programming language. I think you’re wrong about the language and community, though. It’s killer feature is it’s safety, be it memory, data race, or type. These are the reasons I was interested in learning the language. The fact that the tools make that easier is why I was able to struggle through the new concepts and actually be able to build useful things with it. If the fact that people enjoy something as a general community turns you off, that’s not the community’s problem.
  - jamincan 4y ago
    I think you have a point. Rust is primarily focused on being a systems language, and memory safety is the killer feature it brings to the table in that domain. But we know that Rust is being used in areas where its qualities as a systems language are less important. Why, for example, would a Python developer pick up Rust? Probably because of the really strict typing addressing a major pain point for most Python developers and the trait system being somewhat analogous to Protocols, which any Python developer who has chafed with the dynamic typing is almost certainly already familiar with. With good library support for interfacing between the two, it's a more natural coupling than most people would think on the face of it. That said, while I don't think a Python developer reaches for Rust because of memory safety, I do think it's still an important factor as it provides the guard rails that make it so someone who has primarily used a GC language and not had to concern themselves as much with managing memory can start using Rust knowing that the compiler is not going to let them accidentally shoot them in the foot when it comes to memory management.

pjmlp 4y ago

Rust's thread safety only applies to the special case of those threads accessing in process data segments. Rust's type system can do very little to help when those threads are accessing the same record on a database without transactions, OS IPC on shared memory, manipulating files without locks, handling hardware signals, handling duplicate RPC calls,... Yeah but that ultimately requires an unsafe block, kind of true, except no one reads the code of all crates they depend on, and the direct dependencies might be safe in what concerns the direct consumers.

bluejekyll 4y ago
This is a point that you constantly bring up in these threads, do you think most developers believe that data race safety should extend beyond the bounds of the process? One thing that Rust’s type system does allow you to do is define a consistent manner in which to access external systems, even add types that will mimic the same safety. Is it perfect? Will it protect you from a different process working against the DB? Will it enforce things in the other process? No. But will it give you higher level semantics to be able to construct a better model for operating against that external system? Yes.
- pjmlp 4y ago
  Yes, when they care about data consistency in distributed systems. Maybe many Rust devs don't care.
  - bluejekyll 4y ago
    So what is your point? You’re changing the goal posts on safety and it’s a pointless reductive argument. Even if we account for everything, solar storms will eventually flip bits unexpectedly. Does that make Rust’s guarantees worthless?
    - pjmlp 4y ago
      The goal posts stay on the same place. There are ways towards data corruption where Rust's fearsome concurrency is of no help.

nyanpasu64 4y ago

rustc rejects the resulting program if you mechanically factor out a function accessing &mut self, into a function holding mutable borrows to half the fields calling another function which access the other half of fields (or vice versa, the caller holding &field calling a method mutating other fields). This requires the more complex transformation of passing individual fields into the subfunction (more work, but sometimes easier to read), or waiting for Rust to add partial borrows. Note I've never actually hit this case myself, though I've heard it's an issue people run into.

estebank 4y ago
The third option is to use a wrapper type with internal mutability, but that is to be done very sparingly.