Rust is for Professionals • Hacker News Board

Re: Rust is for Professionals

#131

Post by ahelwer » Tue, Apr 13, 2021, 6:44 PM UTC

devit wrote: post #103

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…

It passes cargo check with this change. diff --git a/cli/src/test.rs b/cli/src/test.rs index ac4807bf..8b9882ab 100644 --- a/cli/src/test.rs +++ b/cli/src/test.rs @@ -410,16 +410,17 @@ fn parse_test_content(name: String, content: String, file_path: Option ) .map(|b| String::from_utf8_lossy(b).to_string()) .map(|s| escape_reserved_regex_chars(&s)); - let suffixHeaderPattern : Option = suffix + let suffixHeaderPattern…

Thank you for this! the .as_ref() seems to solve a lot of the problems, since I guess just doing a straight .map() takes ownership of the contained string.

Re: Rust is for Professionals

#132

Post by ajross » Tue, Apr 13, 2021, 6:51 PM UTC

estebank wrote: post #73

ajross wrote: post #62

Earlier quoted context omitted.

You're describing the desired behavior of the compiler, but not what it actually implements. In fact there are an infinite number of correct Rust programs which will never access memory incorrectly but which will still be rejected by the compiler, for the simple reason that Rust's authors, talented though they may be, have made no progress at all at solving the Halting Problem. What Rust actually accepts is a subset…

There are two problems here. Rust accepts a subset of correct programs that involve borrowing, that's absolutely true, but it gives you the tools to get around that: you either use Arc , where now you are in the same space that any refcounted GC language is in (with the extra flexibility that if you can "choose your guarantees"[1]), or use unsafe which lets you dereference memory freely in the same way that you would…

> The unstated problem is that there are patterns from other languages that are actually invalid

And this is why this argument persists. This is, to people outside the community, a semantic evasion:

