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

New Rust runtime turned on. What next?

mail.mozilla.org

Post reply on HN
Print view View original

41–50 of 118 posts

Re: New Rust runtime turned on. What next?

#41

Post by BruceIV »

andrewflnr wrote: post #17

I really wish I had space in my TODO list to start a project in Rust. I don't think there's another dev tool I'm more excited about.

I started porting one of my side projects (written in C++11) to Rust because I thought it looked promising - I still think it does, but I filed two bug reports before I even got argument parsing working, and the documentation is still rather sparse. I don't want to dissuade you, it's a great project, and I hope it's the next C++, but it's very much not production-ready, so don't build anything critical in it yet.

Re: New Rust runtime turned on. What next?

#42

Post by pcwalton »

sanxiyn wrote: post #36
seanmcdirmid wrote: post #31

Earlier quoted context omitted.

Is there a reason why future work on Go's runtime couldn't fix this problem?

I wouldn't say impossible, but yes, there are reasons this is difficult to fix in Go compared to Java and C#, and intentionally so. Quoting from http://talks.golang.org/2012/splash.article (emphasis mine): "To give the programmer this flexibility, Go must support what we call interior pointers to objects allocated in the heap. The X.buf field in the example above lives within the struct but it is legal to capture the…

To be fair I don't think this is a blocker for Go to implement GGC and CGC. .NET supports interior pointers too, for example. You just have to design your allocator right to allow the card marking to work.

