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

191–200 of 274 posts

Re: Rust's 2017 Roadmap

#191

Post by richardwhiuk »

vertex-four wrote: post #118
JoelMcCracken wrote: post #108

Earlier quoted context omitted.

This is one of those things that seem plausible, but I have no idea if its really true. I'm not disagreeing, I just can't see it as being obviously true. Can you give me an example of how a fuzzy idea of ownership causes, ideally, a real problem, or a less ideally a simplified example problem? I'm 100% genuinely interested in this.

It's pretty much the reason for segfaults and use-after-free issues (which manifest as either memory corruption or security vulns) in reasonably sized codebases - without a good understanding of ownership, it's non-obvious when a pointer is supposed to become invalid, and if that doesn't match up with when the data is actually freed, you have an issue that's hard to track down later. If you're using a language with g…

If you don't understand your object graph, then maintaining a large codebase is going to become very difficult. You'll get questions like 'who is responsible for updating this object' or 'who is responsible for notifying when X happens', or 'why does every object talk to every other object', or 'why does it work very slowly when there's a large number of objects'

Re: Rust's 2017 Roadmap

#192

Post by olivier1664 »

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.

Re: Rust's 2017 Roadmap

#193

Post by legulere »

Ericson2314 wrote: post #177
jeffdavis wrote: post #176

Earlier quoted context omitted.

It's about the runtime. I think that's probably the most important reason, even more so than memory management or performance. If you need to write a library to implement the latest protocol, or render the latest image format, or parse the latest serialization format, then Haskell seems great. Unfortunately, the resulting library will be useless except to other Haskell programmers. Nobody wants to link in libXYZ.a an…

Honestly for most programmers, no GC is a red herring.

Try to get two programming languages to cooperate that use different GCs/runtimes. Not one combination out of the following works: C#, Java, Python, Ruby, Haskell. Because rust is runtime-less you can combine it with any of those programming languages.

Re: Rust's 2017 Roadmap

#194

Post by gcp »

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.

GTK is a painfull to install.

Also pretty bad on Windows AFAIK?

My personal wish would be for an easy way to use Servo to render the UI.

Re: Rust's 2017 Roadmap

#196

Post by tom_mellior »

nostrademons wrote: post #179
Ericson2314 wrote: post #177

Earlier quoted context omitted.

Honestly for most programmers, no GC is a red herring.

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 collecting some, but not all, garbage.

Honestly, if Rust is to become popular, it needs (a) to get rid of this elitist "we are awesome systems programmers" mindset, and (b) a good, optional way to use a GC where it makes sense, with good support for migrating away from it (i.e., by giving you a list of "I cannot determine the lifetime of this object, so it will be allocated on the GC heap" diagnostics on request).

Good cases can be made for having a no-GC mode, but having it exclusively is just premature optimization.

Re: Rust's 2017 Roadmap

#197

Post by blaenk »

gcp wrote: post #194
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.

GTK is a painfull to install. Also pretty bad on Windows AFAIK? My personal wish would be for an easy way to use Servo to render the UI.

That's actually a cool idea. IIRC Servo was even (going to?) comply to the chromium embedded framework API/ABI so that it could be a drop-in replacement. If they're doing that, hopefully they'll go further in creating a rich API for embedding.

Re: Rust's 2017 Roadmap

#198

Post by lmm »

nostrademons wrote: post #179
Ericson2314 wrote: post #177

Earlier quoted context omitted.

Honestly for most programmers, no GC is a red herring.

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…

Are the with-GC options really that much better? Rust or OCaml's advantages over C++ seem much the same as OCaml's advantages over, say, Java, no?

Re: Rust's 2017 Roadmap

#199

Post by rkangel »

legulere wrote: post #193
Ericson2314 wrote: post #177

Earlier quoted context omitted.

Honestly for most programmers, no GC is a red herring.

Try to get two programming languages to cooperate that use different GCs/runtimes. Not one combination out of the following works: C#, Java, Python, Ruby, Haskell. Because rust is runtime-less you can combine it with any of those programming languages.

This is one of those points that is so obvious that it has never occurred to me.

Re: Rust's 2017 Roadmap

#200

Post by pkolaczk »

richardwhiuk wrote: post #147
tormeh wrote: post #126

Earlier quoted context omitted.

Copying everything every time is a trivial (and very slow) solution to the memory safety problem. It just means that everything is on the stack (or at least that only one stack frame has a reference to any given object), so it is simply deallocated along with the stack frame. That's it. There's nothing unsafe about it. What do you mean by saying mutability is for safety? That's a very unusual opinion.

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.
Post reply on HN