Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust is mostly safety

graydon2.dreamwidth.org

Post reply on HN
Print view View original

321–330 of 474 posts

Re: Rust is mostly safety

#321

Post by newsat13 »

Manishearth wrote: post #203
nercury wrote: post #168

Earlier quoted context omitted.

Rust safety is ultimately a productivity boost. For example, if I have a big string, I may create a hashmap where both keys and values are references to some portions to that original string. Then, I may pass this hashmap to another function that will transform this hashmap into structs that contain reused portions of those string references. Rust compiler will make sure that the original string is not destroyed or m…

I wrote about this concept a bit in http://manishearth.github.io/blog/2015/05/03/where-rust-real... , with an example of a situation where in Rust I was able to make things work but in C++ I'd be totally terrified and use a shared_ptr or something. I like to say that Rust lets you toe the line perfectly, and dance near it as much as you want. C++ does not, since you're afraid you may accidentally cross it.

Is that a joke? Just doing a cursory reading of your blog post was terrifying to me and I could hardly understand why things are so complicated. It almost make it seem like programming is some 'puzzle' (I feel same way about boost library).

Re: Rust is mostly safety

#323

Post by pimeys »

kibwen wrote: post #299
pimeys wrote: post #237

Earlier quoted context omitted.

We've been in production with Rust almost six months already. Couldn't be happier with the language. Works like a charm with our consumers.

Can I ask which company you're with? Are you already listed on https://www.rust-lang.org/friends.html ?

I should add our company there soon...

Re: Rust is mostly safety

#324

Post by nercury »

newsat13 wrote: post #321
Manishearth wrote: post #203

Earlier quoted context omitted.

I wrote about this concept a bit in http://manishearth.github.io/blog/2015/05/03/where-rust-real... , with an example of a situation where in Rust I was able to make things work but in C++ I'd be totally terrified and use a shared_ptr or something. I like to say that Rust lets you toe the line perfectly, and dance near it as much as you want. C++ does not, since you're afraid you may accidentally cross it.

Is that a joke? Just doing a cursory reading of your blog post was terrifying to me and I could hardly understand why things are so complicated. It almost make it seem like programming is some 'puzzle' (I feel same way about boost library).

Few recent posts that I can see are about the compiler internals, design of a tracing GC and a crypto problem. These things might just be complicated anyway :)

Re: Rust is mostly safety

#325

Post by MustardTiger »

newsat13 wrote: post #320
EugeneOZ wrote: post #270

Earlier quoted context omitted.

When I write in Rust, I have feeling "that's how programming should work". I don't know how to express it in more scientific way. Errors handling, pattern matching, Result type - it's all how it should work. I know, some other languages have similar features, but Rust also has race-conditions protection (very important thing), good package manager out of the box, testing tool (cargo test), very smart compiler and gre…

I get the opposite feeling. When I write in Rust, I have feeling "that's how programming shouldn't work". The syntax is awkward and you are expected to spend weeks to get anything done. Ultimately, it seems to come down to Rust fans who have a sunken cost fallacy - I spent weeks learning this, so they think it is worth it.

Just because some people have a different opinion than you, doesn't mean it is due to fallacious reasoning. Ultimately, it seems to come down to rust haters who have a sunken cost fallacy - I spent years writing bad code in bad lanaguages, so I don't want to give that up to do things better.

Re: Rust is mostly safety

#326

Post by EugeneOZ »

newsat13 wrote: post #320
EugeneOZ wrote: post #270

Earlier quoted context omitted.

When I write in Rust, I have feeling "that's how programming should work". I don't know how to express it in more scientific way. Errors handling, pattern matching, Result type - it's all how it should work. I know, some other languages have similar features, but Rust also has race-conditions protection (very important thing), good package manager out of the box, testing tool (cargo test), very smart compiler and gre…

I get the opposite feeling. When I write in Rust, I have feeling "that's how programming shouldn't work". The syntax is awkward and you are expected to spend weeks to get anything done. Ultimately, it seems to come down to Rust fans who have a sunken cost fallacy - I spent weeks learning this, so they think it is worth it.

Few weeks is not enough time to get it when you don't like ideas of the language initially. I tried to read one dynamic language (will not name it to avoid fans fury) and realized very quickly that it's not my language. The only difference - I've been never thinking about "sunken cost fallacy" - there are languages I can use and there are others, and this diversity is necessary for healthy evolution.

