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

100 days with Rust: a series of brick walls

brandur.org

Post reply on HN
Print view View original

281–290 of 323 posts

Re: 100 days with Rust: a series of brick walls

#281

Post by pjmlp »

yorwba wrote: post #55
Analemma_ wrote: post #22

Earlier quoted context omitted.

That is indeed what I found :) But trying to find stuff like this with Rust's documentation-- when you're using a search engine instead of relying on having a human to interpret the question for you-- is usually tremendously frustrating. My experience has been that Rust developers lean heavily on autogenerated documentation, where each method of a struct/enum is heavily documented but there are few to no examples or…

When I just did the search for C#, the first non-StackOverflow link was to Microsoft's autogenerated documentation. Without any examples, I'm not sure whether System.DateTime.Parse does what you want. Where would you have looked to get those examples/E2E scenarios for C#?

I see a complete E2E example here.

https://msdn.microsoft.com/en-us/library/system.datetime.par...

Re: 100 days with Rust: a series of brick walls

#282

Post by yorwba »

pjmlp wrote: post #281
yorwba wrote: post #55

Earlier quoted context omitted.

When I just did the search for C#, the first non-StackOverflow link was to Microsoft's autogenerated documentation. Without any examples, I'm not sure whether System.DateTime.Parse does what you want. Where would you have looked to get those examples/E2E scenarios for C#?

I see a complete E2E example here. https://msdn.microsoft.com/en-us/library/system.datetime.par...

Interesting. I found https://msdn.microsoft.com/en-us/library/system.datetime(v=v... and there in the long list of methods is a link to https://msdn.microsoft.com/en-us/library/1k1skd40(v=vs.110).... , which doesn't have the example.

Re: 100 days with Rust: a series of brick walls

#283

Post by bjz_ »

brandur wrote: post #176

Author here. I want to apologize a bit for the tone of this article — it was written from a place of frustration, and this part of the site is very much akin to a development journal — these are short articles without a lot of concrete facts that are not really intended for broad or comprehensive consumption. In no way is this meant to be an anywhere-near comprehensive critique on Rust. I'll quickly point out that Ru…

Yeah, much work is being done! As a long time user of Rust (for many years), I'm not super confident about using futures yet without the support of `impl Trait` - I mean, I could manage it, but I definitely would not want to inflict it on more sceptical coworkers. Thankfully this stuff is being worked on, and should be shipped in the not to distant future. The Rust team is great, and manages to get a huge amount done despite the many challenges in front of them! All while remaining positive and friendly! :)

Re: 100 days with Rust: a series of brick walls

#284

Post by skohan »

dmitrygr wrote: post #182
skohan wrote: post #72

Earlier quoted context omitted.

Two things jump out at me: 1. Automatic reference counting is a really good alternative to GC. It takes a little bit more book-keeping, but the performance characteristics are predictable since allocations/frees are handled along the way. Many GC implementations require execution to be halted while the reference graph is traced, which makes it a non-starter for applications trying to deliver predictable real-time per…

if something is hard to do in Rust it's probably an anti-pattern with respect to memory performance or safety. Oh? Tell me, how many lines of Rust does this take you? struct Task { struct Task *next; struct Task *prev; struct TaskRegs regs; //other shit here } Or are doubly-linked lists antipatterns now?

Of course it always depends on context, but doubly linked lists are often far from optimal in terms of performance when it comes to sequence-like data structures.

A naive implementation of a doubly linked list is probably going to mean you are allocating list members one at a time, and over the course of execution you may be re-ordering items, inserting items in the middle of the list or adding items over time. All of this probably leads to memory fragmentation in a data structure you are probably going to be iterating over, which is far worse for performance than allocating a contiguous block of memory of a fixed size.

So yes, Rust may be pushing you away from implementing naive linked lists by making that more complicated. But if you care about list performance (which you very well may not in your problem domain), you probably should not be implementing your own sequence data structures. You should be using a mature, optimized implementation which, under the hood, is probably implemented using those "hard" design patterns which Rust is designed to make easier.

Re: 100 days with Rust: a series of brick walls

#285

Post by papaf »

