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

Rust's 2017 Roadmap

blog.rust-lang.org

Post reply on HN
Print view View original

201–210 of 274 posts

Re: Rust's 2017 Roadmap

#201

Post by iopq »

kibwen wrote: post #98
steveklabnik wrote: post #47

Earlier quoted context omitted.

> What about the warts part? I'm not sure enough time has passed to tell what Rust's warts truly are. I always joke String should have been called StrBuf... I do this, yes. This is one of the reasons I hang out in IRC so often; it's an effective way to collect these kinds of things. More data is always better, and collecting it across multiple venues. I don't think IRC is inherently going to be a representative sampl…

> I always joke String should have been called StrBuf Agreed, and Vec should just be Buf! Let's fork the language. :)

And it should be white-space sensitive!

    1. Writing a tab character introduces the equivalent of {} for blocks, but not other uses of {}.
    2. You can still use {} for blocks if need be
    3. Everyone uses elastic tabstops in their editor
oh yeah, and parens are optional for function application

Re: Rust's 2017 Roadmap

#202

Post by lmm »

olivier1664 wrote: post #192

I would love to see some improvement in the desktop GUI libs. - GTK is a painfull to install. - Conrod: I was unable to do an hello world application with it. It just miss some tutorial. - KISS-UI: some dll to install - Qt: not totally free - Neon to plug on Electron: I'm not sure if I can do some callback from Rust to the GUI with this method. I finnally give up to play with Electron in javascript.

> Qt: not totally free

Qt has been free for decades and is LGPL these days, about as free as it gets. Is there some Rust-specific issue, or is this just decades-old FUD from the GNOME project?

Re: Rust's 2017 Roadmap

#203

Post by pkolaczk »

tom_mellior wrote: post #196
nostrademons wrote: post #179

Earlier quoted context omitted.

That may be true, but for programmers that can use GC, there are already very good solutions out there. New products succeed based on how much better they are than the other solutions in their market . Rust's genius is going after the market that can't use GC, which has seen few innovations in programming language design over the last 25 years. (C++11/14/17 has helped this situation immensely, but C++ is still behold…

> Rust's genius is going after the market that can't use GC But the problem with that is that the market that really really can't use GC is vanishingly tiny. Rust throws the baby out with the bathwater and tries to pressure others into thinking that they are in this market. Most developers on most projects aren't. And then Rust implements reference-counted pointers in the library, which is the slowest possible way of…

Well, even though I'm totally for using a modern GC when I can, implementing an efficient GC (low pause, high throughput) requires a lot of effort and special hardware. This is still not available for a number of platforms, particularly the tiny ones, where you may only dream of things like memory virtualization. Also, reference counting may not be as bad as you think when objects are never shared between threads and when you have a smart compiler that can elide most of redundant increments/decrements.

Re: Rust's 2017 Roadmap

#204

Post by tatterdemalion »

rspeer wrote: post #160
dbaupp wrote: post #155

Earlier quoted context omitted.

String == &str works. Maybe you were encountering some other problem.

Oh, I guess the case of this I encountered most recently was actually Option == Option . I get why that's different, but it would be great if the type system could figure that out, so that the literal Some("foo") could be an Option if necessary. Maybe I'm still being spoiled by Haskell's OverloadedStrings.

> Oh, I guess the case of this I encountered most recently was actually Option == Option.

There are pretty rough type inference issues preventing this impl from existing. Too many people are doing `opt == None` & the compiler would no longer be able to infer the type of None. (You should not be one of them, just call `is_none()` instead)

I'd like to see this impl some day but its not clear how to make it happen.

Re: Rust's 2017 Roadmap

#205

Post by wofo »

gcp wrote: post #38
agmcleod wrote: post #28

Earlier quoted context omitted.

Ive found Atom to be better in terms of having the lint as you go. RustyCode is pretty good though otherwise :). I'm interested to see where the debugging goes with it as well.

RUSTYCODE IS DEAD. I wish more people knew this, because it's probably the thing most people try to install as it has the most downloads. It's no longer maintained and doesn't work correctly with current stable. There's a fork that is being updated that's just called "Rust" in the VSCode addons.

Thanks! I was still using RustyCode...