1. It relies on a Rust-internal definition for "actually valid" (conforming to Rust's specific set of provability requirements) that doesn't correspond to what the rest of the world views as "correct" (not behaving incorrectly). Think about stuff like allocate-through-a-session-and-free-in-a-block paradigms (Apache was famous for this), or run-once-and-exit, or garbage collection, etc... Those things aren't "invalid" in any reasonable sense, they're just not what Rust programs do.

2. The definition for "valid" is (and this is my point above) entirely Rust-internal and ad hoc. It's not that we refuse to conform to your rules, really, it's that we don't know what they are!

Re: Rust is for Professionals

#133

Post by steveklabnik » Tue, Apr 13, 2021, 7:08 PM UTC

ajross wrote: post #132

estebank wrote: post #73

Earlier quoted context omitted.

There are two problems here. Rust accepts a subset of correct programs that involve borrowing, that's absolutely true, but it gives you the tools to get around that: you either use Arc , where now you are in the same space that any refcounted GC language is in (with the extra flexibility that if you can "choose your guarantees"[1]), or use unsafe which lets you dereference memory freely in the same way that you would…

> The unstated problem is that there are patterns from other languages that are actually invalid And this is why this argument persists. This is, to people outside the community, a semantic evasion: 1. It relies on a Rust-internal definition for "actually valid" (conforming to Rust's specific set of provability requirements) that doesn't correspond to what the rest of the world views as "correct" (not behaving incorr…

There's an anecdote about a similar effect in the article too:

> Fun fact: while at Mozilla I heard multiple anecdotes of [very intelligent] Firefox developers thinking they had found a bug in Rust's borrow checker because they thought it was impossible for a flagged error to occur." However, after sufficient investigation the result was always (maybe with an exception or two because Mozilla adopted Rust very early) that the Rust compiler was correct and the developer's assertions about how code could behave was incorrect. In these cases, the Rust compiler likely prevented hard-to-debug bugs or even exploitable security vulnerabilities. I remember one developer exclaiming that if the bug had shipped, it would have taken weeks to debug and would likely have gone unfixed for years unless its severity warranted staffing.

Sometimes people think that they're right and that the compiler is wrong, but often, (not not necessarily always!) it's that they forgot some important piece of context.

(Oh, and Rust absolutely can do "allocate in a block and free at once" stuff, or "run once and exit" stuff...)

Re: Rust is for Professionals

#134

Post by kzhukov » Tue, Apr 13, 2021, 7:20 PM UTC

wyldfire wrote: post #47

kzhukov wrote: post #41

Earlier quoted context omitted.

> safety-critical applications Nope, Rust is also not suitable for these tasks since it doesn't have a certified toolchain (e.g. ISO26262 for automotive or DO-178 for aerospace). > embedded Current LLVM-based compiler lacks support for some platforms (e.g. Xtensa for some ESP32 MCUs).

'Embedded' doesn't require supporting everyone's favorite microcontroller. Even if ESP32 is really popular, there's plenty of others. OBTW experimental xtensa backend is landing in upstream llvm lately.

That were just the examples when Rust is not really suitable as a drop-in replacement for C/C++. Of course, if your platform is well-supported by Rust compiler and you don't have to write safety critical applications, then using Rust is just a matter of choice.

I don't argue whether it's good or bad language. It's a quite interesting one with its own pros and cons. If it fits you, then it's great, but you should know its limitations.

Re: Rust is for Professionals

#135

Post by gher-shyu3i » Tue, Apr 13, 2021, 7:30 PM UTC

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…

Rust and Go are not in the same domain space, so it's a false dichotomy to compare the two.

It seems in your use case, Java would have been a viable (and potentially superior) alternative to golang.

Re: Rust is for Professionals

#136

Post by sanxiyn » Tue, Apr 13, 2021, 7:32 PM UTC

ajross wrote: post #132

estebank wrote: post #73

Earlier quoted context omitted.

There are two problems here. Rust accepts a subset of correct programs that involve borrowing, that's absolutely true, but it gives you the tools to get around that: you either use Arc , where now you are in the same space that any refcounted GC language is in (with the extra flexibility that if you can "choose your guarantees"[1]), or use unsafe which lets you dereference memory freely in the same way that you would…

> The unstated problem is that there are patterns from other languages that are actually invalid And this is why this argument persists. This is, to people outside the community, a semantic evasion: 1. It relies on a Rust-internal definition for "actually valid" (conforming to Rust's specific set of provability requirements) that doesn't correspond to what the rest of the world views as "correct" (not behaving incorr…

Rules are actually simple and not ad hoc. I in fact think Rust documentation should state rules and make them more prominent. In my experience, knowing the rules does not help you to keep them, but at least we will get less complaints of the sort "we don't know what the rules are".

To recap, here are the rules:

It is an error to access a place, when an access conflicts with a loan, and the loan is live. Access means source code construct to read or write, whether the construct is actually executed in runtime is irrelevant. Place is static approximation of a set of bytes in the memory. Place is either local (x), field (x.f), or upvar (local captured in closure). Indexing (x[i]) and method calls (x.m()) are approximated as local (x). Loan is either shared (&x) or mutable (&mut x). Read access conflicts with mutable loan, write access conflicts with all loans. Expression is live from the definition to the end of the containing statement. Declaration is live in connected region of control flow graph from the definition to potentially multiple last uses.

Re: Rust is for Professionals

#137

Post by estebank » Tue, Apr 13, 2021, 8:18 PM UTC

brundolf wrote: post #130

masklinn wrote: post #126

Earlier quoted context omitted.

> 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. That's… not exactly true. `Vec::new` is completely free so that's a different debate, but much as in C++ or C allocations in Rust are much more expensive than in managed languages: 1. system allocators genuinely suck, all of them, though some more than others (ii…

Interesting, I hadn't heard this before. Do you have any resources I could read? Edit: I do know that languages where strings are immutable use that fact to do lots of optimization (automatically sharing "copied" strings and just cloning reference-counters, for example), but you can accomplish some of this in Rust too with Rc or even persistent data structures if you really want to. And of course there are cases wher…

There are three strategies that other languages use automatically that you can also apply in Rust by hand: string interning, small string optimization and "Copy-on-write". For the first and second, you can use some existing crate like https://docs.rs/string-interner/0.12.2/string_interner/ and https://github.com/rust-analyzer/smol_str. For the later, you can use Cow https://doc.rust-lang.org/std/borrow/enum.Cow.html. I'm having trouble thinking of a case where Rc would be appropriate.

Re: Rust is for Professionals

#138

Post by Koshkin » Tue, Apr 13, 2021, 8:23 PM UTC

runarberg wrote: post #112

Koshkin wrote: post #74

Earlier quoted context omitted.

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 b…

> I don’t see

Neither do I.

Re: Rust is for Professionals

#139

Post by kazinator » Tue, Apr 13, 2021, 8:25 PM UTC

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.

straitjacket: related to the word strait.

Re: Rust is for Professionals

#140

Post by justsomeuser » Tue, Apr 13, 2021, 10:30 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…

Rust is more complex than Go, but when you are dealing with the inherent complexity in a problem, sometimes Rust can allow you to make the decision to take a larger chunk of that complexity and handle it at compile time (instead of at runtime with a crash->debug->fix feedback loop).

So you get sometimes stressful and frustrating writing sessions, coupled with more confidence in the runtime correctness. Also the more expressive type system can allow you to more closely match the domain, which helps when you add new features in the future as you can rule out certain invalid states or interactions.

I often feel you need to know the right conventions to write correct Go programs, where as Rust will just tell you you cannot run it.

I would get things done faster in Go for sure, but the compiled artifact would likely have more issues during runtime.