So it's great that with anti-NMDA there is an actual singular test to determine this, but given it's so rare and little-known, getting to that point is very much not given :-(.

E.g. Multiple Sclerosis can very well fit what you're describing, too. Commonly, there's a flare-up (we commonly use the term "attack" funilly enough)of some neurological symptoms (numb limbs, tingliness, diziness, vision issues are very common) that can last a few days/weeks and then mostly or completely subsides (until the next time).

Absolutely not suggesting that's what it was, just that it is what it could be too (or many other things — auto-immune diseases in particular can be really broad and nasty).

Sushi, I'm so glad you're doing better. Some of what you said (including just writing about it for awareness and sharing) resonates with my MS experience. I'm sorry you've experienced this and I hope things will keep looking up! <3

The Markdown one seems interesting too.

I'll probably stick with this for stuff where there's some expectation of drive-by contributions (the tutorial has seen a bunch, it was one of the motivations behind this) because requiring additional tooling can often be a bar that's too high.

Agreed on the general literate programming note. I'm not sure I'll ever pick it up for something that doesn't have an obvious accompanying article/book to come with it, but if I ever write another tutorial or something, I'll definitely use it from the beginning.

But knowing what's out there is definitely important (and AsciiDoctor is extensible so these things could probably be added as plugins).

http://tomassedovic.github.io/roguelike-tutorial/

https://github.com/tomassedovic/roguelike-tutorial

There are no official builds you can download since this is something you're supposed to read and follow along, building your own game in the process.

I have made my own "proper" roguelike (moved away from libtocd, but kept Rust) but that was unrelated to the post.

(I'm the author of the article, but not the OP)

If this is the reaction to the theme in the Rust tutorial that the original post talks about, that's because it's basically a port of the classic Python+libtcod one. It implements the same game, but walks the reader through doing it in Rust.

I (not OP but the author of the article and the Rust tut) wanted to use the same game & structure so folks can compare and contrast. A lot of folks are coming from Python or are familiar with libtcod. Plus it's trained generations of RL devs for better or worse.

If you do want to see roguelike creators experimenting, check out the annual Seven Day Roguelike Challenge[1]. Lots of absolutely amazing stuff keeps coming out of that, including most of my favourites.

[1]: http://www.roguebasin.com/index.php?title=Seven_Day_Roguelik...

In addition to it being a pure Rust library (which does make a difference when you get started, but also when you try to distribute your game) it compiles to WebAssembly as well meaning you can use the same code to produce a game that runs on the desktop and the web. And the tutorial covers much more ground as well, including ECS for those interested.

And finally, both the tutorial and tcod-rs are barely maintained anymore. I try to address questions/fix serious issues from time to time, but the chances of this seeing any significant developments in the future are very slim. The RLTK stuff is actively maintained and developed.

(I'm not the OP, but I did write the linked post, the tutorial -- which is based on the classic Python+libtcod one as well as started tcod-rs)

If you factor in the real world, the number shrinks as you get to things like performance, cross-platform support, ease of packaging and distribution.

But still, Nu could plausibly have been written in Assembly, C, C++, D, Go, Nim, Zig, Haskell and so on.

You would have lost some of Rust's strengths and weaknesses and imported another set (regarding the language, tooling, performance, ease of debugging and so on).

I took the comment to mean that as far as they (all people intimately familiar with the language, tooling and ecosystem) are concerned, this would be a trade-off that would be negative enough to not begin or finish the project in the first place.

I don't know what plans and requirements the Nu authors had. But for my own game (a roguelike written in Rust) the requirements on the performance, distribution, stability, ease of development and dependency management meant that Rust was (at the time) pretty much the only viable choice for me.

Could someone have written it in C? Sure. Could I have written it in C? Likely, yes. Would I have ever finish the game in C? Almost certainly no. For various reasons none of the other languages would have done in those circumstances, not really.

Human language is an imperfect method for transferring information and sometimes one trades off brevity for nuance.

There are deterministic interpretations that are very much on the table.

The Everett's Many Worlds[1] is fully deterministic (and depending on your view, the simplest one too): the universe is a quantum wave function evolving according to the Shrödinger's equation. That's it.

A lot (if not all) of the hidden variables theories are also deterministic. The apparent non-determinism stems from the aforementioned variables that we don't/can't see.

I keep hearing more and more about the Pilot wave theory[2] recently. And that's a hidden-variables deterministic interpretation.

[1]: https://en.wikipedia.org/wiki/Many-worlds_interpretation

[2]: https://en.wikipedia.org/wiki/Pilot_wave_theory

It also helped me understand something about the font sizes that always puzzled me (but never enough to actually look it up).

All of the fonts there have the size of 16, but some are clearly bigger than others. Compare e.g. Inconsolata and Meslo:

http://app.programmingfonts.org/#inconsolata http://app.programmingfonts.org/#meslo

Having them side by side, you can see that they contain the same vertical amount of space. Inconsolata's glyphs are smaller, but they're still in the box of the same height.

It does seem that the "font size" only refers to the height, though. The width is clearly variable.

To anyone who actually understands this properly: is the above correct or is that just an artefact of how the website renders the text?

These things are pretty complex.

This is a nitpick, but Red Hat did not get bought by IBM. What happened was IBM announcing the intention to buy Red Hat.

It's maybe a subtle, but possibly important distinction. Red Hat is still its own independent entity until the deal goes through (which means IIRC passing the board's approval, SEC and likely other stuff). This is expected to happen in late 2019 I believe, but it might still fall through.

This doesn't absolutely dispel any possibility of IBM's influence, but it should be very low/zero until the merger actually goes through. But I also don't know how all this works.

There are many more or less serious potential explanations: not enough people care, it wasn't (or still isn't) financially feasible, the people able to develop AAA engines are actively against sharing source or ideas, there's an engine development cartel actively pushing against it to keep their revenue.

Or it might just be a social or historical accident -- we may just have been extremely lucky with Linux and projects on that scale will never come again.

Or maybe everyone thought it would be a great idea but they also thought it would never work and so no one seriously ever started an open source engine. Maybe Godot will be a true AAA engine that will surpass them all in a few years.

I don't know.

But you've mentioned it yourself, so you presumably don't see that as a contradiction.

What do you think makes the complexity of Linux achievable with FOSS while the comparable complexity of a AAA engine not?

It was in a reference to another law, already passed years ago and only referenced by its number. So you had to look that up and any references it had, too.

And at the end of it, you're still left with a deep unease that you've probably missed a lot of data and meaning because these things don't seem to be written in a way non-layers can understand.

https://jvns.ca/teach-tech-with-cartoons/#tools-that-make-it...

Presumably, she uses the same to do the slides. Here she talks some more about her tools:

https://usesthis.com/interviews/julia.evans/

https://www.rollingstone.com/music/music-news/paul-mccartney...

(he's released 2 new singles in June from his upcoming solo album)

This required only a handful of changes across the codebase (mostly handling external resources such as the filesystem and the random generator) and then implementing a bit of JavaScript that took the drawcalls from the WASM core and rendered them on the canvas. And vice-versa, a bit of JS that passed the browser input into the WASM game.

Since the original game had no concept of a DOM, it didn't matter to it. I think WASM can be huge for browser games.

But like Steve said, you can call any JavaScript function and manipulate the DOM that way. At least for Rust, there's also a library that does this for you. So you can have Rust code that uses a DOM API and the WASM <-> JS bridge is handled for you:

https://github.com/koute/stdweb