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

Announcing Rust 1.20

blog.rust-lang.org

Post reply on HN
Print view View original

191–200 of 277 posts

Re: Announcing Rust 1.20

#191

Post by pjmlp »

kannanvijayan wrote: post #108
jeffdavis wrote: post #65

I've been having a little trouble using rust for a little project: I need a tree with uplinks (meaning there are cycles). I asked on IRC a couple times and I think what I need is a weak reference inside a refcell, but it's not very easy to make it work cleanly. For one thing, it doesn't look like refcell works well with traits (the nodes in the tree are traits, not plain structs). I'm a bit frustrated because this is…

Frankly, I'd just use unsafe pointers for the backrefs, and wrap the tree API up in a typesafe layer, and build on top of that. RefCells seem to add unnecessary redundancy here. You'll take a hit for runtime borrow for every pointer chase up the tree. If walking from a leaf to the root is important, you don't want to add an extra compare/branch/set to every pointer chase. Turns a single memory read into a branch, a w…

This is why, as a user of GC languages, I think a bit sad that the ergonomics are so bad for cyclic data structures, that this solution is most likely what the majority will turn to.

Re: Announcing Rust 1.20

#192

Post by pjmlp »

leshow wrote: post #114
zaphar wrote: post #39

Earlier quoted context omitted.

Is-A does not and should not imply Inheritance. It merely implies polymorphism. I didn't get formally trained so I can't comment on what college/high school's teach but if they teach that Is-A relationships imply Inheritance then claiming Rust is OOP seems like a good way to educate the mis-educated regarding the difference.

What kind of polymorphism? Traditional OOP is subtype polymorphism. You can't really do that in Rust. It's main polymorphism is parametric and ad-hoc polymorphism a la Haskell. If that's considered OOP then OOP is so broad it's not a useful term

What is traditional OOP?

The Simula, Smalltalk, Lisp, SELF or BETA model?

Yes, OOP is broad, just like FP also is.

Re: Announcing Rust 1.20

#193

Post by alphaalpha101 »

chancancode wrote: post #73
jeffdavis wrote: post #65

I've been having a little trouble using rust for a little project: I need a tree with uplinks (meaning there are cycles). I asked on IRC a couple times and I think what I need is a weak reference inside a refcell, but it's not very easy to make it work cleanly. For one thing, it doesn't look like refcell works well with traits (the nodes in the tree are traits, not plain structs). I'm a bit frustrated because this is…

Have you read "Learning Rust With Entirely Too Many Linked Lists"[1]? I think it will be quite helpful for these kind of situations. It walks you through all the possible tools in the language that is available to you, and at the end, if you just want to write it how you would in C, you could always do it "unsafely" with raw pointers (which is no worse than C). --- [1] http://cglab.ca/~abeinges/blah/too-many-lists/bo…

It's also really no better than C. Or at least no better than C++.

This is my main issue with Rust. It doesn't seem to really solve the right problem. I feel like it solves the easy problems that I already know how to solve easily, but as soon as I get to something that really, truly feels like I want it, the best solution is unsafe.

A complicated circular linked data structure is exactly where I want the language to be screaming at me if I make a silly error. But Rust doesn't even consider memory leaks to be errors...

Re: Announcing Rust 1.20

#194

Post by alphaalpha101 »

CrystalGamma wrote: post #67
wahern wrote: post #60

Earlier quoted context omitted.

Rust isn't inherently thread-safe; not like in the way Java is thread-safe because of how the JVM's memory model is defined. Rust makes it really difficult to share mutable data. But once you do that, such as by smuggling a pointer _through_ an unsafe block, all bets are off, even for code outside an unsafe block. Also, as with Java there will always be bugs in the compiler and runtime. Rust programs were susceptible…

If you use a C FFI in any language, including Java, all kinds of safety are off. Unsafe Rust is equivalent to C (with a lot of mandatory lints) in terms of safety, so Rust is not really less safe.

Not necessarily. There is no actual reason that you couldn't be required to prove to the compiler that your code is safe.

That proof might be parameterised by a proof that some external FFI function was safe, which you might not be able to actually prove and have to assume, but then you would have your assumptions well-documented.

As it is, you have to justify the safety of your unsafe blocks to other programmers using comments, which kind of sucks.

Still better than every other fast language in this area though so I can't complain much.

Re: Announcing Rust 1.20

#195

Post by kybernetikos »

fdchn2016 wrote: post #187

Is there a book on Programming Data Structures in Rust. Like from scratch. Trees, Graphs etc. I would expect the first 2 to 3 chapters to be on Rust pointer system and the rest of the book to be on implementing Data Structures using the pointer system. Similar to like Tanenbaum's book for Data Structures in C or Kruse, Leung and Tondo's book for Data Structures in C.

