11–20 of 118 posts
Earlier quoted context omitted.
Yes, please. Anything but C++. The progress of Rust and Go make me hopeful for the future.
Go (at least as it stands today with its non-generational, stop the world, mark and sweep GC) is wholly unsuitable for video game development where unpredictable latency must be avoided.
Earlier quoted context omitted.
Go (at least as it stands today with its non-generational, stop the world, mark and sweep GC) is wholly unsuitable for video game development where unpredictable latency must be avoided.
When latency matters, just use pool allocation, which makes the GC irrelevant.
Earlier quoted context omitted.
Yes, please. Anything but C++. The progress of Rust and Go make me hopeful for the future.
Go (at least as it stands today with its non-generational, stop the world, mark and sweep GC) is wholly unsuitable for video game development where unpredictable latency must be avoided.
See: Minecraft, Terraria, Magicka, AI War, and many more.
> it does implement TCP and UDP on both IPv4 and IPv6 I thought this sort of thing was usually handled by the OS. Can you even get raw sockets on most systems? Or by "implemented TCP", do they mean they can give you back a Unix TCP/UDP socket?
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…
> dogfooding-via-self-bootstrap Very rare thing. Ok maybe not in language design. But rare otherwise.
Earlier quoted context omitted.
Go (at least as it stands today with its non-generational, stop the world, mark and sweep GC) is wholly unsuitable for video game development where unpredictable latency must be avoided.
I don't completely disagree with your point, and I would not be a person to advocate Go for game development, but "wholly unsuitable" isn't true. A large number of successful games are released that depend on runtimes with similar garbage collectors. Most notably games running on the JVM and CLI. These are "real games" with real performance considerations. See: Minecraft, Terraria, Magicka, AI War, and many more.
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.
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…
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