81–90 of 118 posts
Earlier quoted context omitted.
The JVM and CLR both have generational garbage collectors, which reduces the impact of most GC pauses quite significantly. Go's GC on the other hand is non-generational, which means every GC pause must perform a full scan of all objects in the system.
Is there a reason why future work on Go's runtime couldn't fix this problem?
Earlier quoted context omitted.
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…
You know a lot more about these things than I do. That said: Aren't the equivalent pointers in .Net _only_ allowed/usable if you pin your object? If you tell the GC explicitly 'please don't move that, I'm pointing to that thing here'? That's hard to bolt on to Go, imho. For Go it seems to be implicitly allowed, in .Net you have to ask explicitly?
So it's basically as if all objects are pinned in Go. I don't expect that to change. There are probably tons of Go code out there which will break in response to a change.
I guess it will be pushed back to some mystical "2.0" release, along with Generics.
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 tried to give Rust a try to build some stuff but my project required HTTP and there's no easy SSL solution in place right now. Hope it comes along. I don't have time to contribute much otherwise I would.
I am no language designer, but I wonder why use libuv and have to worry about implementing a scheduler and all the other components of a run time loop in your language when the kernel will do this for you. I think it would make more sense to provide a better interface to existing kernel structures then leverage a third party library and then re implement kernel functions around it ( I am mainly thinking about the par…
What if someone wants to write a kernel with Rust? This might be a very naive question taking into account my ignorance of language and kernel design.
It's rudimentary, but it does compile and it does run, and I'm not aware of any particular obstacles to a more featureful kernel.
I am no language designer, but I wonder why use libuv and have to worry about implementing a scheduler and all the other components of a run time loop in your language when the kernel will do this for you. I think it would make more sense to provide a better interface to existing kernel structures then leverage a third party library and then re implement kernel functions around it ( I am mainly thinking about the par…
What if someone wants to write a kernel with Rust? This might be a very naive question taking into account my ignorance of language and kernel design.
Earlier quoted context omitted.
Really the portability that matters in this case (games) is probably Windows, which llvm and clang do not target very well at this point.
We've been focused on first class Windows support since day one. The only major issue for LLVM itself that I'm aware of is the lack of PDB debug info, which is less of a problem for Rust because the system debuggers don't debug Rust in the first place. Most of the clang problems for Windows that I'm aware of relate to all the MSVC extensions in windows.h, which is not a problem for Rust as it doesn't use system heade…
Earlier quoted context omitted.
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 Interm…
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.
As someone else mentioned, C# is a big deal now and comes with a degree of safety over C++. I don't expect to see Rust in the pole position on the whole, but it could easily displace C++ at Id Software since Carmack has been shopping for an alternative, and elsewhere (especially if he runs with it first.)
But I think C++'s share is losing ground, and Unity is an impressive platform. The asm.js buzz seems to whisper promises about ES and browsers becoming a serious AAA gaming platform. If FFOS gets anywhere it may supply the necessary voltage. So the lay of the land is anyone's guess, but all the variables eat into C++'s % share even if only by expanding the market around it.
Earlier quoted context omitted.
We've been focused on first class Windows support since day one. The only major issue for LLVM itself that I'm aware of is the lack of PDB debug info, which is less of a problem for Rust because the system debuggers don't debug Rust in the first place. Most of the clang problems for Windows that I'm aware of relate to all the MSVC extensions in windows.h, which is not a problem for Rust as it doesn't use system heade…
I would think the harder platforms are the consoles: they often come with their own compilers that only support C and C++.
also, even before that there were people using "non-standard" toochains e.g. http://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp