mmstick

I recall some DICE slides about two years ago and a mentioning from a DICE employee that they are building some of their game dev tools in Rust. Naturally, EA would never approve of allowing DICE to develop a game in Rust if it meant it would make the game PC-exclusive.

It's entirely dishonest and ignorant to simply discredit and dismiss someone's point of view because you have it set in your mind to not believe a point of view that isn't your own. My history with Rust is proof alone that there is more to the story than you claim. I'm not the only one that has no difficulty with Rust either.

It is all a matter of mindset, and so if you think it is hard, then it will be hard. However, you must remember that like many things in life, learning is like a Chinese finger trap. The more you struggle and resist, the harder it seems. Rust is a Chinese finger trap. Until you change your point of view and use a different, simpler approach, you will have hard time.

http://mmstick.tk/posts/id/292

Type restrictions aren't really a problem, but in fact really helps out game development in the long run.

> Memory safety is not a problem in game development, they will just patch the bugs.

You must not have played any Bethesda titles. That said, there is much more to Rust than memory safety. That's just a side effect of the safe parallelism -- it's a minor story.

DICE is using it internally. The only reason why they aren't using it in games is because Rust won't compile on console platforms.

Thanks. I've never built a website before, but now I've built a website, and a web server + cms client at the same time. I've been thinking of open sourcing the code at some point in the future.

The website stores all the content in a database, uses handlebar templates to generate HTML pages, stores the generated HTML pages in a concurrent hash map compressed with the native Rust implementation of Zopfli, and only regenerates pages after a set amount of time -- all in pure Rust. I can serve an unrealistic amount of requests per second -- just bottlenecked by a consumer-grade network connection.

Japan's NicoVideo seems to agree. 550K lines of Erlang, and 20K lines of Rust.

You are basically stating that we should be doing both try/catch AND result/option at the same time, everywhere. That would get annoying fast.

Rust requires at compile-time that you handle each case.

Nothing wrong with pointing out that someone's logic is wrong. It is true that the only way to address these 'concerns' is to change Rust into something that it is not. Rust without closures, structures, traits, pattern matching, and algebraic data types would not be Rust, it would be C. We don't want C.

Odd that you find closures weird. I use them everywhere that I can because it allows you to make your library more modular and, at the same time, allows you to write unit tests for otherwise impossible functions to test without dependency injections and other convoluted external setups that won't pinpoint the cause of an error very well.

Case in point, in the Ion shell that I am working on, I have a shell expansion module within that takes a structure containing closures that are used to grab and expand array variables, string variables, tilde variables, and process expansions.

Because of this, the module can live as an entirely separate piece of software with no dependency on the specifics of Ion, and I can write reduced unit tests that extensively test every component. I could strip it out of Ion and use it with a completely different shell project. That shell would just have to provide the batteries (closures) that define what to do with certain tokens.

Using exceptions would be unprofessional. If someone were to use exceptions, then all of my carefully crafted error-handling routines would go up in flames because someone's library decided not to use an algebraic data type for conveying error messages across boundaries. It's bad enough that C libraries can suffer catastrophic failures bringing the entire stack down. I want a consistent error-handling strategy, and pattern matching is the best method of clearly displaying intents and possible downfalls.

Despite all the flashy tools that proponents of C and C++ claim that makes C++ as safe as Rust, it's not doing any good at stopping the exponentially-increasing amount of vulnerabilities and crashes that are being reported over the last few years.

Google and Microsoft are using it.

It's not really hard. It's incredibly easy, from my perspective. It only took me about a week to get a hang of it -- about the same amount of time that it took me to get the hang of Go. Yet the difficulty curve progressively becomes easier and easier until it's much easier to write and maintain software in Rust than Go or even Python. Now I can regularly slap out solutions to challenging problems that would be much harder in 'easier' languages.

I would be downright appalled if Rust were to start promoting exceptions. It's an anti-feature.

Web developers have zero issues with using Rust for web development though. The Rocket web framework is rather intuitive. I even built my website entirely in Rust with it.

http://mmstick.tk

Hinting is very much obsolete on modern systems. I haven't used hinting with my text in many, many years, and yet fonts are visually superior to a typical Windows PC with hinting enabled.

Actually, your distribution needs to learn to live with the world rather than isolating itself to a stagnant point in history. If it's going to ship Rust in the repository, it needs to ensure that it always ships the latest version. If it doesn't plan on doing that, it should ship rustup instead. Otherwise, there's very little point in shipping Rust as you'll limit yourself to only being able to compile older versions of software. Ain't nobody got time to manage multiple versions of the same project for the sake of system X and Y having different versions of the Rust compiler.

The Rust ecosystem is able to make leaps and bounds on a regular basis precisely because we aren't limiting ourselves to ancient versions of the Rust compiler because the system we use isn't technologically savvy enough to keep up with the times. Rust basically follows the Internet age of development, whereas point release distributions are stuck in a metaphorical floppy disk era (and often times still use mailing lists).

