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

61–69 of 69 posts

Re: A Doom Renderer written in Rust

#61

Post by spullara »

eropple wrote: post #22
spullara wrote: post #21

Earlier quoted context omitted.

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.

FWIW, I don't find it to be a big issue in Scala anymore with SBT's incremental compilation.

Depends on how many people are developing on the code base. If every morning is a full build with a few spread throughout the day for integration it is pretty awful. Additionally, I think submit queues are the way to go for committing code to master and if that takes an hour before you know your change is good I'm pretty unhappy. As far as incremental compiles go, just developing in IDEA does a pretty good job.

Re: A Doom Renderer written in Rust

#62

Post by pjmlp »

steveklabnik wrote: post #56
pjmlp wrote: post #49

Earlier quoted context omitted.

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.

> Static typing vs. unit tests is a false dichotomy.

Not at the enterprise.

In what is now almost 30 years of dealing with computer systems. I only had the luck to work at one single company that took unit tests seriously.

All the other companies, the guys just write tests if a manager imposes them (usually only if the customer makes it a condition of payment), or they are somehow related to their performance evaluation.

Otherwise, the best you can get are integration tests at around one month before delivery date.

Ah, and agile in the enterprise is a synonym for a 3 week long mini-waterfall project.

Re: A Doom Renderer written in Rust

#63

Post by comex »

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.

Not for incremental compilation when a single file changed, without optimization, it's not - depending on the type of change, of course, and how heavy the C++ code in question is, and I guess on whether you're using a broken IDE/build system (my standard is the command line, using make for small projects and ninja for larger ones). And incremental compilation can scale up to much larger projects without increasing the time much, whereas in Rust that would require splitting up into crates and even then would frequently require a full rebuild due to the coarse dependency tracking of "anything in this crate changed -> rebuild all dependents".

That said, I expect incremental compilation built into rustc to greatly improve the situation - if done right, it should easily beat C++, although I don't know the details of the plan - so I'm happy someone is working on it. (In the past I wanted to work on it myself, but I was in a big generally unproductive slump..)

Re: A Doom Renderer written in Rust

#64

Post by cristicbz »

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.

You're welcome! :D

Re: A Doom Renderer written in Rust

#66

Post by yen223 »

jnbiche wrote: post #57
temuze wrote: post #38

Holy 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…

One of the huge wins of rust is that the devs put a lot of effort into its basic infrastructure. Testing, documenting, and benchmarking are almost too easy.

Re: A Doom Renderer written in Rust

#68

Post by Alupis »

pcwalton wrote: post #32
Alupis wrote: post #30

Earlier quoted context omitted.

really doesn't matter how long the compiler takes, so long as the result is fast.

That's not true; for quick turnaround it's important to be able to get results out of the compiler quickly.

In what scenario does executable correctness and performance take a backseat to compiler runtime? Seems backwards to me.

Re: A Doom Renderer written in Rust

#69

Post by spullara »

Alupis wrote: post #68
pcwalton wrote: post #32

Earlier quoted context omitted.

That's not true; for quick turnaround it's important to be able to get results out of the compiler quickly.

In what scenario does executable correctness and performance take a backseat to compiler runtime? Seems backwards to me.

There is a reason that every C/C++ compiler has various optimization options. Developers like the compiler to respond quickly to changes and later they'd like the highest performing code at the cost of compile speed.
Post reply on HN