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

A Doom Renderer written in Rust

github.com

Post reply on HN
Print view View original

41–50 of 69 posts

Re: A Doom Renderer written in Rust

#41

Post by jeffdavis »

melling wrote: post #5
comex wrote: post #2

This is sort of off topic, but the fact that every change to the source requires (on my machine) 3-4 full seconds to recompile, without optimization, is indicative of the compiler performance problems that remain my main roadblock with Rust.

Turbo Pascal and Delphi had incredibly fast compilers. Why can't we make fast compilation a required feature today? We should never have to wait for the compiler/linker. http://prog21.dadgum.com/47.html

Why?

First and foremost, a language must satisfy some need that is not met adequately by another existing language. Otherwise it's useless.

There are languages already with fast compilers, and some of them are pretty fast and have pretty good semantics.

Rust is really trying to offer a combination of things not available elsewhere: safety, speed, and control. But that innovation is based heavily on compiler features, which have a compile-time performance penalty.

Assuming rust succeeds on delivering an innovative new language, they can secondarily try to improve compiler performance. Or find ways to avoid paying some compile-time costs in certain situations.

Re: A Doom Renderer written in Rust

#44

Post by simias »

pjc50 wrote: post #36
comex wrote: post #2

This is sort of off topic, but the fact that every change to the source requires (on my machine) 3-4 full seconds to recompile, without optimization, is indicative of the compiler performance problems that remain my main roadblock with Rust.

3-4 seconds is extremely fast if you're coming from the C/C++ world. I can't see how this could possibly be a roadblock.

C++ definitely if you're using heavily templated code, C not so much though.

Although I agree with your point, I've been using Rust quite a lot lately and compilation time was never an issue so far.

Re: A Doom Renderer written in Rust

#45

Post by steveklabnik »

adamnemecek wrote: post #15
comex wrote: post #2

This is sort of off topic, but the fact that every change to the source requires (on my machine) 3-4 full seconds to recompile, without optimization, is indicative of the compiler performance problems that remain my main roadblock with Rust.

It's probably better that before 1.0, the development effort concentrates on getting the language right rather than compilation speed which can be fixed later.

While this is true, it's also important that things aren't introduced which make these kinds of optimizations impossible. I think we've done a good job of that, but it is something to keep in mind.

Re: A Doom Renderer written in Rust

#46

Post by steveklabnik »

pjmlp wrote: post #26
cageface wrote: post #17

Earlier quoted context omitted.

How optimistic are you that the compilation speed can be significantly increased? Are there a lot of easy optimizations available or is this just the price paid for extra compile time safety? I'm not really a fan of Go but waiting for the compiler can be a pretty significant productivity killer on larger projects. Their fast compilation times are a pretty big selling point for what is (IMO) an otherwise underwhelming…

Rust compilation times can still be made faster. Generally I think many people complain too much for what takes a few seconds. C++ builds are measured in hours, usually require distributed build systems, clever use of forward declarations and cutting class private declarations into static code or PImpl classes to bring it down to something manageable.

While I agree with you, I'll also say that the difference between a second or two and instant is _huge_. The Ruby world has been talking about how to get unit tests runs down for the past few years for this reason. Sub-second test suite runs are _amazing_.

Re: A Doom Renderer written in Rust

#47

Post by lazyjones »

lobster_johnson wrote: post #16
melling wrote: post #5

Earlier quoted context omitted.

Turbo Pascal and Delphi had incredibly fast compilers. Why can't we make fast compilation a required feature today? We should never have to wait for the compiler/linker. http://prog21.dadgum.com/47.html

The Borland compilers were single-pass compilers; they did not go through an AST, but generated machine code directly from parser input. Also, the original Turbo Pascal compiler was written in assembly language. (Not sure about the later compiler versions used by BP and Delphi.) Also, the language was quite simple. With large, complex programs, the most time-consuming stage was in the linking of the final binary. If…

> If you want a similarly fast compiler today, look at Go.

There's also the amazing and much underrated Free Pascal: http://www.freepascal.org

Re: A Doom Renderer written in Rust

#48

Post by Bzomak »

bmh100 wrote: post #7

These are really valuable projects. It's not only a nostalgic project to hack on. It's also a learning tool for those interested in game programming, idiomatic Rust, and C-to-Rust conversion. Even building complex software from requirements. Thank you, Cristi Cobzarenco.

Indeed! Looking at projects like this and Piston are helping me get to grips with the language in a much more useful manner than working through the various guides/tutorials.

Re: A Doom Renderer written in Rust

#49

Post by pjmlp »

steveklabnik wrote: post #46
pjmlp wrote: post #26

Earlier quoted context omitted.

Rust compilation times can still be made faster. Generally I think many people complain too much for what takes a few seconds. C++ builds are measured in hours, usually require distributed build systems, clever use of forward declarations and cutting class private declarations into static code or PImpl classes to bring it down to something manageable.

While I agree with you, I'll also say that the difference between a second or two and instant is _huge_. The Ruby world has been talking about how to get unit tests runs down for the past few years for this reason. Sub-second test suite runs are _amazing_.

I am a huge sponsor of agile, but in the enterprise world I work on, strong type checking wins over unit tests.

It is a lost battle trying to make enterprise guys to write a single line of unit tests.

Re: A Doom Renderer written in Rust

#50

Post by shmerl »

bjz_ wrote: post #39
shmerl wrote: post #9

How does it interact with OpenGL? Using C bindings?

We have a syntax extension that uses kronos' xml registry ( https://www.opengl.org/registry/#specfiles ) to generate symbol a loader (somewhat like GLEW) at compile time. https://github.com/bjz/gl-rs

Thanks for the pointer!
Post reply on HN