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

31–40 of 248 posts

Re: The Road to Rust 1.0

#31

Post by haberman »

steveklabnik wrote: post #9
JoshTriplett wrote: post #8

I used to describe my preferred family of languages as: - C when I absolutely had to (kernel/modules/plumbing). - Python for scripting and broad accessibility. - Haskell when I had the choice and I knew everybody who would work on the project. I was skeptical of Rust when it first came out, due in large part to the many different kinds of pointers it originally had, many of which involved significant manual memory ma…

Rust does not have any garbage collection, to be clear. All your other features are correct though :) (We have previously said "opt-in GC" but that was a lie. See https://news.ycombinator.com/item?id=8312327 for more.)

I am a huge fan of no required GC, and of precise refcounting. But does Rust have anything on the roadmap to handle truly cyclic structures that don't lend themselves to a weak pointer approach?

Re: The Road to Rust 1.0

#32

Post by steveklabnik »

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.

Re: The Road to Rust 1.0

#33

Post by doe88 »

JoshTriplett wrote: post #8

I used to describe my preferred family of languages as: - C when I absolutely had to (kernel/modules/plumbing). - Python for scripting and broad accessibility. - Haskell when I had the choice and I knew everybody who would work on the project. I was skeptical of Rust when it first came out, due in large part to the many different kinds of pointers it originally had, many of which involved significant manual memory ma…

> Disappointing to see yet another language-specific package management system (Cargo), though.

Coming from Python I find Cargo very very smart and very well thought so far, it is not feature heavy, but everything has a very clear and useful purpose. For instance today I found that if I created a file .cargo/config I could override my dependancies to make Cargo search projects on my fs instead of grabbing them on Github, while doing developments it's a big thing I think.

Re: The Road to Rust 1.0

#34

Post by someone13 »

haberman wrote: post #31
steveklabnik wrote: post #9

Earlier quoted context omitted.

Rust does not have any garbage collection, to be clear. All your other features are correct though :) (We have previously said "opt-in GC" but that was a lie. See https://news.ycombinator.com/item?id=8312327 for more.)

I am a huge fan of no required GC, and of precise refcounting. But does Rust have anything on the roadmap to handle truly cyclic structures that don't lend themselves to a weak pointer approach?

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

Re: The Road to Rust 1.0

#35

Post by smacktoward »

JoshTriplett wrote: post #20
pestaa wrote: post #14

Earlier quoted context omitted.

Curious to hear more about language-specific (though OS-agnostic!) package management systems. IMO composer is the best thing ever happened to PHP, Ruby gems are huge, Python eggs also make a very useful ecosystem. OpenSUSE's Open Build System would be great to ship independent packages, but those are again heavily tied to Unices, hence leaving other platforms behind.

> 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 language end get frustrated by the way the people on the package-manager end don't hurry to rush out bleeding-edge versions of packages the second they hit Github. To the package-manager people, that's no big deal, their orientation towards stability and predictability makes them comfortable with waiting a little for the coffee to cool. But to the developers, who want to get their hands on the Latest and Greatest Right Now!, it feels like slogging though molasses.

So the developers eventually end up blowing their stacks and stomping off yelling "Yeah? Well fine, we'll build our own package manager then! With blackjack! And hookers!"

Re: The Road to Rust 1.0

#36

Post by thomasahle »

haberman wrote: post #31
steveklabnik wrote: post #9

Earlier quoted context omitted.

Rust does not have any garbage collection, to be clear. All your other features are correct though :) (We have previously said "opt-in GC" but that was a lie. See https://news.ycombinator.com/item?id=8312327 for more.)

I am a huge fan of no required GC, and of precise refcounting. But does Rust have anything on the roadmap to handle truly cyclic structures that don't lend themselves to a weak pointer approach?

Maybe try to avoid these as much as you can - they make the code complicated in any language - and if you must, then manage the memory yourself?

Re: The Road to Rust 1.0

#37

Post by pbsd »

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.

People tend to expect more stability from a systems language than a web one. Can I trust that my Rust 1.0 code will work, unchanged, 20 years from now? If not, the language is likely to remain in the enthusiast realm.

Re: The Road to Rust 1.0

#38

Post by steveklabnik »

pbsd wrote: post #37
steveklabnik wrote: post #32

Earlier quoted context omitted.

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.

People tend to expect more stability from a systems language than a web one. Can I trust that my Rust 1.0 code will work, unchanged, 20 years from now? If not, the language is likely to remain in the enthusiast realm.

To be clear, Rust is following SemVer, and the six-week releases are 1.x versions. So they should be backwards compatible. There's no current timeline for a 2.x.

Re: The Road to Rust 1.0

#39

Post by Ygg2 »

JoshTriplett wrote: post #8

I used to describe my preferred family of languages as: - C when I absolutely had to (kernel/modules/plumbing). - Python for scripting and broad accessibility. - Haskell when I had the choice and I knew everybody who would work on the project. I was skeptical of Rust when it first came out, due in large part to the many different kinds of pointers it originally had, many of which involved significant manual memory ma…

> Disappointing to see yet another language-specific package management system (Cargo), though.

I don't think it is. You need support for Rust modules on various platforms Linux/Mac/Windows(possibly Android). No single tool works on all those platforms. Cargo does and it has minimal dependencies.

Not having to juggle three different configuration (CMake, Makefile, etc.) on different platform is actually pretty great.

Re: The Road to Rust 1.0

#40

Post by wycats »

haberman wrote: post #31
steveklabnik wrote: post #9

Earlier quoted context omitted.

Rust does not have any garbage collection, to be clear. All your other features are correct though :) (We have previously said "opt-in GC" but that was a lie. See https://news.ycombinator.com/item?id=8312327 for more.)

I am a huge fan of no required GC, and of precise refcounting. But does Rust have anything on the roadmap to handle truly cyclic structures that don't lend themselves to a weak pointer approach?

I think what you want is a cycle collector, and to invoke it at appropriate points. I don't see why Rust couldn't have a refcounted pointer type with an invokable cycle collector, but maybe someone on the core team could chime in here.
Post reply on HN