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

Rust is for Professionals

gregoryszorc.com

Post reply on HN
Print view View original

111–120 of 157 posts

Re: Rust is for Professionals

#111

Post by devit »

estebank wrote: post #105
ahelwer wrote: post #85

Earlier quoted context omitted.

Sure! So I'm trying to implement this feature: https://github.com/tree-sitter/tree-sitter/issues/982#issuec... And here's my branch (you can see the latest commits to see the file I'm modifying): https://github.com/ahelwer/tree-sitter/tree/testfile-separat... I haven't had a chance to go through and add clones everywhere, and will be away at a PT appointment for the next hour or so, but would appreciate any pointers…

The error output for your code is error[E0382]: use of moved value: `suffix` --> cli/src/test.rs:416:48 | 406 | let suffix = FIRST_HEADER_REGEX | ------ move occurs because `suffix` has type `std::option::Option `, which does not implement the `Copy` trait ... 414 | .map(|s| String::from(r"^===+") + &s + r"\r?\n([^=]*)\r?\n===+" + &s + r"\r?\n"); | ---------------------------------------------------------------------…

The latter change introduces an unnecessary clone(). The correct approach is to instead introduce a variable so that headerRegex can keep being a reference to either that variable or to HEADER_REGEX.

Re: Rust is for Professionals

#112

Post by runarberg »

Koshkin wrote: post #74
yagizdegirmenci wrote: post #58

> Rust Makes You a Better Overall Programmer I agree with that, but this applied to nearly any language for me. I started doing Python back when 2013, then i learned Go, i started writing better Python code, then i learned C, i started writing better Go code, then i learned Rust, i started writing better code in general. The more you play with other language the more you learn other programming paradigms, it changes…

Well, it's like saying that wearing a straightjacket makes you a better person.

A while back there was an interesting post about dry stone walls[1] (e.g. stone walls erected without any mortar). The top comment included this recommendation for beginners in stone masonry:

> When you pick up a stone from the pile, it MUST be placed on the wall. You either have to make it fit your intended spot through rotation or another adjustment, or you have to find another place on the wall for it. It CANNOT be placed back on the pile.[2]

The post explains that using this restriction makes you a better masonry overall because you train your self to the exact skills required. I find this a lot better analogy to restrictive programming languages then a straitjacket. When you restrict your self to always place a stone you pick up, you train your eyes to first evaluate which kind of stones you need next, and you train your self to find that stone in a pile. I don’t see exactly what you are training exactly when you wear a straitjacket.

1: https://news.ycombinator.com/item?id=20455860

2: https://news.ycombinator.com/item?id=20469600

Re: Rust is for Professionals

#113

Post by skohan »

pizza234 wrote: post #76

While I'm a big fan of Rust myself, there are a few points that lack rigour in this article (which are typical of "I love X" articles). Three points that struck me: - rust-analyzer is good (as in: it's functional, it's advancing, etc.etc.), but it's alpha; it's not a tool that can be considered a mature tool of a mature language. I often encounter issues while working on projects. - learning Rust is a serious problem…

> learning Rust is a serious problem IMHO, not only because it's hard in itself, but it's because it's hard to structure a plan to learn it.

I totally agree. One of the issues is that there are so many complex and novel topics that you will run into in your first week of working on a real project, and you have to wrap your head around all of them to some degree to be able to progress. If there is an obvious and clear progression path, I did not discover it.

> the complexity of programming is very, very far from Python

I could not agree more. These languages are deeply philosophically different in my mind.

Re: Rust is for Professionals

#114

Post by Jweb_Guru »

ahelwer wrote: post #12

Here I am on day three of an attempt to modify a rust program with logic that would have taken about twenty minutes to implement in C# or Java. It has to do with operations on strings (use a regex to find a string in some text, escape all the regex-reserved characters in that string, then use the string as a regex to find other occurrences of itself in the text) so I get that I'm really thrown into the borrow-checker…

As someone who's been there, I strongly recommend asking for help (maybe posting this on HN counts?). Bashing your head against the wall against Rust without some correct code to look at is not (IMO) a great way to learn the language... I definitely get the appeal, as someone who hates asking for help, but it's just not worth it in this case, especially when you're starting out and aren't even sure what terms to look for.

Re: Rust is for Professionals

#115

Post by f154hfds »

I have to concur with the author on Rust. I remember when I read the book a few years ago I had just spent several years doing professional development in C++ and Python, and had recently discovered the GIL much to my dismay. After reading the Book I felt like I stepped through some proverbial door and could never go back. The features by themselves aren't really that remarkable but all of them together in one package - every time I use Python or C++ now I want Rust syntax, tooling, etc.

Now, my biggest critique - because of Rust's emphasis on static dispatch and monomorphization (good decisions all around if you ask me), plus the fact that lifetimes provide their own type dimension - I find that open source projects can have absolutely monstrous types, impossible to reason about. It's tough because I prefer the WYSIWYG templating Rust offers over C++ duck typing any day but many of these crates' types are too complex. In fairness, most of the most egregious cases were due to the lack of const generics and those cases are quickly improving.

As an example, I've been playing around with websockets recently and ran into this type: https://docs.rs/websocket/0.26.2/websocket/server/upgrade/st...

Note 4 different impls, each with its own generic requirements! I'm sure each case makes sense somehow, but it sure complicates my life when I want to use a function and find it isn't implemented for _my_ WsUpgrade.

Re: Rust is for Professionals

#116

Post by brundolf »

ocschwar wrote: post #21
CJefferson wrote: post #16

Earlier quoted context omitted.

While this can be painful, my basic suggestion -- clone more. The temptation is to never clone, butin C++ people run copy constructors all the time without thinking about it (as they are called automatically).

Cloning means runtime inefficiency, but the cost is so pathetically small compared to the amount of code we run in Python and Java with their larger footprints. Yes. Clone more.

This is one of the psychological traps I've experienced writing Rust: in Python or Java you can't hope to make things more efficient at a certain point. You couldn't get clever with string re-use if you tried, etc. So you're content to just move forward and be practical.

Whereas in Rust you know that it's probably possible to use a &str there instead of a String. If you just bang on it a little longer, you can make it just a bit more optimal. The clone()s and the Vec::new()s are all explicit, making them feel heavier than those other languages, when in reality they're still quite a bit lighter.

You usually don't have to optimize them out! Your code will probably be faster than Java even with a bunch of clones, etc! But there's this temptation that's really hard for programmers to resist, to sink hours and hours into making things just slightly more optimal given the opportunity. You have to consciously talk yourself out of that if you want to be productive.

Re: Rust is for Professionals

#118

Post by steveklabnik »

pantulis wrote: post #44

"(...) Rust feels more like Python than C. (...)" This feels like a very powerful assertion. Does the rest of the HN audience agree with this? If this is true, how long did it take?

It really depends on what those languages mean to you. I don't think that you can answer these sorts of questions in the general case.

You can sorta kinda compare programs though. I had a discussion about this on HN last year. Note that this is an extremely small sample size, but you know https://news.ycombinator.com/item?id=22712441

I wrote an updated version half a year ago https://news.ycombinator.com/item?id=24595081

YMMV. It depends on a lot of factors.

Re: Rust is for Professionals

#119

Post by skohan »

sylvain_kerkour wrote: post #93
peppery-idiot wrote: post #79

Earlier quoted context omitted.

For web work, are there benefits to using Rust over a garbage collected language that also benefits from a similar type system?

Do you have a specific language in mind? Honestly, I don't feel that I spend time managing memory in Rust: I use ARC pointers for long-lived shared object (Database connections pool, mailer...) and otherwise the ownership is pretty straightforward during the lifecycle of a request, data is moved from the top layer (HTTP handlers) to the bottom (Repositories to access Database) and back for the response.

> I use ARC pointers for long-lived shared object (Database connections pool, mailer...)

Does that mean you basically enforce sequential database reads? Seems like a bottleneck if your server is concurrent

Re: Rust is for Professionals

#120

Post by sanxiyn »

ajross wrote: post #106
sanxiyn wrote: post #92

Earlier quoted context omitted.

Yes, but the rule is still complete. What is going on is "place" is currently defined to be local x, or field x.f, or index x[i], but all x[i] are merged to x[*]. Rust's so-called NLL changed definition of "live". The point is, the rule is simple, formal, and complete. It is neither an ad hoc rule nor a best effort prover.

> What is going on is "place" is currently defined to be Not to belabor this growing thread, but here's the disconnect. I complained the rules were ad hoc and complicated, you replied that they were simple, and when challenged on an edge case your treatment is to add another clause to re-define a term you used in isolation earlier . That's what "ad hoc and complicated" means.

"place" and "live" have their respective intuitive definitions. To clarify, "place" is a set of bytes in the memory. "live" means it is used again. But both are runtime concepts, so Rust compiler needs to compute static approximation of these runtime concepts. This static approximation is what is complex and changing. But the principle is simple.

Actually, my elaboration of "place", local/field/index, is nearly complete. The only thing missing is upvar, which is local captured in closure. Pre-NLL "live" is simple: expression is live from the definition to the end of the containing statement, and declaration is live from the definition to the end of the containing block. Post-NLL "live" is connected region of control flow graph from the definition to potentially multiple last uses. Really, that is the whole story.

There are two changes currently in development. One changes definition of "place" to include field captured in closure, in addition to local captured in closure. The other is more drastic, changing definition of "live": a loan is live where the loan is origin of a variable and the variable is live. This is great, because current approximation is equivalent to union of all origins.

Post reply on HN