15 ms·

These zero information statements and intellectually dishonest marketing is what keeps rust a fringe language. > it's just that you're not used to doing things

These zero information statements and intellectually dishonest marketing is what keeps rust a fringe language. > it's just that you're not used to doing things properly, and Rust forces you to do things properly. Many patterns that rustc refuses aren't inherently wrong. They are because 1) you have to aid lifetime inference and memory management unlike GC languages 2) All safe patterns can't be verified by compiler, especially if threads are involved. The cult like mentality of rust spammers on hackernews is making many people sceptic about it. Rust is actually well designed language for what it does. But stop pretending rust is God.

arcticbull 6y ago
> Many patterns that rustc refuses aren't inherently wrong. They are because 1) you have to aid lifetime inference and memory management unlike GC languages 2) All safe patterns can't be verified by compiler, especially if threads are involved. It's not about the patterns being wrong, it's about the patterns being verifiable and having a compiler that's on your side, not on the side of watching the world burn. The difference between C's laissez-faire approach, where no new warnings are added and anything's whatever you want it to be vs. a subset of provably correct things you can opt out of at your discretion. Yes, it's not going to catch all edge cases, yes it's not perfect, however the idea people are behind is that it represents a fundamental change from "I'm sure the smart engineer knows what they're doing" to "hold on now, let's assume they don't, or will forget in 6 months, or some new person is going to have zero context." That model maps much better to the reality we have vs. the one we wish we had. My opinion is hardly culty, I write ObjC at my day job at $BIGCO, I've done plenty of Swift, I've written plenty of embedded C, plenty of C++, implemented a ton of stuff in VHDL. Rust is my go-to for personal projects. It's genuinely better. Not perfect, better. And better's what I'm looking for.
- moldavi 6y ago
  Ive always wondered something: comparing to languages like Swift, is Rust really better if it takes so much cognitive overhead and architectural backflips to work around the borrow checker's limitations? Couldnt we be spending that time adding features, or optimizing the parts of the program that the profiler shows us are inefficient? Using Rust seems like it would make sense for an extremely low-level performance-sensitive application, but do people use it for higher level things? If they do, why?
  - nevi-me 6y ago
    I think after a while writing the language, you're able to reason about your object memory with little friction from the compiler. On the Rust-written projects that I work on, I rarely have significant compiler errors that impede on my efficiency in adding new features. After a while, you know that you're mutably borrowing something, or that you're crossing a thread boundary and are carrying something not thread-safe along. Maybe like other low-level languages there's a large learning cost, but it gets better after a while.
  - fasterthanlime 6y ago
    People definitely use it for higher-level things, and it's nice there as well - not the same level of comfort as a garbage-collected language, but still very nice. When writing code that isn't that performance-sensitive, cloning is often an option (and gets you past a lot of grief with lifetimes), so is reference counting, etc. Rust's set of rules just means you can never, for example, accidentally hold a reference to a value that's been freed - it'll error out, and then you can pick whether you meant to borrow it, to share ownership with reference counting, or to clone it.
  - heldrida 6y ago
    That's a very good question and deserves its own thread. Personally, I remember an interview of Keith Haring just before he passed away; he wasn't sleeping much to put as much of his ideas out as quickly as he could, he was about to die. He said something like he'd rather spend the time creating then perfecting his art. I don't know exactly what his words were but what he said made a lot of sense to me. The popularity of C++ keeps growing for some reason and Swift offers a great dev experience! On top of that, the layoffs in the Servo team is quite telling about how profitable the work they've put was.
  - Measter 6y ago
    I would pick Rust if I had the choice and libraries were available. Personally, I've found that the borrow checker for the most part doesn't get in the way. But part of the reason for that is because I've used Rust enough to know what the borrow checker expects, so I would just design things in a way that get accepted in the first place without having to think about it. Someone new to the language won't have that prior knowledge, and will be more likely to run into the borrow checker and get frustrated because of it. So with that in mind, I don't really find the cognitive overhead to be high when writing Rust. I also find that I like having the control over what can mutate what, and knowing that information by looking at the function signatures or variable definition. Also, Rust has all of the features I liked in Haskell when I tried it, while putting them into a package that is more familiar and comfortable to me.
- fasterthanlime 6y ago
  Not to get in the way of a good time but - your conversation with opposing viewpoints perfectly illustrates the conflict I'm trying to describe in the article. Rust will catch mistakes you would've let through, but it'll only agree to verify a subset of all valid programs.
- avasthe 6y ago
  > It's not about the patterns being wrong, it's about the patterns being verifiable and having a compiler that's on your side, not on the side of watching the world burn. Yeah, but not all programs genuinely need to be multithreaded [0] that too with memory sharing, and even in a program very few data is shared. And a lot of patterns can't be verified by compiler to be amenable for static memory management. That's a tradeoff. I am not telling rust's cognitive overhead makes it unsuitable for everything. It definitely has a place. But unlike what a lot of people on HN tend to say, rust is not the perfect language for everything. Languages like OCaml deserved a significant portion of hype that rust gets now. But there is no mozilla and no HackerNews spamming taskforce behind OCaml. On the positive side, all 5 companies using OCaml pay well ;) [1] As a user, I don't want your code to exhaust all my cores, unless it is a batch job. I'd rather urge to choose better algorithms and data structures for the job and many times parallelism is just unnecessary.
