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

Rust for Professionals

overexact.com

Post reply on HN
Print view View original

81–90 of 103 posts

Re: Rust for Professionals

#81

Post by pjmlp »

aussiesnack wrote: post #59
nicoburns wrote: post #36

Earlier quoted context omitted.

> Rust is harder than any other mainstream language to do that in. I’d argue C and C++ are both harder. It’s hard to even get these to build once you move past trivia examples (including libraries etc). > I find the denial of Rust's difficulty (and not even centred on the borrow checker - it's the use of just about every commmon library) just very very strange Some of us just didn’t find it that hard. Like, I get tha…

> > Rust is harder than any other mainstream language to do that in. > I’d argue C and C++ are both harder. It’s hard to even get these to build once you move past trivia examples (including libraries etc). Agree I overstated that. What I mean is that, out of the difficult to learn languages, Rust is the only one whose community for opaque reasons denies the difficulty. > Some of us just didn’t find it that hard. Why…

I know C and C++ since the mid-90's, and have delivered several products into production with them, still have issues today when dealing with some cases where the borrow checker should be fine (from human borrow checker point of view), but it doesn't get it.

There are also these patterns one has to learn like applying references to numbers in some corner cases, e.g. func(&123), and the fact polominus is being developed shows there is still room for improvement on the borrow checker logic.

Re: Rust for Professionals

#82

Post by pjmlp »

joaquincabezas wrote: post #2

I keep saving these Rust resources for a near future... Am i the only one?? I really hope to start using Rust in 2023, probably for some kind of API gateway experimentation

I can only justify Rust for hobby coding, none of the stuff I do professionaly cares about what Rust offers, compiled managed languages are good enough and have decades of software maturity, and using Rust as translation layer between them and C++ libraries hinders more than it helps.

Re: Rust for Professionals

#83

Post by nicoburns »

jandrewrogers wrote: post #60
nicoburns wrote: post #36

Earlier quoted context omitted.

> Rust is harder than any other mainstream language to do that in. I’d argue C and C++ are both harder. It’s hard to even get these to build once you move past trivia examples (including libraries etc). > I find the denial of Rust's difficulty (and not even centred on the borrow checker - it's the use of just about every commmon library) just very very strange Some of us just didn’t find it that hard. Like, I get tha…

C is a simple language. Many people have quickly become proficient at it with only K&R to work from, and that is a thin book. The C language has many deficiencies but I don’t think many people would characterize it as difficult to learn among its peer programming languages. It has very few concepts that you need to learn. C++, on the other hand, is exceedingly complex and a difficult language to become proficient in,…

C is a simple language if you only want to do simple things with it (like say, numerical calculations). As soon as you want to do anything more sophisticated you find all the complexity in other languages and more comes back just as library APIs rather than language-level features.

Re: Rust for Professionals

#84

Post by avaldez_ »

tmtvl wrote: post #5
joaquincabezas wrote: post #2

I keep saving these Rust resources for a near future... Am i the only one?? I really hope to start using Rust in 2023, probably for some kind of API gateway experimentation

I saved up Common Lisp resources for a few years and in 2022 I finally decided to sit down and learn it. It was entirely worth it, so I recommend you sit down to learn Rust one weekend. In fact, do it next weekend. Getting started on anything is always better done sooner than later.

Nice. I'm doing exactly that with CL, one of my new year's resolutions. Would you mind to share your resources?

Re: Rust for Professionals

#85

Post by saghm »

coderenegade wrote: post #63
wrs wrote: post #32

An important “unblocker” for me when learning Rust after decades of other languages was internalizing that assignment is destructive move by default. Like many Rust intros, this sort of glides past that in the “ownership” section, but I felt like it should be a big red headline. If you’re coming from C++ especially, where the move/copy situation is ridiculously confusing (IMO), but also from a simpler “reference by d…

