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

91–100 of 103 posts

Re: Rust for Professionals

#91

Post by legerdemain »

scotty79 wrote: post #86
legerdemain wrote: post #79

Earlier quoted context omitted.

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.

It's "completely optional" in the sense that in several years of reading other people's Rust code, I have never seen anyone explicitly use it throughout a code base. It is utterly ubiquitous, rarely explained, and poorly (if at all) understood by a large majority of Rust users I've mentioned it to.

My claim is that for most Rust users, understanding the borrow checker is limited to a few heuristics that seem to work for them 80% of the time, and throwing up their hands and declaring an approach unworkable the remaining 20% of the time. To a first approximation, no one can mentally model the borrow checker beyond extremely simple examples of 4-5 lines of code.

Re: Rust for Professionals

#92

Post by aussiesnack »

nicoburns wrote: post #90
aussiesnack wrote: post #59

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

> I suspect the cause is a whole bunch of people saying that Rust is too hard,

Perhaps, though I haven't myself witnessed anyone saying it's 'too hard'. Just that people (like me and everyone I know who's tried to learn) find it 'hard'. Then we're informed it's not.

My thought about the underlying reasons was more along the lines of the Rust community's inclusion ethic. I find that entirely laudable in general. But like all ideologies it can lead to blind spots when insisted on against evidence. For example, it's even built into the (plainly false) official tagline: "A language empowering everyone to build reliable and efficient software." If someone finds Rust difficult, this creates a strong cognitive dissonance in fierce Rust advocates (for some reason so many are), which evokes vigorous denial.

> Previous experience with a language that uses functional patterns is a huge plus

My previous two 'learn for interest' languages were Clojure and Elixir. I could do more in both after a week than after some months of Rust.

In my case it's not unfamiliarity nor abstraction, but the sheer complexity that bleeds right through the ecosystem. For example: something I experience every time I try to do anything 'real': I search for the most common/recommended relevant library, go to its docs and find them utterly incomprehensible. It then takes days to glean enough to use the new library fluently. Even reading commandline args - detailed but conceptually simple - leads to a vastly complex horror of a library (I won't name names) that takes days to decipher. It's never taken me more than an hour or two in any other language. My Rust projects slow to a stupefying crawl.

For all that, I'm persisting (or rather re-starting, as my attempt earlier this year left me thoroughly demoralised) out of a combination of some real practical uses I have for it ("hard" doesn't to me in any way mean "bad"), and stubbornnes. But I'll do so without the 'help' of the community, which I find insufferable.

Re: Rust for Professionals

#93

Post by insanitybit »

aussiesnack wrote: post #74
insanitybit wrote: post #70

Earlier quoted context omitted.

Just to be clear, again, lots of people find rust difficult. I found it easy. Lots of people find it easy. That's interesting. Saying "rust is difficult" is silly to me because... it wasn't for me. Saying "rust is easy" is less silly to me because for me it was, but obviously for you it will be more silly because it isn't easy for you. You'll find that many in the rust community are in fact very very sympathetic to y…

> You'll find that many in the rust community are in fact very very sympathetic to your view that it's too hard to learn. I have not found that. The very comment I'm responding to above is a correction, telling me "it's not hard", not saying on the writer's part that they didn't find it hard, and least of all with any curiosity towards any dev claiming that they find Rust hard, because that view is considered in the…

Well I've been around Rust since before 2015 and I'm telling you that tons of people feel the language is too difficult. Maybe you haven't seen that, but you've also seen a tiny fraction of the community relative to me.

Going it alone sounds like a recipe for it being very difficult. I'd recommend interacting with the community when you have questions, it'll be very helpful.

My only point this entire time is that saying "rust is difficult" is just as wrong as saying "rust is easy". Rust was easy for me, fact. Rust was hard for you, fact. Both things are true.

Re: Rust for Professionals

#94

Post by alltheworlds »

scotty79 wrote: post #65
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…