Re: Rust is mostly safety

#327

Post by quotemstr »

curun1r wrote: post #170
tomjakubowski wrote: post #29

Earlier quoted context omitted.

> The right granularity for error handling is important, as well as making it easy to handle (abort? providing a default value? doing something else?) Option and Result achieve just about the best level of granularity I could imagine for error handling. Suppose you're trying to fetch a value from a map (use case for Option ), or read some value over some fallible I/O stream (use case for Result ). Want to abort if th…

I can see Option and Result irking people who don't want to embrace a more functional (programming) mindset. They can be kind of a pain to deal with procedurally without the and_then, or_else, map and such. The new '?' construction will definitely help with this. The appeal of exceptions, to me, has always been that they allow you to largely separate your error handling from your procedural logic since the catch bloc…

At least I'm not the only one disappointed in Rust's error handling strategy. I still firmly believe that exceptions are the best error handling strategy we've concocted so far and that Rust (and Go) represent a big step backwards in language design in this respect. It's still hard to get over Rust's default abort-on-OOM behavior that arises from the awkwardness that would arise from surfacing the possibility of allocation failure from every part of stdlib.

> the catch block

"The" catch block? For each function? Some people misunderstand exceptions and think that every function needs a catch block that cleans up resources allocated in that function. I hope you're not one of these people.

Idiomatic exceptional code has very few catch blocks. That's part of the appeal.

Re: Rust is mostly safety

#328

Post by EugeneOZ »

MustardTiger wrote: post #325
newsat13 wrote: post #320

Earlier quoted context omitted.

I get the opposite feeling. When I write in Rust, I have feeling "that's how programming shouldn't work". The syntax is awkward and you are expected to spend weeks to get anything done. Ultimately, it seems to come down to Rust fans who have a sunken cost fallacy - I spent weeks learning this, so they think it is worth it.

Just because some people have a different opinion than you, doesn't mean it is due to fallacious reasoning. Ultimately, it seems to come down to rust haters who have a sunken cost fallacy - I spent years writing bad code in bad lanaguages, so I don't want to give that up to do things better.

Please be more patient :) Flamewars will not help us, definitely. I'm nobody to criticize your way to communicate, but for the sake of Rust community reputation - please let's avoid "Rust vs X" wars.

Re: Rust is mostly safety

#329

Post by runT1ME »

stcredzero wrote: post #292

I do not mean to pick on C++: the same problems plague C, Ada, Alef, Pascal, Mesa, PL/I, Algol, Forth, Fortran ... show me a language with manual memory management and threading, and I will show you an engineering tragedy waiting to happen. I think if programming is to make progress as a field, then we need to develop a methodology for figuring out how to quantify the cost-benefit trade-offs around "engineering trage…

> A lot of these seem to be anti-synergistic with powerful language features and "nifty ideas."

I think this is a pretty big myth that only applies to some of these language features.

Re: Rust is mostly safety

#330

Post by zerofan »

dllthomas wrote: post #318
zerofan wrote: post #282

Earlier quoted context omitted.

Have you done much skydiving? I used to go three days a week, for a couple years, between 4-10 jumps a day at a place that had world class experts. My experience is that only beginning skydivers are constantly preaching safety. They go around (vocally) judging everything they see, and I think they do it because it alleviates their own fear. Instructors would teach safety, but really only to their own students. I thin…

> I think the safety aspect of Rust appeals to a lot of beginning programmers. Maybe, but it also appeals a lot to many of us experienced programmers who know how hard things can bite us. It's not so much that we can't get things right. It's that it's really expensive to revisit old assumptions when circumstances change, and it's phenomenal to be able to document more of these in a machine-checked way.

Please don't get me wrong - I would take safe over non-safe if everything else were equal. It's just that Rust made many other choices that are worse for me than what's in C++. Also, I think it would be very painful trying to explain some of Rust's features to my coworkers (who are generally very smart, but generally not interested in clever programming languages).

> It's that it's really expensive to revisit old assumptions when circumstances change, [...]

That's very dependent on the type of work you do. Over the last 23 years, my job has been to write many small programs to solve new problems. It's not expensive for me because I've aggressively avoided making monolithic baselines. I have medium sized libraries that I drag from project to project, but I can fix or rewrite parts of those as needed without breaking the old projects.

Post reply on HN