I found the copy/move situation in Rust to be far less intuitive than in C++. In C++, move semantics are obvious because they rely on std::move and the && operator, whereas in Rust, similar behavior seemed to depend on the object type. Even more confusingly, Rust has its own move operator as well, despite destructive move being the default behavior for assignment. I found it frustrating enough that I put the language…

I'd be pretty surprised if the C++ move semantics were considered more intuitive by someone not familiar with either and then learning both for the same time. Rust's semantics do depend on the type in that anything that implements Copy will be implicitly copied rather than moved, but I'm sure I understand why that's unintuitive. I'm also not sure what you mean by Rust having it's own move operator; the only thing I can think of is the `move` keyword used for indicating that closures should capture by move rather than by reference, but it's not used outside of closures as far as I'm aware, so I suspect that the confusion here is more due to expecting things to behave like C++ rather than the Rust semantics being "unintuitive" in a vacuum.

At a high level, I think the most unintuitive part of moving in C++ compared to Rust is that it can silently degrade into a copy without anything indicating it. In Rust, trying to use a value after it's been moved will give you a compiler error, at which point you can reconsider whether you do in fact want to explicitly copy or if you made a mistake or need to refactor. In C++, the only way I'm aware of to verify whether a value is actually moved or not is to use a debugger. The benefit for requiring explicit copies is similar to having bindings be immutable by default and requiring an explicit `mut` annotation; if you start out enforcing the constraint that things should be moved or immutable, fixing it later if you find out it won't work that way only requires adding `.clone()` or `mut` in one place. On the other hand, if you start out with implicit copies or mutability by default and then want to change it later, it can be a lot more work to refactor the places where the variable is used to not violate this, and it may not even be possible in some cases.

Re: Rust for Professionals

#86

Post by scotty79 »

legerdemain wrote: post #79
scotty79 wrote: post #76

Earlier quoted context omitted.

How does it look like? Do you mean this? https://haibane-tenshi.github.io/rust-reborrowing/ If you assume = always moves you can just never use automatic reborrowing (do &mut * instead) and you'll loose nothing. I don't think that's a very common pattern, fully optional and it can be just treated as another exception to the rule, just like Copy types. You don't have to manually write .copy() in some cases, and you do…

I've posted similar minimal examples before. The first one triggers a move (and then fails to compile), while the second one triggers a reborrow. Sure, you can explicitly write out every instance of reborrowing with `&mut *`. That would require you to understand every instance that triggers it, and would also be unbelievably noisy, since automatic dereferencing and automatic reborrowing are actually incredibly common…

Ok. So that's just triggering auto-insertion of &mut *

It's completely optional fearure. You don't have to rely on it. Like auto-insertion of semicolons in JS maybe it's better if you don't. Although likelihood of this biting you is way lower than in case of relying on semicolons autoinsertion.

Re: Rust for Professionals

#87

Post by scotty79 »

puffoflogic wrote: post #80
scotty79 wrote: post #76

Earlier quoted context omitted.

How does it look like? Do you mean this? https://haibane-tenshi.github.io/rust-reborrowing/ If you assume = always moves you can just never use automatic reborrowing (do &mut * instead) and you'll loose nothing. I don't think that's a very common pattern, fully optional and it can be just treated as another exception to the rule, just like Copy types. You don't have to manually write .copy() in some cases, and you do…

There's a way of thinking of `Copy` which makes it not an exception: `Copy` variables/places are simply not rendered invalid/uninitialized when they are the source of a move operation, unlike non-`Copy` sources. They're still moved from bitwise like all other rust values!

I like it!

Re: Rust for Professionals

#88

Post by kika »

andsoitis wrote: post #29
kika wrote: post #9

Earlier quoted context omitted.

My experience with Java ended circa 2000 and I never wrote a single line in Kotlin. But I read these examples without noticeable issues.

what have you been programming in the past 20 years?

In approximate chronological order: Python, Lisp, C++ (ATL and Qt), Erlang, JavaScript, TypeScript, PureScript, Rust.