- blub 6y ago
  In my case if I were to use Rust for a personal project, that would be a clear case of thinking inside the box. I think this is because I use C++ a lot and Rust is more of the same, except with fewer libraries & domain support but safer and more restrictive. For something where one has the freedom to pick anything they want, I'd take advantage and use something more user-friendly and with even less restrictions like Python or Swift. Although for heavy lifting I may still reach for C++ because of the massive ecosystem. Languages like Rust or Ada with their heavy reliance on specific "annotations" to ensure safety are designed for professional teams that must fulfill certain quality attributes.

arcticbull 6y ago

> Many patterns that rustc refuses aren't inherently wrong. They are because 1) you have to aid lifetime inference and memory management unlike GC languages 2) All safe patterns can't be verified by compiler, especially if threads are involved. It's not about the patterns being wrong, it's about the patterns being verifiable and having a compiler that's on your side, not on the side of watching the world burn. The difference between C's laissez-faire approach, where no new warnings are added and anything's whatever you want it to be vs. a subset of provably correct things you can opt out of at your discretion. Yes, it's not going to catch all edge cases, yes it's not perfect, however the idea people are behind is that it represents a fundamental change from "I'm sure the smart engineer knows what they're doing" to "hold on now, let's assume they don't, or will forget in 6 months, or some new person is going to have zero context." That model maps much better to the reality we have vs. the one we wish we had. My opinion is hardly culty, I write ObjC at my day job at $BIGCO, I've done plenty of Swift, I've written plenty of embedded C, plenty of C++, implemented a ton of stuff in VHDL. Rust is my go-to for personal projects. It's genuinely better. Not perfect, better. And better's what I'm looking for.

moldavi 6y ago
Ive always wondered something: comparing to languages like Swift, is Rust really better if it takes so much cognitive overhead and architectural backflips to work around the borrow checker's limitations? Couldnt we be spending that time adding features, or optimizing the parts of the program that the profiler shows us are inefficient? Using Rust seems like it would make sense for an extremely low-level performance-sensitive application, but do people use it for higher level things? If they do, why?
- nevi-me 6y ago
  I think after a while writing the language, you're able to reason about your object memory with little friction from the compiler. On the Rust-written projects that I work on, I rarely have significant compiler errors that impede on my efficiency in adding new features. After a while, you know that you're mutably borrowing something, or that you're crossing a thread boundary and are carrying something not thread-safe along. Maybe like other low-level languages there's a large learning cost, but it gets better after a while.
- fasterthanlime 6y ago
  People definitely use it for higher-level things, and it's nice there as well - not the same level of comfort as a garbage-collected language, but still very nice. When writing code that isn't that performance-sensitive, cloning is often an option (and gets you past a lot of grief with lifetimes), so is reference counting, etc. Rust's set of rules just means you can never, for example, accidentally hold a reference to a value that's been freed - it'll error out, and then you can pick whether you meant to borrow it, to share ownership with reference counting, or to clone it.
- heldrida 6y ago
  That's a very good question and deserves its own thread. Personally, I remember an interview of Keith Haring just before he passed away; he wasn't sleeping much to put as much of his ideas out as quickly as he could, he was about to die. He said something like he'd rather spend the time creating then perfecting his art. I don't know exactly what his words were but what he said made a lot of sense to me. The popularity of C++ keeps growing for some reason and Swift offers a great dev experience! On top of that, the layoffs in the Servo team is quite telling about how profitable the work they've put was.
- Measter 6y ago
  I would pick Rust if I had the choice and libraries were available. Personally, I've found that the borrow checker for the most part doesn't get in the way. But part of the reason for that is because I've used Rust enough to know what the borrow checker expects, so I would just design things in a way that get accepted in the first place without having to think about it. Someone new to the language won't have that prior knowledge, and will be more likely to run into the borrow checker and get frustrated because of it. So with that in mind, I don't really find the cognitive overhead to be high when writing Rust. I also find that I like having the control over what can mutate what, and knowing that information by looking at the function signatures or variable definition. Also, Rust has all of the features I liked in Haskell when I tried it, while putting them into a package that is more familiar and comfortable to me.
fasterthanlime 6y ago
Not to get in the way of a good time but - your conversation with opposing viewpoints perfectly illustrates the conflict I'm trying to describe in the article. Rust will catch mistakes you would've let through, but it'll only agree to verify a subset of all valid programs.
avasthe 6y ago
> It's not about the patterns being wrong, it's about the patterns being verifiable and having a compiler that's on your side, not on the side of watching the world burn. Yeah, but not all programs genuinely need to be multithreaded [0] that too with memory sharing, and even in a program very few data is shared. And a lot of patterns can't be verified by compiler to be amenable for static memory management. That's a tradeoff. I am not telling rust's cognitive overhead makes it unsuitable for everything. It definitely has a place. But unlike what a lot of people on HN tend to say, rust is not the perfect language for everything. Languages like OCaml deserved a significant portion of hype that rust gets now. But there is no mozilla and no HackerNews spamming taskforce behind OCaml. On the positive side, all 5 companies using OCaml pay well ;) [1] As a user, I don't want your code to exhaust all my cores, unless it is a batch job. I'd rather urge to choose better algorithms and data structures for the job and many times parallelism is just unnecessary.
blub 6y ago
In my case if I were to use Rust for a personal project, that would be a clear case of thinking inside the box. I think this is because I use C++ a lot and Rust is more of the same, except with fewer libraries & domain support but safer and more restrictive. For something where one has the freedom to pick anything they want, I'd take advantage and use something more user-friendly and with even less restrictions like Python or Swift. Although for heavy lifting I may still reach for C++ because of the massive ecosystem. Languages like Rust or Ada with their heavy reliance on specific "annotations" to ensure safety are designed for professional teams that must fulfill certain quality attributes.