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

Rust's 2017 Roadmap

blog.rust-lang.org

Post reply on HN
Print view View original

221–230 of 274 posts

Re: Rust's 2017 Roadmap

#221

Post by tom_mellior »

yaantc wrote: post #207
tom_mellior wrote: post #196

Earlier quoted context omitted.

> Rust's genius is going after the market that can't use GC But the problem with that is that the market that really really can't use GC is vanishingly tiny. Rust throws the baby out with the bathwater and tries to pressure others into thinking that they are in this market. Most developers on most projects aren't. And then Rust implements reference-counted pointers in the library, which is the slowest possible way of…

> But the problem with that is that the market that really really > can't use GC is vanishingly tiny. It's huge, but specialized so may not be on your radar: small embedded devices. Think RAM size from 10s to 100s kB, and Flash from 100s kB to few MBs as rough ranges. The interest for IoT, and the need for battery operated devices with lifetime of 10+ years, make such platforms very important. And cost and process co…

> No room for GC here

True, if you're talking about tiny embedded systems where you would not use GC (nor any dynamic allocation), you shouldn't have much difficulty using Rust. Nor many of its benefits.

Re: Rust's 2017 Roadmap

#222

Post by lsllc »

anamoulous wrote: post #137
stusmall wrote: post #102

Earlier quoted context omitted.

I've been getting early release PDFs of this book for a while now. I highly suggest it for moving from beginner to getting serious. I still think the Rust book is a better first read, but this is much more in depth and detailed. One of the sections that was most useful to me was comparing how memory is laid out in a few different languages with a few different concrete code examples. These comparisons really helped m…

Did you pre-order the print book? Does that get you early access PDFs? Or does O'Reilly charge separately for the PDF and print?

Annoyingly, O'Reilly doesn't do a bundle. In the end, I found a 40% discount code and bought both.

Re: Rust's 2017 Roadmap

#223

Post by lsllc »

stusmall wrote: post #102
kibwen wrote: post #94

Earlier quoted context omitted.

Then see O'Reilly's upcoming "Programming Rust" by Jim Blandy, who, despite working at Mozilla, has never been involved in Rust development, and has long years of experience developing SpiderMonkey, GDB, SVN, GNU Guile, and Emacs. It's still in early access, but 17 out of 20 chapters are available. http://shop.oreilly.com/product/0636920040385.do

I've been getting early release PDFs of this book for a while now. I highly suggest it for moving from beginner to getting serious. I still think the Rust book is a better first read, but this is much more in depth and detailed. One of the sections that was most useful to me was comparing how memory is laid out in a few different languages with a few different concrete code examples. These comparisons really helped m…

I'll second that recommendation.

Re: Rust's 2017 Roadmap

#224

Post by kazagistar »

sametmax wrote: post #216
dripton wrote: post #152

Earlier quoted context omitted.

Unless foo.txt is too big, in which case, bam, out of memory.

No, Python, ruby and such have a common interface for all lazy iterations. In Python you can just loop on anything declaring the __iter__ method, and it will lazily yield results little by little. IO related objects implement it plus an additional layer of interface so that you can do: with open('file', [mode, encoding]) as f: To get an auto closing file handle and then choose: - for `line in f` to lazy read it line…

The Rust team seems to not want to write trait impls where it would be inefficient to use those traits. If a method doesn't exist, its often because there is a slightly better way. They also insist that memory usage, especially any heap allocations, be very clear and explicit: allocating and attaching a buffer is probably not OK within the internal logic of the library designs.

The interface for reading is split into multiple parts. Read is the lower level interface for any stream of bytes, and is what lets you read a specific number of bytes into a preallocated buffer. Seek is implemented for files, but not all streams, because in most cases it makes no sense. There are also a number of file-specific methods directly attached to File for handling permissions and sync and such.

BufRead is the trait that lets you read all the lines, but it is explicitly not implemented for File, since using it for a File would be slow, and generally the wrong way to do things. It does have an implementation for Stdin, because that is already buffered, but if you want to associate a buffer with a file, you have to do it yourself by wrapping it in a ReadBuffer.

If I were to find a problem with the File documentation, it is that it does not mention BufReader.

Re: Rust's 2017 Roadmap

#225

Post by pkolaczk »

acqq wrote: post #206
pkolaczk wrote: post #200

Earlier quoted context omitted.

"sharing data" is quite illusory. Even if two threads have a reference to the same object, the CPU deals with it internally by making several copies, asynchronous message passing and locking, and in many cases it can lead to abysmal performance. It is often much better for performance to design parallel algorithms around shared-nothing i.e. local mutability + explicit message passing right from the start.

> "sharing data" is quite illusory. Even if two threads have a reference to the same object, the CPU deals with it internally by making several copies, asynchronous message passing and locking, No. Two threads on the same CPU core really access the same data(1) without the delay and no locking happens unless the programmer wrote some locking code. Synchronizing the different cores or processors is another topic, but…

Even on a single core, there are several copies in different cache layers and synchronizing them is done by sending asynchronous messages. Sure, in that one particular edge case when the threads are sharing a core you're right, but this is not a typical scenario for multi-threaded applications. Most of the time for high multi-threaded performance you want exactly opposite - one thread per core and pinning threads to cores. And if you don't do anything, you can never be sure if your threads run on the same core or not and you should assume the worst.

> And it's mostly software design that initiates the slowdowns, not the CPU.