If I can't code some data stuctures in a language I don't feel like I know it, so I would like something like this too.

The closest I found was the 'too many linked lists' book, which I learned a lot from. http://cglab.ca/~abeinges/blah/too-many-lists/book/

Re: Announcing Rust 1.20

#196

Post by GenKali »

tomjakubowski wrote: post #33
kibwen wrote: post #27

Earlier quoted context omitted.

> Is f32 the only suffix for float literals? Nope. `f32` is for single-precision floats, and `f64` is for double-precision floats. There have been some people lobbying for `f16` and `f128` as well. Also, you don't need to use those suffixes. I imagine the OP is using them for maximum explicitness, but you can just write `1.0` and it will be inferred to a floating-point type as necessary (contrast `1`, which will be i…

GLSL programmers may rejoice in learning that `1.` is accepted syntax too.

Having used Rust since pre-release I'm slightly embarrassed that I'm only learning about this today.

Re: Announcing Rust 1.20

#197

Post by kazagistar »

pjmlp wrote: post #191
kannanvijayan wrote: post #108

Earlier quoted context omitted.

Frankly, I'd just use unsafe pointers for the backrefs, and wrap the tree API up in a typesafe layer, and build on top of that. RefCells seem to add unnecessary redundancy here. You'll take a hit for runtime borrow for every pointer chase up the tree. If walking from a leaf to the root is important, you don't want to add an extra compare/branch/set to every pointer chase. Turns a single memory read into a branch, a w…

This is why, as a user of GC languages, I think a bit sad that the ergonomics are so bad for cyclic data structures, that this solution is most likely what the majority will turn to.

Thr majority never need to write a cyclic data structure, because they can use an existing one from a library.

Re: Announcing Rust 1.20

#198

Post by everheardofc »

mikebenfield wrote: post #113
copx wrote: post #15

Earlier quoted context omitted.

>Associated consts aren't class variables, because constants can't vary That's why I wrote "limited version of". Rust's "associated constants" are a subset of C++'s class variables feature. Namely you can only have variables qualified "const" i.e. constants. >Rust also doesn't have classes in any recognizable sense What? If you have instantiatable abstract data types with associated methods you have a "class". Callin…

> What? If you have instantiatable abstract data types with associated methods you have a "class". Calling them "structs" does not change that. There are classes defined with "struct" in C++ and D too. So if I just take C's structs and add the ability to associate structs with functions using a "struct.function" notation, I now have classes? If so, a class isn't a very powerful concept, is it? Here's an easy way to s…

Because nobody bothers with "OOP" or "FP" because there is not a single cannonical implementation of these that everyone agrees on.

What you're talking about has nothing to do with neither.

Any language that has generics can have self types or whatever you want to call them. It's a matter of whether the language has a strong static typesystem and most FP-style languages have these and a minority of OOP-style languages has them too.

The reason why I use C++ has nothing to do with a preference for OOP. It's because all the widely used alternatives have terrible performance.

I hate dealing with C++ projects. I hate dealing with memory leaks and segfaults. But that doesn't stop me from creating more of them and working on existing ones.

All of that because the resulting memory footprint and performance are worth it.

Re: Announcing Rust 1.20

#199

Post by LambdaComplex »

evincarofautumn wrote: post #177
LambdaComplex wrote: post #171

Earlier quoted context omitted.

Since you apparently know stuff about language, maybe you can help me out: Sometimes novice programmers try something like "foo == bar && baz" when they really should have "foo == bar && foo == baz". This is because, in English, "Foo is equal to bar and baz" means (and is more common than) "Foo is equal to bar and foo is equal to baz". There's some name for this rule, but I haven't been able to remember it for a whil…

First, I have a little anecdote about that. I was at a summer camp where we were taking game programming classes. I had been programming for longer than the other students, so I would help them out. One of my peers asked me for help with a part of his program. In the course of that, I noticed that he had written “if (x == 1 || 2 || 3 || …)” in another part of his code, and explained that this condition would always b…

Yes, "right node raising" is exactly what I was looking for. Thank you!

Re: Announcing Rust 1.20

#200

Post by bad_user »

cpeterso wrote: post #189
bad_user wrote: post #182

Earlier quoted context omitted.

So they are already switching to the new Quantum-powered Gecko in Firefox 57?

There is no single switch. Quantum is an ongoing initiative to import more code from Servo into Firefox/Gecko and to improve Firefox responsiveness.

Awesome.
Post reply on HN