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

Rust 1.46

blog.rust-lang.org

Post reply on HN
Print view View original

131–140 of 157 posts

Re: Rust 1.46

#131

Post by Matthias247 »

lmm wrote: post #130
Matthias247 wrote: post #116

Earlier quoted context omitted.

The zip solution however requires any reviewer to look up on what it actually does, whereas the "if let" is more of a language fundamental and known to most reviewers. Therefore I would actually prefer the long/verbose form without the zip.

It's just the opposite. zip is a normal function written in normal code, so if the reviewer doesn't know what it does then they can just click through to the definition in their IDE. Whereas "if let" is some kind of special language construct that a reviewer has to look up through some special alternative channel if they don't understand it.

If I'm doing a code review I don't have an idea. I only see text (yeah - limitation of the tooling, but reality). I can search for the functions, but it's a hassle and I want to limit having to do it to as much as possible. It's even not super easy in Rust, since some functions are defined on (extension) traits and you don't exactly know where to search for them if you don't have the IDE support and are not already an expert.

"if let" is certainly a special construct - but it's also one that Rust authors and reviewers will typically encounter rather fast since a lot of error handling and Option unwrapping uses it. Knowing the majority of library functions will imho take longer.

Re: Rust 1.46

#132

Post by lmm »

Matthias247 wrote: post #131
lmm wrote: post #130

Earlier quoted context omitted.

It's just the opposite. zip is a normal function written in normal code, so if the reviewer doesn't know what it does then they can just click through to the definition in their IDE. Whereas "if let" is some kind of special language construct that a reviewer has to look up through some special alternative channel if they don't understand it.

If I'm doing a code review I don't have an idea. I only see text (yeah - limitation of the tooling, but reality). I can search for the functions, but it's a hassle and I want to limit having to do it to as much as possible. It's even not super easy in Rust, since some functions are defined on (extension) traits and you don't exactly know where to search for them if you don't have the IDE support and are not already a…

Understanding - or looking up - library functions is something you're always going to have to do during code review (it's well worth getting IDE integration set up). zip is a very standard and well-known function (I used it yesterday, in a non-Rust codebase); it may well end up being better-known than "if let". Learning what a library function does is certainly never harder than learning what a keyword does and it's often easier (apart from anything else, you know that a library function follows the normal rules for functions, so if you can see how its output is used then you can often tell what it does. Whereas you can't rely on that kind of reasoning with language keywords).

Re: Rust 1.46

#133

Post by Jweb_Guru »

Lendal wrote: post #121
nemothekid wrote: post #35

Earlier quoted context omitted.

> the borrow checker, I do conceptually understand lifetimes, but actually using them is tricky. I've been using Rust for a little over year, almost daily at work, and for several projects. I have a pretty good intuition about how the borrow checker works and what needs to be done to appease it. That said, I don't think I'm any closer to understanding lifetimes. I know conceptually how they are supposed to work (I ne…

I've tried and tried but I've never found a situation where explicit lifetimes was the answer. It's almost always more complex than that. I mean, everywhere that is complex enough that implicit lifetimes don't work is also too complex for explicit lifetimes and almost always required Rc or Arc to solve it. Maybe I'm missing something, but it seems like there are so many other missing topics the Rust Book could be spe…

There are a lot of situations where explicit lifetimes are the answer, TBH. However, you have to have a very good working model of lifetimes in order to get the annotations right.

Re: Rust 1.46

#134

Post by gpm »

hu3 wrote: post #46
Verdex wrote: post #26

Earlier quoted context omitted.

Hear hear. System languages don't grow on trees. Rust has had a lot of non-trivial effort put into it and is very usable right now . Somebody is going to see the value just lying around and is going to pick up the financial slack. I see it as vaguely analogous to the current movie theater situation in the US. A lot of companies are seeing the end of their business, but all of those buildings are still sitting around…

What's baffling to me is how scott's comment is [flagged] and [dead]. You trully can't have unconfortable opinions about Rust here. That's blatant censorship. Replying to you since I don't see a reply button to his comment.

I didn't flag it, but I almost did.

The part about the rust team being fired was just incorrect, I downvoted it for that (burying incorrect information tends to avoid it spreading).

Combined with ranting about a spec and a single reference implementation and it looks a hell of a lot more like like intentional flamebait than a misinformed user. They aren't related, are common points raised by known trolls on reddit, and are largely irrelevant. The most popular language in the world is probably python, which has no formal spec. If I had been in a slightly less charitable mood I would have flagged it for this.

Re: Rust 1.46

#135

Post by brundolf »

datanecdote wrote: post #127
brundolf wrote: post #109

Earlier quoted context omitted.

I'm far from an expert, but I would not expect hand-written Rust code to outperform Numpy. Not because it's Rust and Numpy is written in C, but because Numpy has been deeply optimized over many years by many people and your custom code would not have been. When it comes to performance Rust is generally comparable to C++, as a baseline. It's not going to give you some dramatic advantage that offsets the code-maturity…

I deal with a lot of ragged data that is hard to vectorize, and currently write cython kernels when the inner loops take too long. Sounds like Rust might be faster than cython? Thanks for the feedback.