This is quite vague statement and I'm not sure what you really meant here. Software written using a simplified abstraction model (e.g. flat memory with stuff shared between threads, ordered sequential execution) much different than the way how CPU really works (hierarchical memory, out-of-order execution, implicit parallelism etc.) is very likely to cause "magic" slowdowns. See e.g. false-sharing.

Also algorithms designed around the concept of shared mutability do not scale. Sure, you may hide some of the problems with reordering, out-of-order, etc. To some degree it will help, but not when you go to scale of several thousands cores in a geographically distributed system.

Re: Rust's 2017 Roadmap

#226

Post by sametmax »

kazagistar wrote: post #224
sametmax wrote: post #216

Earlier quoted context omitted.

No, Python, ruby and such have a common interface for all lazy iterations. In Python you can just loop on anything declaring the __iter__ method, and it will lazily yield results little by little. IO related objects implement it plus an additional layer of interface so that you can do: with open('file', [mode, encoding]) as f: To get an auto closing file handle and then choose: - for `line in f` to lazy read it line…

The Rust team seems to not want to write trait impls where it would be inefficient to use those traits. If a method doesn't exist, its often because there is a slightly better way. They also insist that memory usage, especially any heap allocations, be very clear and explicit: allocating and attaching a buffer is probably not OK within the internal logic of the library designs. The interface for reading is split into…

Make senses. I tried to apply a solution to the wrong problem.

Re: Rust's 2017 Roadmap

#227

Post by winstonewert »

MichaelGG wrote: post #132
JoelMcCracken wrote: post #108

Earlier quoted context omitted.

This is one of those things that seem plausible, but I have no idea if its really true. I'm not disagreeing, I just can't see it as being obviously true. Can you give me an example of how a fuzzy idea of ownership causes, ideally, a real problem, or a less ideally a simplified example problem? I'm 100% genuinely interested in this.

One piece of software that handles a lot of traffic on phone networks has an interesting issue. A bunch of headers are added to a list on every transaction. Most of these header names are constants ("TransactionID", "SourceId", "CallingNumber", etc.). However, they can be dynamic ("x-dynamic-header-foobar"). The easiest way in C to deal with this is just to strdup all the header names, so the final consumer can safel…

How would rust help in this situation? What alternate design is rust enabling that would be different?

Re: Rust's 2017 Roadmap

#228

Post by curun1r »

dbaupp wrote: post #73
Animats wrote: post #18

Earlier quoted context omitted.

Rust needs a Rust book not written by the Rust developers. "Rust for Dummies", if you will.

Why couldn't Rust's developers write "Rust for Dummies"? I feel like you're connecting dots that aren't actually connected. Obviously having more books from different authors/perspectives is great for Rust, but I don't see, prima facie, why a non-Rust-developer author would do a better job of "Rust for Dummies" than a Rust developer. For one, I would be surprised if a non-"expert" (which is, I presume, why you're so…

It's probably a "forrest for the trees" problem...the developers of a language will have their perspective colored by low-level implementation details.

As an example, I found the explanation of trait objects incredibly confusing when I read the book. They confused the subject by immediately talking about static vs dynamic dispatch of functions, which is really an implementation detail and performance consequence of using them and not a part of what they are logically. An outsider might have started with a simple explanation of what a trait object is (an instance of a trait where the compiler cannot determine the concrete type at compile time) and make that clear before diving into the consequences of choosing to use one in your code.

Re: Rust's 2017 Roadmap

#229

Post by nf05papsjfVbc »

nostrademons wrote: post #179
Ericson2314 wrote: post #177

Earlier quoted context omitted.

Honestly for most programmers, no GC is a red herring.

That may be true, but for programmers that can use GC, there are already very good solutions out there. New products succeed based on how much better they are than the other solutions in their market . Rust's genius is going after the market that can't use GC, which has seen few innovations in programming language design over the last 25 years. (C++11/14/17 has helped this situation immensely, but C++ is still behold…

I admit that I love C++. Of the time I spent learning programming, C++ took the lion's share. I think the language is making amazing progress since C++11. So, I started to make even more efforts to learn all the changes the language was getting.

Then, I saw rust. I fell in love with it. It is indeed what I see as the future for one who isn't tied to using C++ or C from legacy, programmer-knowledge or programmer-availability constraints. I, decided that I will place my bets on rust and am willingly giving up all the investment I made in C++. If I am their target audience, then they've definitely reached me!

Re: Rust's 2017 Roadmap

#230

Post by acqq »

pkolaczk wrote: post #225
acqq wrote: post #206

Earlier quoted context omitted.

> "sharing data" is quite illusory. Even if two threads have a reference to the same object, the CPU deals with it internally by making several copies, asynchronous message passing and locking, No. Two threads on the same CPU core really access the same data(1) without the delay and no locking happens unless the programmer wrote some locking code. Synchronizing the different cores or processors is another topic, but…

Even on a single core, there are several copies in different cache layers and synchronizing them is done by sending asynchronous messages. Sure, in that one particular edge case when the threads are sharing a core you're right, but this is not a typical scenario for multi-threaded applications. Most of the time for high multi-threaded performance you want exactly opposite - one thread per core and pinning threads to…

> See e.g. false-sharing.

It's also an effect of a badly written software, not something that is constantly present in the CPU execution. You based the claim to which I've replied on "sharing is illusory", "if two threads" and "the CPU deals with it" like it's necessary to happen all the time in the CPU as soon as the threads exist and they access the same data.

> when you go to scale of several thousands cores in a geographically distributed system.

There you are not describing "a CPU" (as in, the thing that's in the CPU slot of the motherboard) which is all I discussed, and I'm not interested in changing the topic.

Post reply on HN