Earlier quoted context omitted.
My impression is that this is due to their non-robust programming style. They do not add fallback behavior when e.g. receiving a null object. It would still be a bug, but could be a log entry instead of crash.
Arbitrary recovery to null pointers isn't a good way to do robust programming. I recommend doing the exact opposite actually. https://en.wikipedia.org/wiki/Crash-only_software https://medium.com/@vamsimokari/erlang-let-it-crash-philosop...
Leaving Rust gamedev after 3 years
951–960 of 996 posts
Re: Leaving Rust gamedev after 3 years
#952Earlier quoted context omitted.
> Parts of the Rust community are toxic indeed, but I've been around long enough to recognize the same pattern in communities of other hot programming languages or frameworks in their up-and-coming phase. I would say that in general, this type of attitude permeates a lot of software engineering, and even engineering and science as a whole. When I speak with people in other fields, particularly more creative ones, the…
Conversations that people have in science and engineering are more analytical and pessimistic, where they try to clarify and set the boundaries. This is the opposite of creative and optimistic conversation, where you break boundaries between things to create something new. The attitude to be analytical in conversations comes from the fact, that software engineers usually do creative part of their work alone, and use…
Re: Leaving Rust gamedev after 3 years
#953Earlier quoted context omitted.
A crash of an actor in BEAM is incomparable to a crash of a video game.
Is it? Is there no reasonable case where you have a subsystem in a game crash, then restart itself? Unless I'm mistaken, I've experienced this myself in video games more than once. Anything beats a full crash with a pointless error message.
Re: Leaving Rust gamedev after 3 years
#954As a game developer for about two decades, I've never considered Rust to be a good programming language choice. My priorities are reasonable performances and the fastest iteration time possible. Gameplay code should be flexible, we have tons and tons of edge cases _by design_ because this is the best way to create interesting games. Compilation time is very important, but also a flexible enough programming structure,…
> It is a different story for game engines, renderers, physics, audio, asset loaders etc. those are much closer to system programming but this is also not where we usually spend the most time, as a professional you're supposed to either use off-the-shelf engines or already made frameworks and libraries. But this is where industry interest (the little there is) lies for Rust, is it not? This is what the AAA studios th…
I'm surprised no one has made such a language that is designed from the ground up to be used as such for rust. Nim/coffeescript come to mind, but they target non-rust languages. Lua would be close enough if it weren't so alien to everything people like about rust.
Re: Leaving Rust gamedev after 3 years
#955Earlier quoted context omitted.
The current popularity of the async stuff has its roots in the classic "c10k" problem. ( https://en.wikipedia.org/wiki/C10k_problem ) A perception among some that threads are expensive, especially when "wasted" on blocking I/O. And that using them in that domain "won't scale." Putting aside that not all of use are building web applications (heterodox here in HN, I know)... Most people in the real world with real appl…
> If you ever pull up a debugger and step through an async Rust/tokio codebase, you'll get a good sense for what the overhead here we're talking about is. So I didn't quite do that, but the overhead was interesting to me anyway, and as I was unable to find existing benchmarks (surely they exist?), I instructed computer to create one for me: https://github.com/eras/RustTokioBenchmark On this wee laptop the numbers are…
Re: Leaving Rust gamedev after 3 years
#956Earlier quoted context omitted.
C++17/20 are light-years beyond C++11 in terms of ergonomics and usability. Metaprogramming in C++11 is unrecognizable from C++20 things have improved so much. I hated C++ before C++11 but now C++11 feels quite legacy compared to even C++17. The ability to write almost anything, like a logging library, without C macros is a huge improvement for maintainability and robustness. Most of the features in modern C++ are de…
Heh, mentioning metaprogramming and logging is not exactly how you convince anybody of superior ergonomics and usability.
Re: Leaving Rust gamedev after 3 years
#957Earlier quoted context omitted.
> If you ever pull up a debugger and step through an async Rust/tokio codebase, you'll get a good sense for what the overhead here we're talking about is. So I didn't quite do that, but the overhead was interesting to me anyway, and as I was unable to find existing benchmarks (surely they exist?), I instructed computer to create one for me: https://github.com/eras/RustTokioBenchmark On this wee laptop the numbers are…
I'd want to see perf stats on branch prediction misses and L1 cache evictions alongside that though. CPU cycles on their own aren't enough.
Here's the results for 100000 rounds for taskset 1 perf record -F10000 -e branch-misses -e cache-misses -e cache-references target/release/RustTokioBenchmark (a)sync; perf report --stat though:
async
Task 2 min roundtrip time: 532
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0,033 MB perf.data (117 samples) ]
...
branch-misses stats:
SAMPLE events: 54
cache-misses stats:
SAMPLE events: 27
cache-references stats:
SAMPLE events: 36
sync Thread 2 min roundtrip time: 7096
[ perf record: Woken up 5584 times to write data ]
[ perf record: Captured and wrote 0,367 MB perf.data (7418 samples) ]
...
branch-misses stats:
SAMPLE events: 6577
cache-misses stats:
SAMPLE events: 159
cache-references stats:
SAMPLE events: 682Re: Leaving Rust gamedev after 3 years
#958Earlier quoted context omitted.
It’s much more than that, even now they are continuously opening job postings with a focus on re-writing the 365 platform from C# to Rust.
It’s a bad habit to read too much into a single job posting. (oh, I remember now, it’s the account traumatized by odata)
As far as I’m aware I was never traumatised by OData. It’s true that I may have ranted about the sorry state of the public packages available outside of C# or Java. Not unwarranted criticism I think, but I wrote our own internal adaptation which now powers basically all our API clients for Typescript as a single shared no-dependency library.
But you seem to think you know me? Have we met?
Re: Leaving Rust gamedev after 3 years
#959Earlier quoted context omitted.
> incendiary responses to rust criticism can be I've not experienced this. Do you have examples of the rust community flaming someone for having negative opinions about the language?
Not parent, but take a look at these: https://news.ycombinator.com/item?id=32117148 https://news.ycombinator.com/item?id=39641552 These threads are absolutely painful to read. The Rust community/leadership would not do anything about it because Rust thrives on such "devotion".
Re: Leaving Rust gamedev after 3 years
#960Earlier quoted context omitted.
Maybe I should ask: why should someone interested about Lisp today have to hear stories about some Erik Naggum who posted to a Usenet newsgroup, and died 15 years ago? Let's assume that the newsgroup is important. Legendary Lisp hacker Alan Bawden posted there just last week or so. Nobody ever mentions him.
Every other one I've met in my life was nearly as unpleasant. Fewer death threats but they clearly all thought they had 200 more IQ points than you because they could write a macro. Thus the term "Lisp weenie". In this case I think people should learn from history and that specific examples are the best way to do that. It's, like, effective pedagogy or whatever. Supposedly Clojure people are nice though.
All too often you get ignorant remarks, jokes about parentheses or "contents of address register", or outright ridicule.
If you say anything frank at that point, chances are good you might come off as an asshole.
Just smile, nod your head, change the subject, and never return to it.