The roguelike games also have a low barrier for people who want to write their own, as there are freely available graphical tiles, libraries such as Doryen to do the heavy lifting, and plenty of tutorials covering most programming languages. See https://roguebasin.com/index.p... for some tutorials.

Most existing games are open-source, so if creating a new game doesn't appeal, you can download your favourite and start changing it to be more to your liking.

by far.

I think that is pushing it.

If I'm counting correctly there have only been 9 crewed flights of falcon 9/dragon. 1 spacex demo, 6 operational flghts for NASA and 2 private flights.

By contrast there were 135 crewed space shuttle flights, 2 of which resulted in loss of crew.

One accident would essentially take spacex's record on crewed flights from best to worst.

Now the total number of falcon 9 launches is much higher, but those haven't been without incident, one blew up on the pad prior to launch, and one broke up in flight. Hopefully nothing simlar will happen on a crewed launch and if it does hopefully the launch escape system will do it it's job.

OTOH much of the point of a video game is to let you escape the drudgery of real-life. People will tolerate an hours drive in real life, not so much in a video game. You can put in fast uncongested highways and let the player drive like a maniac but i'm still not convinced you can go much bigger than GTA Vs map without getting really annoying.

The tricky bit with trackers was always how to get the signal out at a minimal cost, both in financial and power terms.

What apple did with the airtag was leverage their massive installed base of phones to solve that problem.

IMO there are multiple different categories of UB in C/C++.

Some UB just reprepresents pig-headedness on the part of compiler writers and standards organisations. The optimisation benefits are massively outweiged by the fact that they make even the simplest operations (like addition) into potential footguns.

Some UB is arguable, stuff like the aliasing rules. On the one hand i'm not convinced the optimisation opertunities justify the extra mental load, on the other hand they relate to things (like pointer typecasts) that should be used sparingly anyway.

These first two categories could be got rid of quite easily if there was the will to do so. Indeed in gcc there are actually compiler flags to turn many of them into defined behaviour for those who can be bothered to actually RTFM.

But there is a third category of UB. UB that represents fundamental consequences of the language and library design and of low level programming in general. This last category includes stuff like buffer overflows (and sometimes underflows), stale pointer de-references, double frees.

I don't think this third category can ever be done away with completely in low level programming. The best you can hope for is to do what rust tries to do and compartmentalize it but I can't see how you can do even that without language and library changes radical enough that you may as well call it a new language.

A particular problem is the combination of sharing and mutability. Lets take for example I have a type that represents a string, it has a pointer to the string data, a length and a capacity. I read the pointer and start a loop of read character, process character, increment pointer until I reach the end of the string.

However, while the code working through the string some other peice of code comes along, maybe another thread, maybe an interrupt handler, maybe a callback function. This other piece of code appends a character to the string, triggering reallocation of the string. Suddenly the first piece of code has a stale pointer.

Rust gets around this by forbidding shared mutability in safe code except under very specific circumstances but I really don't see how you can solve this problem for an existing language and library ecosystem.

Do a benchmark on a production workload on a real application and we'll talk. Pretending like this project with 360 github stars is somehow authoritative for every language is silly.

Doesn't address the issue of how the concurrency was set up for these synthetic benchmarks, which again bear very little resemblance to a real web application task. Javascript has a different concurrency model and again, unrealistic compared to how a real web browser would run this.

The other thing about this particular set of benchmarks is that it's actually selecting for languages with good parallel threading support and concurrency in general, which has been a weak point of Ruby until recently. I don't know what threading approach they used but there are newer approaches such as Fibers instead of Threads, or the Ractor pattern. They also left elixir and erlang off the list. Elixir is a language with Ruby-like semantics but the concurrency of erlang. I'd be interested to see how it compares to JS.

These synthetic benchmarks that timed out probably aren't configured properly. For the ones that did run, ruby got decent performance considering they are using truffleruby which requires extensive tuning to take advantage of the JIT, and it likely isn't set up to do that, tweaking gc, and showing high memory usage. On a cursory look at their implementation https://github.com/hanabi1224/... it could certainly be improved to use hashes instead of recursively creating objects. The reality is that you aren't going to be computationally bound for common web application tasks. Synthetic benchmarks really just show that ruby is perfectly fine. I'm sure a knowledgeable ruby core contributor could show some significant performance gains in the ruby results here and probably the same could be said for python and other similar languages.

Ruby is a great replacement for Perl and PHP and adds many modern features for scalability. If you are productive in Perl and PHP and want to upgrade to a more modern stack, Ruby is a good choice alongside Python/Django, or Elixir/Phoenix

Nowadays I use asdf but you can solve this easily with rvm or rbenv. Which should probably be part of the standard ruby package management distribution, just as nvm is needed to use nodejs properly. If you try to run with a system library things are hard. Same thing with using the system python without virtualenv or anaconda or whatever.

Tell that to multiple large companies such as Shopify.

Concerns about rails performance are vastly overstated and mostly very outdated.