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

The Road to Rust 1.0

blog.rust-lang.org

Post reply on HN
Print view View original

61–70 of 248 posts

Re: The Road to Rust 1.0

#61

Post by wycats »

jmgrosen wrote: post #57
Q6T46nT668w6i3m wrote: post #46

Earlier quoted context omitted.

C++ is useful when learning Rust since a lot of documentation assumes the reader is familiar with C++ and there’s plenty of C++ documentation that has no pre-requisites.

Hmm. I learned Rust without any C++ knowledge (though I did have a fair amount of experience with C), and it was pretty easy. Recently I've had to start writing some C++ (to my dismay), and it has not been so easy... the language is really complex.

I think things have changed :)

Steve Klabnik has been doing a ton of work on the docs, and that has brought a lot of "coming from an HLL" perspective to them.

Re: The Road to Rust 1.0

#62

Post by MichaelGG »

pestaa wrote: post #17
MichaelGG wrote: post #13

Rust looks fantastic, and has a lot of things I wish I could do while in a higher level language like F#. I just wish Rust was a bit less verbose. Requiring, for instance, type annotations on function arguments because it's sometimes helpful is such a weird decision. Let the programmer decide when an annotation is needed. This gets annoying when you get into functions with complex arguments. Especially for local func…

Fully typed function signatures form a kind of contract you can program against. Haskell and other extremely strongly typed languages can infer the types of function parameters, yet the community still agrees it is good practice to annotate your work.

Would Haskell be better off if the compiler enforced this community agreement, instead of letting users decide?

Also, the type annotations can be added on later. While you work and play with ideas, leave everything unannotated. After it's cemented and perhaps refactored a bit, add the "contract". In Rust, even while working things out, the user has to figure out and jot down the types.

Re: The Road to Rust 1.0

#63

Post by eCa »

steveklabnik wrote: post #32
eCa wrote: post #30

I haven't looked at Rust, but it seems from the outside that releasing a stable version of a language every six weeks is very aggresive?

Continuous deployment is common in the web world. It's true that it's aggressive, but we think it's going to have significant benefits.

Yes, I'm not saying it's a bad thing. It does imho put a lot more pressure on the language developers than a cd'd web app, with regards to backwards compatibility and such. (With ~10 releases a year there's bound to be accidental breakage that passes the beta period.)

Ambitious might have been a better word than aggresive..

Re: The Road to Rust 1.0

#64

Post by derefr »

steveklabnik wrote: post #59
adrusi wrote: post #56

Earlier quoted context omitted.

The goal of the [nix]( http://nixos.org/ ) project is to solve this, and every time anyone brings up a package manager on HN, someone has to mention nix. The reality is that nix is really nice, but isn't any better than making a new package manager until it has wide adoption, so no one is using it.

Nix was brought up during the discussion that led to Cargo, but no Windows support is a deal breaker.

Wouldn't it still have been less effort to port Nix to Windows, than to write an entirely new package manager and then port it to every OS?

Re: The Road to Rust 1.0

#65

Post by ranran876 »

hadoukenio wrote: post #43

Still sitting on the fence as to which language I should pick up on next - the only contenders are C++11 and Rust. How does Rust compare with C++11 as a language? C++11 seems to (in some ways) have caught up with what Rust has to offer (compared to older C++ versions) e.g. smart pointers, concurrency and regexes part of the standard library

I'd definitely pick C++11 unless you need to use Rust.

Rust is inherently memory safe - however in practical terms this isn't important for most applications. If you are writing security critical applications Rust will provide you with some very important guarantees (ie. there are certain mistakes which are inherently not possible in the language). C++ doesn't really guarantee anything and if you're an idiot you can shoot yourself in the face. However in practical terms memory management in C++11 is very straightforwards and C++11 compliant code (ie. using the STL and not writing it like C) is very safe and clean. You're not mucking with raw pointers anymore

The main issue I see is that Rust is still in early development. It may or may not get "big" in the coming years. And library support is ... lacking

In contrast C++ has the STL and boost and every library under the sun. I haven't working with a lot of other languages extensively, but I've never seen anything as clean, robust and thorough as the STL and boost. C++ will remain relevant for a long long time. If Rust takes off in a big way, you'll be well positioned to jump ship.

Re: The Road to Rust 1.0

#66

Post by steveklabnik »

derefr wrote: post #64
steveklabnik wrote: post #59

Earlier quoted context omitted.

Nix was brought up during the discussion that led to Cargo, but no Windows support is a deal breaker.

Wouldn't it still have been less effort to port Nix to Windows, than to write an entirely new package manager and then port it to every OS?

If that were the only downside, possibly. I don't really do Windows development, so I can't tell you how difficult porting Nix would be. There's large advantage to having a packaging system that knows your language well. It's going to have tighter integration than a generic one ever could.

Re: The Road to Rust 1.0

#67

Post by hadoukenio »

ranran876 wrote: post #65
hadoukenio wrote: post #43

Still sitting on the fence as to which language I should pick up on next - the only contenders are C++11 and Rust. How does Rust compare with C++11 as a language? C++11 seems to (in some ways) have caught up with what Rust has to offer (compared to older C++ versions) e.g. smart pointers, concurrency and regexes part of the standard library

I'd definitely pick C++11 unless you need to use Rust. Rust is inherently memory safe - however in practical terms this isn't important for most applications. If you are writing security critical applications Rust will provide you with some very important guarantees (ie. there are certain mistakes which are inherently not possible in the language). C++ doesn't really guarantee anything and if you're an idiot you can…

Wow, that was a great comment and exactly the type of info I was after.

I think (coming from a dynamic language world) the memory safeness is what pulls me towards Rust. But from what you say and what I've read elsewhere, that was old-style C++ and not C++1[17].

Thanks!

Re: The Road to Rust 1.0

#68

Post by austinz »

Congratulations to the Rust team! Can't wait to start learning the language and building stuff using it.

I'm looking to learn about how Rust's refcounting memory management works (and how it differs from how, e.g. Objective-C or Swift's runtime-based reference counting works), mostly for personal edification. Can anyone point me to any good resources?

Re: The Road to Rust 1.0

#69

Post by bitbckt »

haberman wrote: post #41
someone13 wrote: post #34

Earlier quoted context omitted.

One option would be to allocate objects out of an arena[0] and then destroy the entire thing at once when you're finished with the contained objects. [0] http://doc.rust-lang.org/arena/index.html

Makes sense. If anyone is interested, I think it could be interesting to see if the refcounting approach I developed for handling cyclic references in my library "upb" would work as a Rust library: https://github.com/haberman/upb/blob/master/upb/refcounted.h The basic idea is that you refcount groups of objects instead of refcounting objects independently. You compute the groups dynamically such that no cycle can spa…

This sounds like an interesting variant on a Train collector.

Re: The Road to Rust 1.0

#70

Post by steveklabnik »

austinz wrote: post #68

Congratulations to the Rust team! Can't wait to start learning the language and building stuff using it. I'm looking to learn about how Rust's refcounting memory management works (and how it differs from how, e.g. Objective-C or Swift's runtime-based reference counting works), mostly for personal edification. Can anyone point me to any good resources?

Is worth noting that you don't reach for reference counting by default in Rust: your reach for references, then boxes, THEN Arc.

You can find documentation on these types here: http://doc.rust-lang.org/guide-pointers.html

Post reply on HN