In practice I think that the biggest problems are compiler related and affect both Go and Rust. Go and Rust both use conservative GC on the stack and as a result they take a lot of shortcuts. For example, LLVM (and GCC as far as I'm aware, though someone like DannyBee may correct me here) loses the distinction between integers and pointers by the time they get to the machine instruction level, which makes a lot of optimizations easier to implement but also making it impossible to generate precise stack maps. Fixing this would be a lot of hard work. It's probably easier in the Plan 9 compilers, of course, though I suspect it's still going to be a lot of hard work.

Re: New Rust runtime turned on. What next?

#43

Post by Dn_Ab »

I haven't written anything in Rust yet but one of its most interesting aspects is its support for linear types. I expect that will share the same kind of perspective enriching attribute of learning logic, array or functional paradigms. While it's certainly not the first language to support substructural types, it looks the only one with a decent chance of developing a meaningful ecosystem.

The linear logic of J.-Y. Girard suggests a new type system for functional languages, one which supports operations that ``change the world''. Values belonging to a linear type must be used exactly once: like the world, they cannot be duplicated or destroyed. Such values require no reference counting or garbage collection, and safely admit destructive array update

http://homepages.inf.ed.ac.uk/wadler/topics/linear-logic.htm...

An interesting bit of trivia about linear types is they are in some sense the closest thing to programming a quantum computer this side of qubits (where no cloning dictates qubit variables can only be used once in a function term).

Re: New Rust runtime turned on. What next?

#44

Post by agentS »

pcwalton wrote: post #42
sanxiyn wrote: post #36

Earlier quoted context omitted.

I wouldn't say impossible, but yes, there are reasons this is difficult to fix in Go compared to Java and C#, and intentionally so. Quoting from http://talks.golang.org/2012/splash.article (emphasis mine): "To give the programmer this flexibility, Go must support what we call interior pointers to objects allocated in the heap. The X.buf field in the example above lives within the struct but it is legal to capture the…

To be fair I don't think this is a blocker for Go to implement GGC and CGC. .NET supports interior pointers too, for example. You just have to design your allocator right to allow the card marking to work. In practice I think that the biggest problems are compiler related and affect both Go and Rust. Go and Rust both use conservative GC on the stack and as a result they take a lot of shortcuts. For example, LLVM (and…

I've been following along on golang-dev, and they seem to be making progress on precise stacks.

See https://groups.google.com/forum/?fromgroups#!topic/golang-de... for example.

Re: New Rust runtime turned on. What next?

#45

Post by usea »

krichman wrote: post #40
pshc wrote: post #2

Excerpt from Graydon's (BDFL) reply: > Despite all these caveats I have a very strong sense that writing the > runtime in Rust will go a long way to validate Rust in the domains it's > aiming for: concurrent and systems programming. Even in the task > scheduler, where there's quite a bit of unsafe code, the shared-nothing > nature of unique types forces you to consciously break the type system > to share memory, and…

I, too, think Rust is going to be revolutionary in the video game industry. Were I a game programmer I would start learning now. In two years at least 51% of all new video game code will be in Rust.

I think you may be overestimating the pace of change. C++ is quite entrenched for industrial-strength game projects. The network effect is strong, the tooling is mature, and the projects are largely driven by C++ experts. Even if we see Rust 1.0 by the end of the year, it will take a lot of time for that kind of change to occur in the industry, if it ever does.

I think you're much more likely to see 51% of new game code written in C# for Unity. I think the median game budget is shrinking. More and more games are being made as small projects by small teams. Steam greenlight, kickstarter, humble bundle, and other avenues are enabling curation and funding of smaller games. Unity is far more suited for this kind of development than C++. If you look at smaller studios' job listings, a lot of them prefer experience with Unity. The trend is in full swing at this point.

I have no sources to site for the above information. Take it with a grain of salt.

Re: New Rust runtime turned on. What next?

#46

Post by Locke1689 »

dkhenry wrote: post #15
agumonkey wrote: post #4

Earlier quoted context omitted.

> dogfooding-via-self-bootstrap Very rare thing. Ok maybe not in language design. But rare otherwise.

I think its much less common in language design then we might give it credit for. Many languages run on a VM that is written in C including the likes of Java, Javascript, C#, Ruby and Python ( even PyPy compiles down to C ). I am sure there are others besides C that are self sustaining, but they are _very_ rare

I think you have a somewhat inaccurate mental model of how things are done.

For one, it doesn't really make sense to talk about the CLR when you talk about bootstrapping C#. My project (the Roslyn C# compiler) is a 100% C# implementation of the C# compiler. One thing to keep in mind is that we don't target the CLR.

The C# compiler is not a compiler from C# to the CLR, it's a compiler from C# to the CIL (Common Intermediate Language). It's completely reasonable to imagine a machine which runs CIL in hardware instead of in a VM. In this case the answer to the question of whether or not the C# compiler is bootstrapped is, "Yes. Completely."

Moreover, it wouldn't make sense to ask whether or not the CLR is self-hosted -- it's called the "Common Language Runtime" for a reason. It's a language-independent virtual machine. In this sense, implementing it in C++ makes just as much sense as implementing it in machine code.

Now, my argument here was meant to be without loss of generality. To ask whether or not a language is bootstrapped shouldn't really depend on a runtime, since any language which requires a runtime cannot, by definition, have the runtime written in said language. In this sense, we should only ask whether or not the compiler is bootstrapped, not the entire environment.

Re: New Rust runtime turned on. What next?

#47

Post by spullara »

pcwalton wrote: post #12
TylerE wrote: post #11

Earlier quoted context omitted.

When latency matters, just use pool allocation, which makes the GC irrelevant.

Pools are still traced.

If you pool everything, the GC never runs and tracing is irrelevant. However, getting to there is very difficult. Better is to just make sure you throw almost everything away before the next GC, have a small permanent runtime set of objects and accept 10-20ms stop the world young gen collections.

Re: New Rust runtime turned on. What next?

#49

Post by tyleregeto »

PommeDeTerre wrote: post #39
tyleregeto wrote: post #22

Earlier quoted context omitted.

I'm feeling the same way, Rust looks fantastic. There are a few things in the language I'm not huge fan of, I don't like overly subtle things in a language. For example, some of the functionality around semi colons seem like they will be a common source of stupid programmer bugs that are difficult to track down. Perhaps the compiler will catch that stuff. Go kinda ruined other languages for me with multiple return va…

Rust does have a lot of potential, but don't underestimate how much change it has undergone lately, and will likely be undergoing in the future. The large amount and rapidity of change makes it difficult to use it seriously. It's nowhere near as stable as other newer languages like Go and Scala are, for instance. Some experimental programs I wrote a mere 8 months ago are now basically unusable with recent versions of…

This is true, though I do believe it is a lot more stable than about 12 months ago(?)

It reminds me of Go a couple of years ago, but that had "go fix" which would mostly update your source files to the newest revisions. That made early adoption a lot nicer. I'd love to see a "rust fix"

Re: New Rust runtime turned on. What next?

#50

Post by oconnor0 »

jzwinck wrote: post #28
pcwalton wrote: post #19

Earlier quoted context omitted.

Three reasons. First, we don't control the kernel and we don't want to make assumptions about thread spawning being cheap on every OS. Second, it lets us implement work stealing, which is a proven method for dynamic parallelism. Third, it lets us do some operations such as RPC from task to task entirely in userspace with no trip through the scheduler or OS kernel.

Good points. A counterpoint for #3 is that you could do kernel bypass RPC by installing a driver, but Rust developers probably don't want to write all those drivers, and Rust users wouldn't want to install them. Work (task) stealing is very compelling, and a little paradigm shift is no bad thing. If Rust or any new systems language stands a chance, it should aim high and not too close to the past.

And then drivers would be required for each OS creating an additional porting burden.
Post reply on HN