Most likely, yes

Re: Rust 1.46

#136

Post by rmdashrfstar »

shepmaster wrote: post #89
jandrese wrote: post #70

Earlier quoted context omitted.

One thing I'd be wary of is Googling error messages and taking answers from Stack Exchange. Rust has mutated (heh) a fair bit over the years and many SE answers to noob problems are obsolete and sometimes incorrect. At the very least check the datestamp on any answer and be wary of anything more than a year or two old. This goes double if the answer has some extremely awkward looking syntax with lots of modifiers and…

I literally spend tens of hours a week on Stack Overflow ensuring this isn’t the case, or if it is that it’s clearly notated. As always, feel free to drop into the Rust Stack Overflow chat room[1], or any of the official Rust discussion channels, and ping me or other Stack Overflow contributors to review and update answers. 1: https://chat.stackoverflow.com/rooms/62927/rust

You are awesome!

Re: Rust 1.46

#137

Post by paledot »

rmdashrfstar wrote: post #136
shepmaster wrote: post #89

Earlier quoted context omitted.

I literally spend tens of hours a week on Stack Overflow ensuring this isn’t the case, or if it is that it’s clearly notated. As always, feel free to drop into the Rust Stack Overflow chat room[1], or any of the official Rust discussion channels, and ping me or other Stack Overflow contributors to review and update answers. 1: https://chat.stackoverflow.com/rooms/62927/rust

You are awesome!

Seconded. I've been learning on SO heavily lately as I'm writing my first real Rust program (an IRC bot/client/server/not sure yet), and I was impressed by how many questions and answers had been updated with notes about things being potentially out of date. Not something that I think I've ever seen in the PHP land from whence I came.

Re: Rust 1.46

#138

Post by chubot »

ragnese wrote: post #63
estebank wrote: post #59

Earlier quoted context omitted.

> how many function types does Rust have again? Three?). Depending on what you meant, there are more than three: * There are 3 traits, used by closures depending on their needs: * Fn(Args) -> Output * FnMut(Args) -> Output * FnOnce(Args) -> Output * *Every* `fn` is its own type (`fn() {foo}`) * Function pointers (`fn()`), which is how you pass the above around in practice > Rust is very much procedural. I think this…

I realized after I wrote the comment that I was really referring to the closure traits when I said that. And I really should have said "kind" instead of "type" because, like you said, every different function has its own type . But anyway, I don't really disagree with your point about categorizing languages as OOP, Procedural, or Functional. But honestly, in this case, I think it's pretty damn clear than Rust is proc…

But honestly, in this case, I think it's pretty damn clear than Rust is procedural WAY more than it's either OOP or FP. (Note: By OOP, I mean Java-style with tall ownership hierarchies and object-managed mutable state, not necessarily caring about inheritance. And definitely not referring to Alan-Kay-Style-OOP a la Lisp and Smalltalk).

Scala can be looked at ...

Interesting perspectives, and I largely agree with all of them.

Related: I heard someone else say that while Clojure and Erlang embrace immutability for concurrency, Rust shows that you can "just mutate". It's still safe for concurrency (due to its type system).

Rust seems to be one of the only languages that embraces the combination of algebraic data types + stateful/procedural code.

But I've also found this in my Oil project [1], which is written with a bunch of custom DSLs!

I wrote it in statically-typed Python + ASDL [2], so it's very must procedural code + algebraic data types. Despite historically using an immutable style in Python, this combo has grown on me. Lexing and parsing are inherently stateful, and use a lot of mutation.

----

On top of that, my collection of DSLs even translates nicely to C++. Surprisingly, it has some advantages over Rust! The model of algebraic data types is richer ("first class variants"), described here:

https://news.ycombinator.com/item?id=24136949

https://lobste.rs/s/77nu3d/oil_s_parser_is_160x_200x_faster_...

[1] https://www.oilshell.org/

[2] http://www.oilshell.org/blog/tags.html?tag=ASDL#ASDL

Re: Rust 1.46

#139

Post by [deleted] »

lmm wrote: post #132
Matthias247 wrote: post #131

Earlier quoted context omitted.

If I'm doing a code review I don't have an idea. I only see text (yeah - limitation of the tooling, but reality). I can search for the functions, but it's a hassle and I want to limit having to do it to as much as possible. It's even not super easy in Rust, since some functions are defined on (extension) traits and you don't exactly know where to search for them if you don't have the IDE support and are not already a…

Understanding - or looking up - library functions is something you're always going to have to do during code review (it's well worth getting IDE integration set up). zip is a very standard and well-known function (I used it yesterday, in a non-Rust codebase); it may well end up being better-known than "if let". Learning what a library function does is certainly never harder than learning what a keyword does and it's…

[deleted]

Re: Rust 1.46

#140

Post by fmakunbound »

> if, if let, and match

> while, while let, and loop

> the && and || operators

Common Lisp user here. Why just that? How come you can’t have the entire language as well as all your language customizations available at compile time for evaluation?

Post reply on HN