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

81–90 of 248 posts

Re: The Road to Rust 1.0

#81

Post by austinz »

steveklabnik wrote: post #70
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

Awesome! Thanks.

Re: The Road to Rust 1.0

#82

Post by jroesch »

MichaelGG wrote: post #62
pestaa wrote: post #17

Earlier quoted context omitted.

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.

Yes. Many times the compiler will actually infer a type different than the one you wanted. In my experience this just leads to confused programmers who have trouble deciphering what went wrong when presented with the error message.

Re: The Road to Rust 1.0

#83

Post by steveklabnik »

pmahoney wrote: post #77
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.

I would probably make the same decision, but I hope in the end Caro is easy to wrap with Nix, which is a breath of fresh air particularly when needing to mix dependencies that cross language boundaries and share those build recipes with a team. Previously, I wrote shell scripts and worried whether everyone on the team had rsync installed, or xmlstarlet, or some other less common tool. Now I wrap those scripts in a Ni…

Cargo has the second, and there's a plan for the first.

That said, the reason that you want it to do the installation is that a lockfile is supposed to represent the way to do a build successfully. Without building everything, you can't actually be sure that the lockfile is correct. In theory, it should be...

Re: The Road to Rust 1.0

#84

Post by steveklabnik »

jmgrosen wrote: post #73
wycats wrote: post #61

Earlier quoted context omitted.

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.

Hm, I learned it more than a year ago now (and have kept up), so it was before Steve's time :) Also, I'm coming mainly from a C background, not higher-level language.

Well, before my time being paid anyway :)

Re: The Road to Rust 1.0

#85

Post by wycats »

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?

I'm sure that seemed true about web browsers too. The trick is feature flagging all new API surface and only including flagged code when it's deemed stable.

Re: The Road to Rust 1.0

#86

Post by steveklabnik »

spott wrote: post #74
steveklabnik wrote: post #58

Earlier quoted context omitted.

Nope. We're pretty sure they'll be backwards compatible, and there are too many other outstanding issues (eg, syntax) and too little time. Lots of us want them though!

There isn't an RFC for them, at least that I could find. Have they just not gotten that far in terms of thought?

That's right, there hasn't even been enough work for an RFC.

Re: The Road to Rust 1.0

#87

Post by jroesch »

spott wrote: post #74
steveklabnik wrote: post #58

Earlier quoted context omitted.

Nope. We're pretty sure they'll be backwards compatible, and there are too many other outstanding issues (eg, syntax) and too little time. Lots of us want them though!

There isn't an RFC for them, at least that I could find. Have they just not gotten that far in terms of thought?

I'm pretty sure at least a few people have ideas/are working on them. I have a 75% finished RFC that I have been sitting on because the language has been in such flux lately. I wouldn't be surprised if Niko, Aaron or someone else on the core team doesn't already have strong ideas about them.

Re: The Road to Rust 1.0

#88

Post by DennisP »

smacktoward wrote: post #35
JoshTriplett wrote: post #20

Earlier quoted context omitted.

> Curious to hear more about language-specific (though OS-agnostic!) package management systems. As far as I can tell, one of the main justifications for most language package management systems is "we also run on Windows/OSX, which has no package management, so we'll invent our own". As a result, users of systems that do have sane package management get stuck with multiple package management systems, one for the dis…

The other justification is generally a clash of cultures: the people who maintain distro/OS package managers generally come out of the culture of sysadmins, who value stability over feature-richness, while the people working the language communities generally come out of the culture of developers, whose priorities are the exact opposite. When languages try to hook into existing OS-level systems, the people on the lan…

Maybe OS-level package managers should default to stable, but let the user check a box to get the latest and greatest. Developers want a stable system like everyone else, but for the stuff we're hacking on, we have a legitimate need to get the most recent, so our software isn't obsolete by the time we finish it.

Re: The Road to Rust 1.0

#89

Post by burntsushi »

MichaelGG wrote: post #60
steveklabnik wrote: post #15

Earlier quoted context omitted.

Even in languages with whole-program inference, it's generally regarded as best practice to write out the types of your functions, hence Rust's choice here. You're right that there's a tradeoff. In general, Rust follows 'explicit over implicit.' > This gets annoying when you get into functions with complex arguments. Have you seen the where clauses yet? This should significantly help complex function declarations.

I just don't understand why there has to be a tradeoff. I just don't get why the compiler should decide on such a large thing, instead of letting the programmer do it. One can always be more explicit if one feels they're getting value from it. If someone wants to write a bunch of terse code, why stop them? Does the compiler gain a large benefit from not having to include this feature? Who loses by allowing users to d…

Rust will do type inference on lambdas for you. :-)

    fn fubar(x: uint) {
        let times = |n| x * n;
        println!("{} * 5 = {}", x, times(5));
    }
Rust only enforces type annotations on top-level functions.

> Does the compiler gain a large benefit from not having to include this feature? Who loses by allowing users to do what they want?

FWIW, I feel precisely the opposite as you. I'd rather have an ecosystem of code where top level functions must be annotated by types than an ecosystem where types are there only if the author feels like adding them. There is a small cost but a large gain, IMO.

Re: The Road to Rust 1.0

#90

Post by TheHydroImpulse »

spott wrote: post #74
steveklabnik wrote: post #58

Earlier quoted context omitted.

Nope. We're pretty sure they'll be backwards compatible, and there are too many other outstanding issues (eg, syntax) and too little time. Lots of us want them though!

There isn't an RFC for them, at least that I could find. Have they just not gotten that far in terms of thought?

I have an RFC sitting here (and a few blog posts talking about it), but considering it'll be post 1.0 when such a thing is even entertained, I haven't submitted it. There are more pressing and more appropriate things to work on first.
Post reply on HN