Rust is for Professionals • Hacker News Board

Re: Rust is for Professionals

#91

Post by iudqnolq » Tue, Apr 13, 2021, 4:39 PM UTC

ahelwer wrote: post #43

devit wrote: post #37

Earlier quoted context omitted.

That seems rather trivial, and I'm not sure how you could possibly have any issues with the borrow checker. Just do the first regex search, then escape into a String with regex::escape, then build a regex from the String and search with it. Of course what you are doing is probably wrong since you should use a string matching crate rather than escaping characters and using a regex matching crate.

Since it's so trivial, I would be quite happy for you to implement the feature for me! https://github.com/tree-sitter/tree-sitter/issues/982 Just lol at the idea that you won't run into borrow checker issues when dealing with strings though.

I wrote code recently to parse a file with regexes and generate rust code from it. It's get-the-job-done code, not super clean, but you might find it useful.

https://github.com/danielzfranklin/drm-fourcc-rs/blob/main/b...

Re: Rust is for Professionals

#92

Post by sanxiyn » Tue, Apr 13, 2021, 4:39 PM UTC

estebank wrote: post #81

sanxiyn wrote: post #72

Earlier quoted context omitted.

No, the rule I stated is what is actually implemented. Like all type checking technology, the rule is about static behavior, not dynamic behavior. So halting problem is irrelevant. Rust accepts all programs that follow the rule in static behavior. It's not a subset, and it's not a best effort to prove. It's the complete statement. "Access" means source code construct to read or write. Rust doesn't care whether the co…

I believe the "subset of correct code" refers to things like the current non-support for things like let (left, right) = (&mut foo[..split], &mut foo[split..]); where you have to rely on things like foo.split_at_mut(split), which are implemented as unsafe under the cover. I see these are limitations but not show-stoppers in any way.

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.

Re: Rust is for Professionals

#93

Post by sylvain_kerkour » Tue, Apr 13, 2021, 4:41 PM UTC

peppery-idiot wrote: post #79

sylvain_kerkour wrote: post #63

Earlier quoted context omitted.

As an indie developer, switching from Go to Rust for web APIs was extremely satisfying. At first there was a productivity loss, but after a few months the productivity was better than Go thanks to Rust's functional features which make it extremely pleasant to write business logic, and the type system catching bugs during development instead of production. You can read more about the experience here: https://kerkour.c…

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.

Re: Rust is for Professionals

#94

Post by sanxiyn » Tue, Apr 13, 2021, 4:41 PM UTC

ajross wrote: post #82

sanxiyn wrote: post #72

Earlier quoted context omitted.

No, the rule I stated is what is actually implemented. Like all type checking technology, the rule is about static behavior, not dynamic behavior. So halting problem is irrelevant. Rust accepts all programs that follow the rule in static behavior. It's not a subset, and it's not a best effort to prove. It's the complete statement. "Access" means source code construct to read or write. Rust doesn't care whether the co…

Link to the relevant spec then? Admittedly my intuition is a year stale at the moment, but I went looking hard for this at one point and found nothing other than source code.

No spec, because technical details are complex, but spec, when it is written, will just be an elaboration of "It is an error to access a place, when an access conflicts with a loan, and the loan is live". This has never changed since Rust 1.0, more than 5 years. Spec will just need to define "place" and "live" and that takes time.

Re: Rust is for Professionals

#95

Post by geodel » Tue, Apr 13, 2021, 4:42 PM UTC

The way I see is Rust for people who love to write about writing code quite a bit more than writing code itself.

Re: Rust is for Professionals

#96

Post by kbenson » Tue, Apr 13, 2021, 4:43 PM UTC

twobitshifter wrote: post #78

skohan wrote: post #17

Rust is currently my favorite language for personal projects. It's got a very good value proposition in terms of giving some high level features along with low level control and performance, great compatibility story, and the tooling and community is absolutely great. However , as the manager of a technical team, I would not choose it for professional projects. The learning curve is very steep, and to reap the benefi…

“Complexity is the enemy of execution.” - Tony Robbins I don’t think Tony ever did any coding, but you’re right that it still applies here. A google search shows complexity has many other enemies: security,reliability, agility, and progress itself. In most cases I think this is right, use Go and simple tools whenever you can. There are cases where complexity is unavoidable though, like when you’re trying to land a ro…

> don’t introduce the complexity when it’s unneeded.

Prediction is hard. Sometimes I start with something simple, and it ends up growing in scope until it's quite large and complex. Other times I start with something simple, and it stays simple.

So, what's worse, using a complex and/or strict language for something simple, or a simple and less strict language for something that ends up being very large and/or complex?

Interestingly, some people will probably read that last paragraph as my trying to make a point through implication. I suspect different people will assume I'm saying completely opposite things based on their own experience. Really, it's just hard, you get better at making the right choice as you go along, but you'll never always get it right.

Re: Rust is for Professionals

#97