Re: Rust's 2017 Roadmap

#206

Post by acqq »

pkolaczk wrote: post #200
richardwhiuk wrote: post #147

Earlier quoted context omitted.

Explicitly tracking shared mutability is for safety - obviously not mutability in of itself. Copying everything every time isn't a solution in a multithreaded world if you actually want your threads to share data.

"sharing data" is quite illusory. Even if two threads have a reference to the same object, the CPU deals with it internally by making several copies, asynchronous message passing and locking, and in many cases it can lead to abysmal performance. It is often much better for performance to design parallel algorithms around shared-nothing i.e. local mutability + explicit message passing right from the start.

> "sharing data" is quite illusory. Even if two threads have a reference to the same object, the CPU deals with it internally by making several copies, asynchronous message passing and locking,

No. Two threads on the same CPU core really access the same data(1) without the delay and no locking happens unless the programmer wrote some locking code.

Synchronizing the different cores or processors is another topic, but it's also typically dependent on the software.

----

1) But there is also reordering https://en.wikipedia.org/wiki/Memory_barrier and out-of-order execution https://en.wikipedia.org/wiki/Out-of-order_execution

Most of the time the implemented techniques do significantly speed up the execution. And it's mostly software design that initiates the slowdowns, not the CPU.

Re: Rust's 2017 Roadmap

#207

Post by yaantc »

tom_mellior wrote: post #196
nostrademons wrote: post #179

Earlier quoted context omitted.