derefr wrote: post #195
jmgao wrote: post #143

Earlier quoted context omitted.

Reference counting isn't inherently more predictable than tracing garbage collection. Take the example where your thread is the last one to deref a gigantic object graph. You're stuck holding the bag on traversing the entire graph and destructing it all at once, when a tracing gc could do it piecemeal (and on a dedicated background thread, instead of on your real worker threads).

If objects that hit zero refs have their reference pushed into the queue of a dedicated GC thread, is that not still called RC, or is that called something else?

Researchers tend to call them Reference Counted Garbage Collectors.

Here is a random example that actually recommends the opposite (RC in old generations, mark and sweep in the young generation):

https://link.springer.com/chapter/10.1007/3-540-36579-6_14

Re: 100 days with Rust: a series of brick walls

#286

Post by steveklabnik »

bjz_ wrote: post #283
brandur wrote: post #176

Author here. I want to apologize a bit for the tone of this article — it was written from a place of frustration, and this part of the site is very much akin to a development journal — these are short articles without a lot of concrete facts that are not really intended for broad or comprehensive consumption. In no way is this meant to be an anywhere-near comprehensive critique on Rust. I'll quickly point out that Ru…

Yeah, much work is being done! As a long time user of Rust (for many years), I'm not super confident about using futures yet without the support of `impl Trait` - I mean, I could manage it, but I definitely would not want to inflict it on more sceptical coworkers. Thankfully this stuff is being worked on, and should be shipped in the not to distant future. The Rust team is great, and manages to get a huge amount done…

imply Trait is coming to stable in Rust 1.26, 7 weeks from now. :D

Re: 100 days with Rust: a series of brick walls

#288

Post by MrBuddyCasino »

kibwen wrote: post #156
riquito wrote: post #124

Earlier quoted context omitted.

> Ah, it sounds like you're using traits as types directly, which is very much discouraged by Rust (especially in conjunction with taking references to those traits). What the language really prefers for you to do is to use traits as bounds on generic types Can you write an example?

Sure thing. [Preemptive postscript: damn this got long. TL;DR don't use trait objects, just use generics. You'll thank me.] Here's the setup: we have several different types, and those types implement the same trait (think of it like an interface from other languages). // Define two different types struct Chihuahua; struct GreatDane; // Define a trait with a method trait Bark { fn bark(&self); } // Implement that met…

That was a great explanation. Should publish this somewhere.

Re: 100 days with Rust: a series of brick walls

#289

Post by pjmlp »

yorwba wrote: post #282
pjmlp wrote: post #281

Earlier quoted context omitted.

I see a complete E2E example here. https://msdn.microsoft.com/en-us/library/system.datetime.par...

Interesting. I found https://msdn.microsoft.com/en-us/library/system.datetime(v=v... and there in the long list of methods is a link to https://msdn.microsoft.com/en-us/library/1k1skd40(v=vs.110).... , which doesn't have the example.

.NET allows for function overloading, so usually the examples tend to be on the same page where all variants get listed, not on every single one.

With the main page for a class listing the most common use cases.

Re: 100 days with Rust: a series of brick walls

#290

Post by SCdF »

physguy1123 wrote: post #244
SCdF wrote: post #126

Earlier quoted context omitted.

Yeah. So I'm following a ray tracing book that uses C++ as example code, and am using Traits as a form of interface: there is a trait of Material that has a function on it, and then there are different "implementations" of Material with different implementations of that fn, and can have arbitrary data stored against them. I need to have them sized because I need to copy them at a point where I only understand they ar…

> there is a trait of Material that has a function on it, and then there are different "implementations" of Material with different implementations of that fn, and can have arbitrary data stored against them. Do you mean like a class hierarchy+virtual functions, or just having allocated data of arbitrary length past the end of a struct? If it's the former, C++ fares no better in this regard but it's pretty easy to do…

  impl Material for Lambertain  {
      ...
      fn box_clone(&self) -> Box {
          Box::new(Lambertian {
              ..self
          })
      }
  }
Holllllly shit I think that works.

Why am I allowed to do this and not just derive Clone and Copy!?!

Post reply on HN