Rustup is a major tool for development because it allows us to keep our toolchains updated. It's used for obtaining nightly compilers, stable compilers, official documentation, rust source code for racer autocompletion, and various different types of targets, such as MUSL vs Glibc on Linux, or installing the Windows GNU toolchain on Linux for cross-compiling.

And there's literally zero reason to not follow the latest Rust compiler. Rust follows the semantic versioning rules, which dictates that all of the 1.x.x release are backwards compatible with 1.0.0. Upgrading the compiler will bring no breaking changes, but it will bring improved performance and features.

I've been writing Rust solutions for two years now, and I do not feel like I am in a 'constant fight' to get something to run. That only happened for the first two or so weeks as I was learning Rust.

I can easily slap out a 30-line program and have it compile and work on the first try with Rust, guaranteed. No competent Rust developer has issues writing solutions in Rust. Nobody but newcomers are 'arguing with the compiler'.

Nothing happens to object-oriented programming because it is entirely unrelated to multicore processors, except for the fact that object-oriented programming makes for terribly inefficient data structures that cannot handle threading very well.

If you've written software before, you would know that most of your codepaths require prior data to be processed, and thus having multiple cores won't make software any faster than before. Additionally, there is a cost to starting threads, so the benefit of making your software multi-threaded has to outweigh the cost of launching a thread, sending data to that thread, and getting results from that thread.

Pooling and channels are often used to mitigate the initial cost of creating threads, but it still remains that it takes time to send data to a thread and receive data from that thread, and there will always be that one main thread that needs to handle the majority of the logic and keep results in sync.

Basically, it would be easier to see powerful cores sitting adjacent to miniature parallel cores that are able to respond quickly to requests.

Lower wages doesn't necessarily mean cheaper products, especially once you take inflation into account. The cost of living has been increasing drastically, despite any efficiency gains. Wages have not been increasing to keep up with the pace. Seniors who are now retired are now effectively effed and are forced to go back to work to make ends meet. The young who are trying to get a fresh start aren't able to and most people in their 30s still live with their parents because a full time job isn't enough to afford the most basic apartment.

Companies are more willing to hire outside labor -- effectively slave labor, because they are able to pay foreign workers much less than domestic citizens. Companies are also more willing to replace human employees with robots, because it's cheaper than paying a human to do the same job. Companies will not help employees transition into new job positions. Fast food restaurants are beginning to replace all their workers with robots. The truck driving industry is about to replace all of it's drivers with robots. Walmart is replacing it's stockers and cashiers with robots. Pizza shops are even going for full autonomy with self-driving pizza trucks that automatically make pizza while delivering it. A huge percent of existing jobs today will soon be taken over by robots. You can definitely ensure that all the jobs that are considered entry level will no longer exist. How then, will the young get their foot in the door and become independent when they have no jobs?

That race to the bottom has merely displaced millions upon millions of people and abolished the middle class, in addition to destabilizing the world economy. Capitalism is entirely incapable of keeping up with the modern world. The only way forward is a basic income.

Rust and Cargo promotes a high degree of modularity and thus re-usability. While the image library is being hosted under the Piston project's GitHub profile, the image library has nothing to do with a game engine. Piston's image library is being used in Servo, for example. Rust has created an ideal open source ecosystem.

Everything that can be GPU-accelerated should be GPU-accelerated. The GPU is far more energy efficient, and every bit of offload onto the GPU leads to a decrease in CPU consumption. Terminals can be particularly CPU-heavy when running a chatty program.

You mean this?

https://github.com/mmstick/parallel

I've been writing software exclusively in Rust since the 1.0 release. I have no issues with the borrow checker, personally. I haven't seen the borrow checker mentioned as an issue on the Rust subreddit, which I frequent.

The only people who have issues are people who've used Rust for less than a week and still do not understand the basic rules of the borrow checker. I've explained it many times to people already. Once you know the rules, it's easy peasy, and you'll never have another complaint from the borrow checker ever again.

The only improvements that I could see for Rust is landing non-lexical borrows, macros 2.0, and faster compile times, albeit compile times are largely fixed now. A 100K combined LoC project can easily compile a release build using 1 core in 3 minutes or less.

Cargo isn't competing against nor replacing distribution package managers. Cargo is a build tool, not a package manager. You're free to package Rust software the same way you do non-Rust software for specific distributions. They are entirely different unrelated things with no overlap. Cargo solves a lot of problems that we've been facing for a long time. We have the Internet now, so let's use it to speed up development.

No one's being driven away. Only people who had no intention on trying Rust are complaining about it.

I was competing against some C and C++ software developers in Advent of Code with efficient solutions, and my Rust solutions came out faster each time. Might want to check your facts.

Go's not been receiving any piles of money from Google. Compare Go's API documentation to Rust's API documentation. Where's the `cargo` and `rustup` equivalent for Go? Compare the number of Go packages to the number of Rust packages. Seems Go's not doing so great despite being stable for much longer.

> I just don't see Mozilla having enough resources to keep-up the momentum long-term.

Did you forget about Samsung? Mozilla and Samsung aren't the only two companies backing Rust.