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

My Struggles with Rust

compileandrun.com

Post reply on HN
Print view View original

161–170 of 329 posts

Re: My Struggles with Rust

#161

Post by twic »

p0nce wrote: post #111
ajross wrote: post #39

Earlier quoted context omitted.

I think the complaint is more that Rust has seemingly tried very hard to make error handling "simple". But in the process it has managed to invent a whole series of new idioms and special syntax that is alien to pretty much everyone. There's a thread in /r/rust about this same article where you can look and see people suggesting all sorts of ways to write this that are split into clear sedimentary layers depending on…

That and the bizarre thinking that ".unwrap" is a perfectly ok thing to write in some cases (don't worry it will never make it to production!). No, ".unwrap" turns input errors into bugs, and there is no production code where this is more desirable than an exception.

I don't get it. .unwrap() turns an undesirable situation into printing an error message and exiting with a nonzero status. There are plenty of situations where that is exactly what you want, and not a bug at all.

For example, in my production Rust code, i deal with all errors in reading and parsing config files with .unwrap() or .expect(). If a program cannot read its config file at startup, it cannot correctly do its job, and so the only correct thing for it to do is to abort.

Have i misunderstood what you were trying to say?

Re: My Struggles with Rust

#162

Post by pjmlp »

std_throwaway wrote: post #127
kstenerud wrote: post #122

One thing I've found with rust is that you struggle struggle struggle trying to do a simple task, and then finally someone says "Oh, all you need to do is this". Rust has already reached the point where it leaves the world behind. Only the people who have been there since the early days really understand it, and getting into rust gets harder and harder as time goes on. Yes, there's some awesome documentation, and the…

How is this problem solved for C++?

Sadly by what also helped it gain adoption but also hinders the language's safety, copy-paste compatibility with C (to a certain extent).

Meaning that many C++ applications, even nowadays, are actually C compiled with C++ compiler (not even classes are used).

So the transition between skill levels is quite gradual.

For me it is hard to tell, because I know the language since the C++ARM days, which means it had a feature size similar to Object Pascal and actually smaller than Ada.

Back then compiler writers even though it was easier to implement Ada compilers than C++ ones.

So slowly we got used to the new features, being discussed in books or programming magazines.

Re: My Struggles with Rust

#163

Post by sidlls »

djhworld wrote: post #34

The author doesn't really justify why he needed to port the python script to rust in the first place. Pulling down some JSON, doing a bit of transformation and sending alerts seems like a perfect candidate for a high level language, I don't see any reason why you would port it to Rust unless you had significant performance concerns

Before I convinced co-workers that we could use Rust in production (where we'd normally have used Python), I wrote a lot of this kind of script (where, I'd agree, a higher-level language like Python is a better choice) in Rust and Python so that they'd be able to have some idea of what the differences were and how Rust works. It seems like a great exercise for the very conservative or intimidated programmer to ease into more low-level programming.

Re: My Struggles with Rust

#164

Post by pjmlp »

cornstalks wrote: post #144
ahoka wrote: post #123

Earlier quoted context omitted.

Exceptions don't need RTTI and have only runtime cost when thrown.

Exceptions actually can need RTTI, though not necessarily all of the RTTI that things like provide. For some details, see the -fno-rtti flag for GCC, for which the documentation says[1]: Disable generation of information about every class with virtual functions for use by the C++ runtime type identification features (`dynamic_cast' and `typeid'). [...] Note that exception handling uses the same information, but it wi…

That is a compiler specific implementation, the ANSI C++ standard doesn't require it.

Re: My Struggles with Rust

#165

Post by msangi »

A common theme I find in posts criticizing Rust is that their authors take a problem they've already solved in another language, try to blindly convert it in non-idiomatic Rust and then complain because things get awkward.

I think that it's important to pick the right tool for the job and to follow the patterns of the tool you're using.

Is Rust the right tool for the task described in the post? Probably not, but it could still be used albeit it will always require more work than Python.

What's really missing is a resource showing common problems and their idiomatic solutions.

Re: My Struggles with Rust

#167

Post by guipsp »

MikkoFinell wrote: post #158
erickt wrote: post #31

Hello Justin Turpin! Sorry to hear your struggles with rust. It's always going to be a bit more verbose using rust than Python due to type information, but I think there are some things we could do to simplify your code. Would you be comfortable posting the 20 line code for us to review? I didn't see a link in your post. Anyway, so some things that could make your script easier: * for simple scripts I tend to use the…

I cant even opt out of using exceptions? Good thing I didn't waste my time with this lang.

expect is panic, not an exception

Re: My Struggles with Rust

#168

Post by allengeorge »

kstenerud wrote: post #122

One thing I've found with rust is that you struggle struggle struggle trying to do a simple task, and then finally someone says "Oh, all you need to do is this". Rust has already reached the point where it leaves the world behind. Only the people who have been there since the early days really understand it, and getting into rust gets harder and harder as time goes on. Yes, there's some awesome documentation, and the…

I don't know if that's quite true. While Rust is very deep, I've found that you can get quite far with a few crucial pieces of info (note that I don't speak about generics or macros; haven't worked a lot with them):

* All variables are expected to be sized. So, learn what's sized and what isn't.

* Understand traits and how they add functionality to types. Have a small dictionary of common ones (From, Into, Debug, etc.)

* Learn how to write blanket implementations for traits. This can make your code lighter-weight. You also learn to start looking for blanket implementations.

* Encapsulate ownership details when possible. I'm not sure about the best way to explain this, but...at a high level it means "structure your types so that you avoid sharing ownership".

Re: My Struggles with Rust

#170

Post by kibwen »

p0nce wrote: post #139
kibwen wrote: post #136

Earlier quoted context omitted.

panics aren't for recoverable errors, in any circumstances. It is technically possible to "halt" the unwinding from a panic, but 1) that's intended for C interop, 2) the feature has been deliberately designed to make your life hell if you try to use it to emulate recoverable exceptions, and 3) Rust makes no guarantees that panics will unwind at all, it is entirely legal for a user to configure panics so that they all…

> panics aren't for recoverable errors, in any circumstances. And I understand that. Hence why unwrap everywhere is harmful.

Er, it was a response to this line of yours:

> Absolutely but using the same mechanism (unwrap/panic) for both types of errors - recoverable and recoverable

Nobody is using panics with the intent to recover, in the classic sense of "recoverable error".

Post reply on HN