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

Announcing Rust 1.24.1

blog.rust-lang.org

Post reply on HN
Print view View original

21–30 of 66 posts

Re: Announcing Rust 1.24.1

#21

Post by lucozade »

HumanDrivenDev wrote: post #9

Rust gives me a headache. I want to like it, but it just seems so... overengineered https://doc.rust-lang.org/std/str/struct.SplitWhitespace.htm... Why would you create a special data type to represent a string split by Whitespace? Lunacy

I wrote in another comment that I don't think the SplitWhitespace type is an example of overengineering. And I don't.

However, thinking about this more, I think I understand what you mean and I, sort of, agree.

What I believe is going on is that Rust exposes a lot of its engineering. This can be either good or bad depending on where you're coming from. If you're working at a low level then this is usually a good thing. If you're working at a high level then this can be quite annoying.

What I think you'll find is that this is largely a point in time thing. Rust is still relatively young and there is substantial work in flight under the banner of ergonomics. Even though this is more engineering, I'm pretty confident that the net effect will be to make the language feel less engineered. It probably won't completely get there this year but I don't think it'll be long.

Re: Announcing Rust 1.24.1

#22

Post by varjag »

devit wrote: post #16
HumanDrivenDev wrote: post #9

Rust gives me a headache. I want to like it, but it just seems so... overengineered https://doc.rust-lang.org/std/str/struct.SplitWhitespace.htm... Why would you create a special data type to represent a string split by Whitespace? Lunacy

Because unlike most other programming languages, Rust is well-engineered and seeks to both provide the most general abstractions possible and to make the code generated by them as efficient as possible. In particular, for this task, this requires to: 1. Return references to subranges of the original string, rather than copying them, so that no copy happens if you only need to examine the component instead of storing…

The better half of those points are directly and indirectly caused by insistence on manual memory management. Yes, it was a major design point of Rust, but it doesn't make it better engineered than "most other languages". It's just the corner it painted itself to.

Re: Announcing Rust 1.24.1

#23

Post by ekidd »

romwell wrote: post #19
ekidd wrote: post #15

Earlier quoted context omitted.

> Why would you create a special data type to represent a string split by Whitespace? Big chunks of Rust are build around iterators, and `split_whitespace` returns an iterator of type `SplitWhitespace`. Because this is a concrete type, the Rust compiler and LLVM will then work to together to completely inline it, and they will generate code that looks like a hand-rolled loop. There are some downsides to this system—i…

>and upload each of those chunks to S3 in parallel, using no more than N worker threads Do you use a crate like Rayon for this? I'm just starting with Rust, and my current understanding is that without using a library, one can only spawn threads and distribute load by hand (as opposed to automatic scheduling a-la OpenMP). Is this correct?

We're hoping to open source our streaming S3 uploader. Behind the scenes, it uses the `crossbeam` crate (for scoped threads) and BurntSushi's `chan` crate (for bounded, blocking mpmc queues, which is how we get backpressure from a worker pool). One of the cool things about Rust is that it's possible for third-party crates to implement threading primitives.

`rayon` is awesome, and it uses `crossbeam_dequeue` internally. But `rayon` is really best-suited to computational parallelism on many small pieces of data, and less suited to I/O parallelism. So it may be worth using `crossbeam` directly in that case.

All the threads in our S3 uploader run on a single machine, because multi-part uploads are mostly limited by how much memory we want to use for buffering S3 object parts, not by CPU.