Post by volta83 » Tue, Apr 13, 2021, 4:43 PM UTC

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…

> 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)

This took 2 min: https://play.rust-lang.org/?version=stable&mode=debug&editio...

and I don't recall what's the last time I used the regex crate.

I'm certainly doing all the regex stuff incorrectly, no idea how to match regex-reserved characters, no idea if I'm using the iterator API correctly (its the second example in the regex docs..), etc.

But the idea is simple, search the text for the regex, escape all the reserved characters, use that regex to search for occurrences of the same regex.

I guess that if you want a fully-vectorized, zero-allocation, zero-copy, multi-threaded, gpu... version of this that maxes out the theoretical peak of the hardware available, then you'll probably end up putting a considerable amount of work here.

But otherwise, for someone with literally 30 seconds of experience with the regex crate, it was as straightforward to implement as you mentioned. Just c&p their second example, and just added some glue. This is how I'd implement this in Python, or Java...

EDIT: other responses suggest cloning, but that seems to suggest that one has to explicitly and deliberately think about cloning. I instead just played a game of type golf using functions like `.to_string()` or `.collect` to "clone" stuff behind the scenes. My code is probably horrible, but is the first thing that came to mind.

Re: Rust is for Professionals

#98

Post by jvanderbot » Tue, Apr 13, 2021, 4:44 PM UTC

otabdeveloper4 wrote: post #23

jvanderbot wrote: post #11

Earlier quoted context omitted.

It is. It's not going to replace Python, and if maintenance is the metric, then "rewrite it in rust" is not the right move. But I do think Rust will gain traction, be a round a long time, and slowly become a complement to existing C/C++ ecosystems through wrapping and binding. I'm just not sure the other way will materialize. Until Rust can be used to feed back into C/C++ ecosystems and long-standing projects (like t…

At this point Rust is not the prmary ecosystem for anything. The important and exciting new things are written in C++, not Rust. Rust has no advantages over C++ once you know C++.

I agree that Rust isn't the primary ecosystem. But that's not a reason to dismiss Rust. If Rust could create components that can be incorporated into C/C++ systems, then we'd have a real contender for systems programming. The problem is Rust is strict, and it only goes one way, from C/C++ to Rust. That's the right first step!

Saying C++ is better than Rust "once you know it" doesn't make a lot of sense to me. No language is intrinsically better once mastered by a productive programmer.

Re: Rust is for Professionals

#99

Post by ajross » Tue, Apr 13, 2021, 4:45 PM UTC

estebank wrote: post #81

sanxiyn wrote: post #72

Earlier quoted context omitted.

No, the rule I stated is what is actually implemented. Like all type checking technology, the rule is about static behavior, not dynamic behavior. So halting problem is irrelevant. Rust accepts all programs that follow the rule in static behavior. It's not a subset, and it's not a best effort to prove. It's the complete statement. "Access" means source code construct to read or write. Rust doesn't care whether the co…

I believe the "subset of correct code" refers to things like the current non-support for things like let (left, right) = (&mut foo[..split], &mut foo[split..]); where you have to rely on things like foo.split_at_mut(split), which are implemented as unsafe under the cover. I see these are limitations but not show-stoppers in any way.

It's surely not a showstopper when it's on one line, but again the problem in practice is that those slices may be other operations or hidden behind other APIs, and happening at different depths in a complicated call tree, and you get an error only up at the top when what you're doing looks "clearly correct".

Yes, sure, the rule in question may be simple in the abstract (it's a compiler, after all -- they're just software doing straightforward things). But the ability for the poor programmer to detect which rule is being violated where is a lot more limited than the compiler is designed for. Thus the user with the upthread complaint, which is hardly unique.

I mean, at the end of the day if Rust wants to be an everyday language for this kind of everyday problem, the analysis paradigm needs to be communicated much better to everyday hackers (via docs, error messages, whatever). When Rust was new this seemed like just a technical problem to be solved with software maturity. I guess at this point after several years of regularly returning to play with Rust and being frustrated every time, I've mostly given up.

Re: Rust is for Professionals

#100

Post by brundolf » Tue, Apr 13, 2021, 4:46 PM UTC

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…

Short suggestion: If performance isn't critical, sprinkle some .clone()s in there on your strings and the borrow-checker will get off your back

Long suggestion: Working with strings in Rust requires that you have a C++ mental model of what strings are and what properties (in the abstract sense of the word) they have. Rust will make sure you can't misuse them, and it will make them as ergonomic as they can be within that C++-like model, but it's a fundamentally different concept from what you have in languages like C# and Java, and if you're trying to look at things from that other perspective, you're going to keep running into walls over and over.

More broadly, when you're using Rust you need to be in the basic mindset of a C++ programmer. From there Rust will make things significantly easier in many ways, but if you don't start with the right mental model, you're going to have a bad time. Strings are probably the most striking case of this because the way they get treated in virtually all higher-level languages is so wildly different from the way they get treated at the low-level.