Also very important realization is that things that are moved around (assigned to variable, moved into or returned from a function, kept as a part of the tuple or a field of a struct) must have fixed and known size. And the variable itself is not a handle. It's a fixed sized area in the memory that you named and moved something into it. This makes completely logical why some things must be Box 'ed and borrowed. Why y…

As someone who hasn't looked at Rust, reading all this makes me never want to. Am I missing something? Is it actually easier to reason about the language than it feels like from reading this text?

Re: Rust for Professionals

#95

Post by zozbot234 »

alltheworlds wrote: post #94
scotty79 wrote: post #65

Earlier quoted context omitted.

Also very important realization is that things that are moved around (assigned to variable, moved into or returned from a function, kept as a part of the tuple or a field of a struct) must have fixed and known size. And the variable itself is not a handle. It's a fixed sized area in the memory that you named and moved something into it. This makes completely logical why some things must be Box 'ed and borrowed. Why y…

As someone who hasn't looked at Rust, reading all this makes me never want to. Am I missing something? Is it actually easier to reason about the language than it feels like from reading this text?

This is just stuff that's flagged automatically by the compiler. You don't need to "reason" about it, the compiler will tell you how to fix it if it does come up.

Re: Rust for Professionals

#96

Post by avaldez_ »

tmtvl wrote: post #89
avaldez_ wrote: post #84

Earlier quoted context omitted.

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

Didn't know half of those. Thank you!

Re: Rust for Professionals

#97

Post by bear24rw »

saghm wrote: post #85
coderenegade wrote: post #63

Earlier quoted context omitted.

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

> In C++, the only way I'm aware of to verify whether a value is actually moved or not is to use a debugger.

Not as simple as if there was a proper borrow checker but its sort of possible:

https://awesomekling.github.io/Catching-use-after-move-bugs-...

Re: Rust for Professionals

#98

Post by mlindner »

nine_k wrote: post #30
mlindner wrote: post #10

Earlier quoted context omitted.

Javascript I've seen a decent amount and tweaked/edited some of code in it but I wouldn't say I "know" it at all. Kotlin I've never even seen before and I know literally nothing about the language. Java I wrote a bit of in high school but haven't touched it in 15 years. So yeah there's quite a lot that people wouldn't know.

Well, Golang? Pascal? They have similar ways of declaring data types, for instance. This guide is not going to magically teach you Rust is there's nothing to compare it to; there are other guides to help those without a background. But it could somehow help people who already have similar concepts in their mind to link them to corresponding concepts in Rust.

Golang I've seen code of, but never worked with it. Pascal I've never seen before.

Re: Rust for Professionals

#99

Post by mlindner »

Jtsummers wrote: post #37
mlindner wrote: post #10

Earlier quoted context omitted.

Javascript I've seen a decent amount and tweaked/edited some of code in it but I wouldn't say I "know" it at all. Kotlin I've never even seen before and I know literally nothing about the language. Java I wrote a bit of in high school but haven't touched it in 15 years. So yeah there's quite a lot that people wouldn't know.

You've said what languages you don't know, what languages do you know?

C, C++, and Python are all languages I've worked professionally in. I'm in the process of learning Rust.

Re: Rust for Professionals

#100

Post by alltheworlds »

aussiesnack wrote: post #92
nicoburns wrote: post #90

Earlier quoted context omitted.

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

> I suspect the cause is a whole bunch of people saying that Rust is too hard, Perhaps, though I haven't myself witnessed anyone saying it's 'too hard'. Just that people (like me and everyone I know who's tried to learn) find it 'hard'. Then we're informed it's not. My thought about the underlying reasons was more along the lines of the Rust community's inclusion ethic. I find that entirely laudable in general. But l…

I write low latency Java for a living (usual finance type stuff). Our fund has started to use some Rust but I've not yet delved. I'm still trying to resolve whether it will be worth my time to do so. I'm one of those unusual people who really enjoys Java programming for the most part because it both allows you to be very productive but also offers enough sophistication to achieve really high performance.
Post reply on HN