(Of course, I'll probably overhaul a lot of this code later this year once `#[async]` and `futures` stabilize, so I can also stop paying for the memory used by thread stacks.)

But the cool part is that we can already do streaming input, compression, chunking and parallel uploads without ever creating a temp file. (And we can upload multiple data streams using the same worker pool.) This took about three days to build.

Re: Announcing Rust 1.24.1

#24

Post by Arnavion »

Freak_NL wrote: post #6

> Cargo couldn’t fetch the index from crates.io if you were using an older Windows without having applied security fixes. Why are developers (since this is an issue that shows up with cargo) running Windows 7 without security patches installed? Especially since the issue only shows up on Windows 7 installs that haven't received security patches since June 2016. > libgit2 created a fix, using the WinHTTP API to reques…

>Why are developers (since this is an issue that shows up with cargo) running Windows 7 without security patches installed? Especially since the issue only shows up on Windows 7 installs that haven't received security patches since June 2016.

The issue shows up on patched machines. The patch does not enable TLS 1.2 by default. You have to add reg keys for it.

https://github.com/rust-lang/cargo/issues/5065#issuecomment-...

Re: Announcing Rust 1.24.1

#25

Post by Arnavion »

mtgx wrote: post #7
Freak_NL wrote: post #6

> Cargo couldn’t fetch the index from crates.io if you were using an older Windows without having applied security fixes. Why are developers (since this is an issue that shows up with cargo) running Windows 7 without security patches installed? Especially since the issue only shows up on Windows 7 installs that haven't received security patches since June 2016. > libgit2 created a fix, using the WinHTTP API to reques…

Although developers should know and do better, I think a big part of why they aren't doing it is because Microsoft has made it so hard to update Windows 7 since a year or two ago, all in the name of forcing people to switch to Windows 10. You now have to visit and manually download the updates from Microsoft's Update Catalog website. Oh, and that website only works on Internet Explorer.

No idea what you mean. Windows 7 receives updates from Microsoft through Windows Update just fine.

Re: Announcing Rust 1.24.1

#26

Post by maxaf »

varjag wrote: post #22
devit wrote: post #16

Earlier quoted context omitted.

Because unlike most other programming languages, Rust is well-engineered and seeks to both provide the most general abstractions possible and to make the code generated by them as efficient as possible. In particular, for this task, this requires to: 1. Return references to subranges of the original string, rather than copying them, so that no copy happens if you only need to examine the component instead of storing…

The better half of those points are directly and indirectly caused by insistence on manual memory management. Yes, it was a major design point of Rust, but it doesn't make it better engineered than "most other languages". It's just the corner it painted itself to.

Firstly, manual memory management is what happens when a C programmer must manually place malloc/free calls within her program. Rust doesn't require any of that; the compiler determines the right times to allocate and free memory, while requiring the programmer to follow certain design rules in exchange for the convenience.

Second, you're making it sound as if the position Rust (and those who program in it) is somehow undesirable. This state of things is the consequence of an explicit design goal, which was to accomplish automatic memory management without runtime cost.

Re: Announcing Rust 1.24.1

#27

Post by netheril96 »

varjag wrote: post #22
devit wrote: post #16

Earlier quoted context omitted.

Because unlike most other programming languages, Rust is well-engineered and seeks to both provide the most general abstractions possible and to make the code generated by them as efficient as possible. In particular, for this task, this requires to: 1. Return references to subranges of the original string, rather than copying them, so that no copy happens if you only need to examine the component instead of storing…

The better half of those points are directly and indirectly caused by insistence on manual memory management. Yes, it was a major design point of Rust, but it doesn't make it better engineered than "most other languages". It's just the corner it painted itself to.

Only point 2 is related to memory management, while all others could be applied to GC-enabled languages as optimizations just fine. That is 1/6th, not "better half".

Re: Announcing Rust 1.24.1

#28

Post by varjag »

maxaf wrote: post #26
varjag wrote: post #22

Earlier quoted context omitted.

The better half of those points are directly and indirectly caused by insistence on manual memory management. Yes, it was a major design point of Rust, but it doesn't make it better engineered than "most other languages". It's just the corner it painted itself to.

Firstly, manual memory management is what happens when a C programmer must manually place malloc/free calls within her program. Rust doesn't require any of that; the compiler determines the right times to allocate and free memory, while requiring the programmer to follow certain design rules in exchange for the convenience. Second, you're making it sound as if the position Rust (and those who program in it) is someho…

Interesting; I certainly wouldn't consider C++ constructor/destructor like semantics and manual tracking of object ownership in the code as automatic memory management. But regardless, the point stands.

And yes it's a consequence of a design goal, I said as much. The outcome however isn't beautiful enough to feel smug about the rest of programming languages.

Re: Announcing Rust 1.24.1

#29

Post by Someone »

HumanDrivenDev wrote: post #9

Rust gives me a headache. I want to like it, but it just seems so... overengineered https://doc.rust-lang.org/std/str/struct.SplitWhitespace.htm... Why would you create a special data type to represent a string split by Whitespace? Lunacy

I would call that underengineered. This could be more generic, both in what it operates on (why only strings and not any sequence of value items?) and what it separates on (why only Unicode whitespace? It could be used as return value from a call that iterates over CSV fields in a line or that finds regex matches in a string).

Re: Announcing Rust 1.24.1

#30

Post by microtonal »

varjag wrote: post #22
devit wrote: post #16

Earlier quoted context omitted.

Because unlike most other programming languages, Rust is well-engineered and seeks to both provide the most general abstractions possible and to make the code generated by them as efficient as possible. In particular, for this task, this requires to: 1. Return references to subranges of the original string, rather than copying them, so that no copy happens if you only need to examine the component instead of storing…

The better half of those points are directly and indirectly caused by insistence on manual memory management. Yes, it was a major design point of Rust, but it doesn't make it better engineered than "most other languages". It's just the corner it painted itself to.

Besides that Rust does not do manual memory management (as a peer commenter pointed out), Rusts borrowing rules also prevent typical ownership bugs. For instance:

- You split a string, returning an iterator or slice where every element is a slice of the original string.

- You change the original string.

- Now the splitting may be invalid.

Such bugs are not possible in Rust, since; (1) the SplitWhitespace struct borrows the str immutably; (2) the borrows checker does not permit simultaneously borrowing data as mutable and immutable.

Another problem that is prevented by Rust is 'memory leaks' where someone splits a large string and uses only a smaller substring. If the substring is a slice of the original string, a GC cannot deallocate the larger string. Rust prevents this, because a string slice reference (&str) cannot outlive the underlying String. [1]

tl;dr: better of the half points are indirectly and indirectly caused by Rust's ownership model that prevents a lot of ownership bugs. That does not mean that you do not have to think about ownership problems in other languages.

[1] Such memory leaks were one of the reasons why Oracle Java switched to a much slower, copying implementation of substring:

http://java-performance.info/changes-to-string-java-1-7-0_06...

Post reply on HN