How does it interact with OpenGL? Using C bindings?
It uses gl-rs. Which auto generates a rust wrapper around the C bindings using a compiler plugin. https://github.com/bjz/gl-rs
Thanks for the pointer!
A Doom Renderer written in Rust
51–60 of 69 posts
Re: A Doom Renderer written in Rust
#52[deleted]
Re: A Doom Renderer written in Rust
#53Earlier 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…
> 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? The vast majority of compile time for optimized builds (80%-90%) is spent in code generation and optimization in LLVM. For unoptimized builds, most of the compile time is spent in the typechecker doing type unifications for me…
> Go 6g/8g also doesn't do much optimization by comparison to GCC/LLVM. (Rust uses LLVM.)
You should compare with gccgo, though.
Re: A Doom Renderer written in Rust
#54This 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.
Another thing which I don't see often mentioned, but which alleviate most of the compile-time waiting-pain for me (and I'm actually a dynamic language guy) is the fact that since optimizations are usually what takes longest, the compiler is quite quick about telling me about errors.
But maybe my projects just haven't been big enough :)
Re: A Doom Renderer written in Rust
#55This 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 is in the top 3 issues with Scala as well. The amount of drag it causes in a project just isn't worth it.
More than speed it's the ridiculous ram requirements that made me cringe while learning Scala. sbt itself ate 2G of ram on my machine.
Re: A Doom Renderer written in Rust
#56Earlier quoted context omitted.
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.
Ruby has strong type checking. ;)
Static typing vs. unit tests is a false dichotomy.
Re: A Doom Renderer written in Rust
#57Holy crap, this is f *ing awesome. Rust has made systems programming exciting for me again. Seeing well written Rust code like this (also, the repos on Github https://github.com/trending?l=rust ) has been a really good learning experience. As a Rust newbie, I only wish there were better examples of testing in public Rust repos.
>As a Rust newbie, I only wish there were better examples of testing in public Rust repos.
Testing is incredibly easy. The reason you may have missed the testing is that tests are often in the same file as tested code. Go back and check, it's very common in Rust to test your code. And it's as simple as writing:
#[test]
Then you test your code by running the normal rustc command but with the `--test` flag. A test runner with very attractive output is built into the compiler.
Rust unit testing is just about the easiest testing I've ever used, right up there with golang. I love that it's built into the language.
Also, the `cargo` package manager makes everything -- including unit testing -- incredibly convenient. And I say this as someone who cringes every time a language comes out with yet another package manager or build tool (ahem, .js). But in the case of rust's cargo, it's incredibly worth it to use a new package manager, and so much better than a Makefile (although it's quite easy to integrate makesfiles with cargo).
Re: A Doom Renderer written in Rust
#58Earlier quoted context omitted.
really doesn't matter how long the compiler takes, so long as the result is fast.
I want two types of results: when developing, I want fast turnaround and most of the time don’t care about runtime performance; when deploying, I don’t care much about how long it takes to compile, but I want runtime performance to be optimised.
Even if it's a simple idea, IIRC Fabien Bellard suggested to use very simple compilers such as tcc for prototyping and gcc for final built. A few years ago there was also an intermediate step using clang for error messages (and also portability).
Re: A Doom Renderer written in Rust
#59This 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.
Oh, Gods, 3-4 full seconds, perish the thought. That's really not that long a time at all.
Re: A Doom Renderer written in Rust
#60Holy crap, this is f *ing awesome. Rust has made systems programming exciting for me again. Seeing well written Rust code like this (also, the repos on Github https://github.com/trending?l=rust ) has been a really good learning experience. As a Rust newbie, I only wish there were better examples of testing in public Rust repos.
>As a Rust newbie, I only wish there were better examples of testing in public Rust repos. Testing is incredibly easy. The reason you may have missed the testing is that tests are often in the same file as tested code. Go back and check, it's very common in Rust to test your code. And it's as simple as writing: #[test] on the line before your unit test function, and then using some of the unit test macros in std like…
The guide has a whole section on this: http://doc.rust-lang.org/guide.html#testing
And we even have a full guide on testing, though I haven't checked it lately: http://doc.rust-lang.org/guide-testing.html (it's on the todo list)