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

One year of Rust

blog.rust-lang.org

Post reply on HN
Print view View original

81–90 of 110 posts

Re: One year of Rust

#81

Post by Manishearth »

Lewisham wrote: post #37
merb wrote: post #4

Earlier quoted context omitted.

Except the tooling, could be better. A language like Rust will benefit from a rich IDE a lot. But still the language is great.

I'd say rustdoc is pretty rough. It's very hard to navigate the rust stdlib vs, say, Go, and when you do find what you want, it's often specified in some very cryptic manner that seems to require a PL PhD. It is a really big barrier to adoption because it's very hard to find out what functionality is or is not offered. Here's an example: I want to iterate over a set. Easy, right? No. http://static.rust-lang.org/doc/m…

I'm surprised, I find Go's doc generator to be very rudimentary. For example, you can't find the implementations of an interface, and given that interfaces are used often I have to resort to grepping the code to see what it means.

> I want to iterate over a set. Easy, right?

yes, it is easy, `for value in &set {}`. Not sure why you went all the way down to `Cycle`

In this case I agree that perhaps rustdoc should note that a full description should be alluded to (the full description of Cycle is on the Iterator trait's docs), but it's still IMO much better than go

Re: One year of Rust

#82

Post by jamescun »

aleksi wrote: post #52

> While much of Dropbox’s back-end infrastructure is historically written in Go I'm sorry, but much of Dropbox’s back-end infrastructure is historically written in Python, not Go. Go is a new addition to the stack. Only a small and very specific part of Dropbox is written in Rust, where things like an effectiveness of CPU caches becomes important. Other back-end code is still being written in Go.

Yeah, this extract does feel a little out of place and almost like a dig at Go. I'm sure it is not but a little clarification wouldn't go amiss.

To my knowledge Dropbox's backend is migrating (slowly) from Python to Go (new default), with Rust for some specialist features where the memory management model is preferable.

Re: One year of Rust

#83

Post by megrimlock »

pcwalton wrote: post #57
Lewisham wrote: post #37

Earlier quoted context omitted.

I'd say rustdoc is pretty rough. It's very hard to navigate the rust stdlib vs, say, Go, and when you do find what you want, it's often specified in some very cryptic manner that seems to require a PL PhD. It is a really big barrier to adoption because it's very hard to find out what functionality is or is not offered. Here's an example: I want to iterate over a set. Easy, right? No. http://static.rust-lang.org/doc/m…

> fn cycle(self) -> Cycle where Self: Clone I agree that a summary would be good, but this doesn't require a PL Ph.D. It means "cycle is a method that moves its receiver and returns a Cycle object of the same type of the receiver, and only works if the receiver is cloneable". The trickiest thing here, IMHO, is move semantics, which is something fundamental to Rust in general.

Perhaps there's room for a rust equivalent of cdecl, a tool to map rust to plain English descriptions, offering a gradual onramp to the syntax.

This kind of thing seems silly to experts but could raise the rate at which folks make it through language learning funnel.

Re: One year of Rust

#84

Post by [deleted] »

Manishearth wrote: post #81
Lewisham wrote: post #37

Earlier quoted context omitted.

I'd say rustdoc is pretty rough. It's very hard to navigate the rust stdlib vs, say, Go, and when you do find what you want, it's often specified in some very cryptic manner that seems to require a PL PhD. It is a really big barrier to adoption because it's very hard to find out what functionality is or is not offered. Here's an example: I want to iterate over a set. Easy, right? No. http://static.rust-lang.org/doc/m…

I'm surprised, I find Go's doc generator to be very rudimentary. For example, you can't find the implementations of an interface, and given that interfaces are used often I have to resort to grepping the code to see what it means. > I want to iterate over a set. Easy, right? yes, it is easy, `for value in &set {}`. Not sure why you went all the way down to `Cycle` In this case I agree that perhaps rustdoc should note…

[deleted]

Re: One year of Rust

#85

Post by Rusky »

lossolo wrote: post #80

I've tried to learn Rust twice because i think it's great idea (memory safety with C++ performance) BUT... Rust seems even more complicated than C++ for me, really i find C++11/14 a lot easier to reason about than Rust. I am not sold on functional programming also. Dangling pointers/memory leaks are problems of C and old C++ but not modern C++. I don't remember when i last seen any memory problems in modern c++ code…

Probably getting downvoted because the assertion that modern C++ solves memory leaks is getting kind of tired as far as Rust discussions go, and is also missing the point.

Rust doesn't solve memory leaks, it solves memory unsafety- things like use-after-free and iterator invalidation that modern C++ does virtually nothing to help with, and that vulnerability statistics show are still huge problems with programs written in C++.

Re: One year of Rust

#86

Post by [deleted] »

pcwalton wrote: post #23
Animats wrote: post #20

Earlier quoted context omitted.

That's gotten much better since 1.0. Prior to 1.0, you needed to revise your Rust program about once a week so it would compile. Now the language has settled, but the libraries are still churning. One of the big advantages of Go is that it comes with a coherent set of libraries from a single source (Google) that do most of the things you'd want to do on a server. Rust is more like Python; many people write libraries,…

The advantages of having a distributed ecosystem vs. having a monolithic standard library is an extremely polarized topic, and I don't want to start that debate. But I do want to emphasize that Rust libraries follow semver, and the lock features of Cargo mean that your builds are always reproducible and you upgrade only when you want to. Your code will never stop compiling one day just because some library "churned".

[deleted]

Re: One year of Rust

#87

Post by jayflux »

Animats wrote: post #20
jandrese wrote: post #13

Earlier quoted context omitted.

This is one thing that's a little annoying to me. I know if I develop a Rust app today I can't leave it alone or it will decay horribly.

That's gotten much better since 1.0. Prior to 1.0, you needed to revise your Rust program about once a week so it would compile. Now the language has settled, but the libraries are still churning. One of the big advantages of Go is that it comes with a coherent set of libraries from a single source (Google) that do most of the things you'd want to do on a server. Rust is more like Python; many people write libraries,…

"Rust is more like Python; many people write libraries, many of which overlap and some of which work."

Odd comparison, Python actually has quite a comprehensive, well used standard library, which usually gives you enough to get going.

Using NodeJS as an example would've made more sense, where most libraries/modules are user written.

Re: One year of Rust

#88

Post by laughinghan »

kibwen wrote: post #48
steveklabnik wrote: post #6

Earlier quoted context omitted.

Rust has been in development for almost a decade at this point; but the language changed significantly many times before 1.0. It's been one year since the 1.0 release, which is the language we know today as "Rust". All those older languages are dead and gone now. I'm actually doing a talk about the ACM's Applicative conference in NYC this year talking about the history of Rust.

For the record, I take issue with the "almost a decade" label, development on Rust didn't start in earnest until 2010 at the earliest. :P It's about as misleading as saying that Go is 40 years old just because its commit graph goes back that far ( https://github.com/golang/go/graphs/contributors ).

The 4 commits before 2008 are pretty clearly not development on Go in any sense, they appear to be Brian Kernighan playing with the syntax and styling for a C "hello world" program: https://github.com/golang/go/commits/master?page=810

No one would say those commits show he was working on Go as a "personal project" during that time.

Re: One year of Rust

#89

Post by dbaupp »

Rusky wrote: post #85
lossolo wrote: post #80

I've tried to learn Rust twice because i think it's great idea (memory safety with C++ performance) BUT... Rust seems even more complicated than C++ for me, really i find C++11/14 a lot easier to reason about than Rust. I am not sold on functional programming also. Dangling pointers/memory leaks are problems of C and old C++ but not modern C++. I don't remember when i last seen any memory problems in modern c++ code…

Probably getting downvoted because the assertion that modern C++ solves memory leaks is getting kind of tired as far as Rust discussions go, and is also missing the point. Rust doesn't solve memory leaks, it solves memory unsafety - things like use-after-free and iterator invalidation that modern C++ does virtually nothing to help with, and that vulnerability statistics show are still huge problems with programs writ…

I wrote something on the memory leak vs. memory unsafety confusion a while ago, for those interested in exploring it more: http://huonw.github.io/blog/2016/04/memory-leaks-are-memory-...

Re: One year of Rust

#90

Post by lossolo »

Rusky wrote: post #85
lossolo wrote: post #80

I've tried to learn Rust twice because i think it's great idea (memory safety with C++ performance) BUT... Rust seems even more complicated than C++ for me, really i find C++11/14 a lot easier to reason about than Rust. I am not sold on functional programming also. Dangling pointers/memory leaks are problems of C and old C++ but not modern C++. I don't remember when i last seen any memory problems in modern c++ code…

Probably getting downvoted because the assertion that modern C++ solves memory leaks is getting kind of tired as far as Rust discussions go, and is also missing the point. Rust doesn't solve memory leaks, it solves memory unsafety - things like use-after-free and iterator invalidation that modern C++ does virtually nothing to help with, and that vulnerability statistics show are still huge problems with programs writ…

I don't see usage of new/free without encapsulation, this is not modern c++ which invalidates your point. Using naked new/free is depreciated in modern c++ and is problem of C not modern C++. What kind of statistics? Can you give any links that support what you wrote? All memory leaks/buffer overflows that i saw lately are associated with C (openssl, libc etc) not with C++. For iterator invalidation there are couple of simple rules to remember or for example you can use std::insert_iterator that will not be invalidated even if relocation occurs. You could use static analyzer and would avoid most of the problems.

EDIT: My point is that i have nothing to gain from rust when knowing c++ and memory management rules + i got good static analyzer. But probably for someone that do not know C++ at all Rust could be a better choice.

Post reply on HN