That may be true, but for programmers that can use GC, there are already very good solutions out there. New products succeed based on how much better they are than the other solutions in their market . Rust's genius is going after the market that can't use GC, which has seen few innovations in programming language design over the last 25 years. (C++11/14/17 has helped this situation immensely, but C++ is still behold…

> Rust's genius is going after the market that can't use GC But the problem with that is that the market that really really can't use GC is vanishingly tiny. Rust throws the baby out with the bathwater and tries to pressure others into thinking that they are in this market. Most developers on most projects aren't. And then Rust implements reference-counted pointers in the library, which is the slowest possible way of…

> But the problem with that is that the market that really really > can't use GC is vanishingly tiny.

It's huge, but specialized so may not be on your radar: small embedded devices. Think RAM size from 10s to 100s kB, and Flash from 100s kB to few MBs as rough ranges.

The interest for IoT, and the need for battery operated devices with lifetime of 10+ years, make such platforms very important. And cost and process constraints (like embedded Flash) lead them to be implemented in conservative nodes: 55 to 40 nm typical, will go to 28nm in time but unlikely to go lower. So the amount of processing won't change much in this space I believe. An any gain would not be used to get a bigger CPU/RAM, but to reduce cost and power (less power is smaller batteries => cost too). So this space will stay on the very small side for the foreseeable future.

These are devices that run on very small micro-controller cores and are too small even for a striped down embedded Linux distro. It's either RTOS, or even simple run-to-completion preemptive schedulers, or even bare metal. No room for GC here, and Rust with its focus on performance, leanness and safety is very well suited as a language.

As a platform, the fact that there's only one LLVM based compiler for Rust is a limitation in this space. In the deep embedded space there are a lot of architectures for which there's no LLVM support (Cortus, Andes, BA Semi, LM32, Nios, ...). But I hope this as temporary. GCC is the most common toolchain there, and hopefully at one point GCC will gain a Rust front end. Or maybe LLVM will become more popular in this area? We'll see.

Re: Rust's 2017 Roadmap

#208

Post by adwn »

tom_mellior wrote: post #196
nostrademons wrote: post #179

Earlier quoted context omitted.

That may be true, but for programmers that can use GC, there are already very good solutions out there. New products succeed based on how much better they are than the other solutions in their market . Rust's genius is going after the market that can't use GC, which has seen few innovations in programming language design over the last 25 years. (C++11/14/17 has helped this situation immensely, but C++ is still behold…

> Rust's genius is going after the market that can't use GC But the problem with that is that the market that really really can't use GC is vanishingly tiny. Rust throws the baby out with the bathwater and tries to pressure others into thinking that they are in this market. Most developers on most projects aren't. And then Rust implements reference-counted pointers in the library, which is the slowest possible way of…

> But the problem with that is that the market that really really can't use GC is vanishingly tiny.

If you write a library in C#, you can use it from .NET languages. If you write a library in Java, you can use it from JVM-based languages. If you write a library in Python, you can use it from Python. If you write a library in Rust, you can use it from any language that can bind to C, which is virtually every language that matters.

That is not a "vanishingly tiny" market. It might not be your market, but that's okay: Rust doesn't have to be for everyone in order to be important.

> And then Rust implements reference-counted pointers in the library, which is the slowest possible way of collecting some, but not all, garbage.

That might be the case if you were to replace the JVM's GC with reference-counting, but Rust enables a data layout strategy in which a lot fewer allocations of larger individual objects take place (because not every object requires its own heap allocation). This way, RC in Rust is probably not slower (maybe even faster) than the GC in the JVM, while having a lower memory overhead at the same time.

Re: Rust's 2017 Roadmap

#209

Post by 1wd »

Manishearth wrote: post #158
1wd wrote: post #112

Earlier quoted context omitted.

Thanks, but I still don't see where such guarantees are advertised. Also it's not really clear what "the nursery" is exactly. Where is it? Why is it called that? It sounds more like "not mature = ready for prime time = don't use this". According to that link, regex is also in the nursery. According to crates.io, regex depends on other crates maintained elsewhere, by a "random" single developer, under a different lice…

Crates.io lists the authors as "The Rust Project Developers", and has the Rust libs team as an owner. The dependencies are almost all maintained by Rust libs team members or are otherwise trusted crates. https://crates.io/crates/regex (Regex moved out of the nursery a while back) The nursery is more of a "These crates are officially blessed and we wish to make them part of rust-lang, unless the community comes up wit…

Sorry, I meant the author and license of e.g. this dependency of regex: https://crates.io/crates/aho-corasick

I'm sure the Rust team knows and trusts these (or they even are Rust team members), but how should outsiders know this?

Researching trustworthiness of individual authors, getting approval for different licenses, tracking and updating required notices in documentation etc. for every single dependency transitively(!) seriously takes a lot of effort. Updating dependencies that switch sub-(sub-...)-dependencies freely can turn from a simple cargo command into a month of work. A big standard library (or an equivalent construct) can really save the day there.

> The guarantees aren't advertised, they're known.

It is known. -- Jhiqui

Glad to hear improving this is in the works anyway.

Re: Rust's 2017 Roadmap

#210

Post by 1wd »

steveklabnik wrote: post #121
1wd wrote: post #112

Earlier quoted context omitted.

Thanks, but I still don't see where such guarantees are advertised. Also it's not really clear what "the nursery" is exactly. Where is it? Why is it called that? It sounds more like "not mature = ready for prime time = don't use this". According to that link, regex is also in the nursery. According to crates.io, regex depends on other crates maintained elsewhere, by a "random" single developer, under a different lice…

RFCs are frozen in time; regex has since moved under rust-lang, and has a pre-release for a 1.0. That person isn't random; they're on the libs team and the primary author of regex. (there are a few crates by other people as well, but most of those crates were extracted from regex as they can be useful on their own.)

My point is researching all this puts a huge burden on (serious) users that would not be there for a big standard library. Currently the Rust approach seems quite problematic, but I think this can be solved. For example by an explicit guarantee pledged by the Rust team (or a related umbrella / organization / consortium / ...) for a certain set of libraries (platform / ecosystem / 2nd tier standard library extension / stdx / nursery / ...).

I think it would be important to include in this pledge:

* Transitive closure rule. (No external dependencies not covered by the pledge. Possibly with certain exceptions e.g. for bindings to big known obvious third party dependencies like SQL databases or Operating Systems.)

* Uniform licensing rule. (Everything must use the exact same license, with a single group name as copyright holders and for any purposes of required notices etc.)

* Maintenance, backward compatibility and platform compatibility rule. (100% compatibility forever everywhere is not even necessary, but an _explicit_ rule of thumb of what reasonable time frames for deprecation windows and recommended transition plans can be expected would be nice.)

Or maybe this already exists and I'm just uninformed?

Post reply on HN