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

151–157 of 157 posts

Re: Rust 1.46

#151

Post by chubot »

ragnese wrote: post #148
chubot wrote: post #138

Earlier quoted context omitted.

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…

> 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). Yes! I will repeat a sentiment I articulated on Reddit about that. Even after having used Rust on a handful of small-to-medium sized projects since 2016, I never realized that I could loosen/abandon my immutability feti…

Yes I'll be interested to see how it turns out. Any blog posts / writing on the procedural viewpoint will be appreciated.

Does Rust have something like C++'s const methods? Where you can have a method that mutates a member, but doesn't logically mutate from the caller's perspective?

It seems like you could be prevented from having races on individual variables, but still have races at a higher level.

Like on database cells. I guess no language will help you with that, and that's why Hickey wrote Datomic -- to remove mutability from the database.

Re: Rust 1.46

#152

Post by ragnese »

chubot wrote: post #151
ragnese wrote: post #148

Earlier quoted context omitted.

> 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). Yes! I will repeat a sentiment I articulated on Reddit about that. Even after having used Rust on a handful of small-to-medium sized projects since 2016, I never realized that I could loosen/abandon my immutability feti…

Yes I'll be interested to see how it turns out. Any blog posts / writing on the procedural viewpoint will be appreciated. Does Rust have something like C++'s const methods? Where you can have a method that mutates a member, but doesn't logically mutate from the caller's perspective? It seems like you could be prevented from having races on individual variables, but still have races at a higher level. Like on database…

> Does Rust have something like C++'s const methods? Where you can have a method that mutates a member, but doesn't logically mutate from the caller's perspective?

Yes! "Interior mutatbility" is the term to search for. In Rust, you'd wrap the field in a RefCell. Many connection-pool implementations use interior mutability to manage the connections transparently to the caller.

Interior mutability is basically what, e.g. OCaml, does by default. In Rust, it's opt-in.

Yeah, DB ops are always a sticking point for figuring out how to write my APIs.

Re: Rust 1.46

#153

Post by iopq »

ragnese wrote: post #149
scns wrote: post #143

Earlier quoted context omitted.

Usually when the term OOP is used, it actually means ClassOrientedProgramming (C++/Java/C# etc)

Which I also don't understand. Is that a style of overusing classes where functions would suffice (FooHelper)? Or is it something about the language? Because almost all popular languages have classes. Rust and Go call them "struct", but it's the same thing. Swift has "class" and "struct", but they're both the same thing as a C++ class.

Rust structs are not classes. Rust puts structs inline (on the stack), classes are virtual. Since Rust is a systems programming language, it's an actual distinction that makes a difference

Re: Rust 1.46

#154

Post by ragnese »

iopq wrote: post #153
ragnese wrote: post #149

Earlier quoted context omitted.

Which I also don't understand. Is that a style of overusing classes where functions would suffice (FooHelper)? Or is it something about the language? Because almost all popular languages have classes. Rust and Go call them "struct", but it's the same thing. Swift has "class" and "struct", but they're both the same thing as a C++ class.

Rust structs are not classes. Rust puts structs inline (on the stack), classes are virtual. Since Rust is a systems programming language, it's an actual distinction that makes a difference

I'm not sure I follow. Both C++ and Rust allow us to put structs/classes on the stack or the heap. Rust has trait objects which use a vtables. Are Rust traits the same as "classes" then?

When people say "OOP" or "class-oriented-programming" are you saying that they're referring to implementation details such as memory allocation?

Re: Rust 1.46

#155

Post by daitangio »

Can Mozilla layoffs (on Servo team) impact Rust future? It is just s question to understand if there are others big rust project healty out of there. Just curious

Re: Rust 1.46

#157

Post by int_19h »

iopq wrote: post #153
ragnese wrote: post #149

Earlier quoted context omitted.

Which I also don't understand. Is that a style of overusing classes where functions would suffice (FooHelper)? Or is it something about the language? Because almost all popular languages have classes. Rust and Go call them "struct", but it's the same thing. Swift has "class" and "struct", but they're both the same thing as a C++ class.

Rust structs are not classes. Rust puts structs inline (on the stack), classes are virtual. Since Rust is a systems programming language, it's an actual distinction that makes a difference

I'm not sure what you mean by "classes are virtual", but if it's virtual dispatch, then that's completely orthogonal to allocating objects on the stack vs the heap.
Post reply on HN