Re: Rust for Professionals

#89

Post by tmtvl »

avaldez_ wrote: post #84
tmtvl wrote: post #5

Earlier quoted context omitted.

I saved up Common Lisp resources for a few years and in 2022 I finally decided to sit down and learn it. It was entirely worth it, so I recommend you sit down to learn Rust one weekend. In fact, do it next weekend. Getting started on anything is always better done sooner than later.

Nice. I'm doing exactly that with CL, one of my new year's resolutions. Would you mind to share your resources?

Besides the obvious Big 4 (Gentle Intro, PAIP, On Lisp, and Cookbook) I am also quite fond of Lisp in Small Pieces. Aside from those I'd also recommend grabbing the GCL source and building the Info manual so you can browse it in Emacs, it contains a fairly complete copy of the HyperSpec (I know it's available online, but I don't like visiting websites that haven't updated to HTTPS yet).

Also check out CLiki (the Common Lisp wiki, https://www.cliki.net/), it's very helpful in finding useful libraries, like Alexandria, defstar, trivia, lparallel, and so on.

Re: Rust for Professionals

#90

Post by nicoburns »

aussiesnack wrote: post #59
nicoburns wrote: post #36

Earlier quoted context omitted.

> Rust is harder than any other mainstream language to do that in. I’d argue C and C++ are both harder. It’s hard to even get these to build once you move past trivia examples (including libraries etc). > I find the denial of Rust's difficulty (and not even centred on the borrow checker - it's the use of just about every commmon library) just very very strange Some of us just didn’t find it that hard. Like, I get tha…

> > Rust is harder than any other mainstream language to do that in. > I’d argue C and C++ are both harder. It’s hard to even get these to build once you move past trivia examples (including libraries etc). Agree I overstated that. What I mean is that, out of the difficult to learn languages, Rust is the only one whose community for opaque reasons denies the difficulty. > Some of us just didn’t find it that hard. Why…

> My guess is that most people who say they don't find it hard are either longstanding C/C++ programmers, and/or are learning at work where they have immediate help & scaffolding.

Neither of those were the case for me. In fact, I'd previously tried and failed to learn C (to a level where I could achieve something useful). I did learn at work, which gave me time as I was able to work on it full time, but I had no help available as nobody else at the company knew Rust at the time.

> Rust advocates tend to come back with an aggressive 'proof' that Rust is factually not hard to learn (with implications we can all guess at). No other programming community frequently does this in my experience (and I have brushed against many). That community attitude itself must have causes that are worth thinking about.

I somewhat agree this behaviour isn't great. I suspect the cause is a whole bunch of people saying that Rust is too hard, and that the industry therefore shouldn't bother with it.

Factors I'd guess at:

- Previous experience with a language that uses functional patterns is a huge plus. Even if that's very lightweight functional patterns like you might find in JavaScript or Kotlin (past exposure to something like Haskell or Scala would be even better). - Previous experience with C++ helps. Especially if you write "modern" C++ with smart pointers, etc as this is rather close to how Rust works. - C experience can be a positive or a negative. If you are the sort of C programmer who is hyper aware of object lifetimes and programs carefully and defensively it'll likely help. If you're the kind of C programmer who likes to play fast and loose with safety so long as it works in practice then it'll likely hinder as you'll expect to be able to do things that you can't. - Java/C# and other strongly OOP languages can make learning Rust harder. OOP code tends to be full of graphs of objects that all point to each other, and you just can't do this in Rust. So if that's how you're used to programming your going have to completely relearn how to structure code.

And I guess some of it's just going to be how comfortable people are with abstraction. Rust is definitely heavier on the mathier side of programming (with a sophisticated type system, etc). Personally I find that makes it easier not harder than languages like Go and C which are much simpler in this respect, as when reading code in those languages I often find it hard to pick out those forest from the trees. But from what I've seen, programmers are pretty split on their preferences on this issue, and I imagine for some people this would make it harder.

Post reply on HN