The problem with making a custom web server is that you take responsibility for re-solving all the non-obvious security vulnerabilities. I always try to delegate as much network-facing code as possible to a mature implementation someone else wrote for that reason.

Here's how I'd implement it, based on stuff I've done before:

1. Start with either Actix Web or Axum for the server itself.
2. Use std::thread to bring up mpv in a separate thread.
3. Use an async-capable channel implementation like flume as a bridge between the async and sync worlds.
4. If the async side needs to wait on the sync side, include the sending side of a tokio::sync::oneshot in the "job order" object your async code drops into the channel and then have the async task await the receiving side. That way, you can have the async task block on the some kind of completion signal from the sync thread without blocking the thread(s) underlying the task executor.

I'm sure other people have a more teachable way of learning these things but I'm just one of those nerdy guys who's been reading technical materials for pleasure since he was in elementary school and gathered the core "this will tell you how the system is designed so you know what to ask about" knowledge along the way.

For example, I just ran across The TTY Demystified, Things Every Hacker Once Knew, The Art of UNIX Programming, and A Digital Media Primer for Geeks on my own. (Sort of the more general version of "It showed up in the YouTube sidebar one day" or "I landed on it while wandering Wikipedia for fun".)

Beyond that, it's mostly "exposing yourself to things the professionals experience", like running a Linux distro like Archlinux or Gentoo Linux which expect you to tinker under the hood and give you documentation to do so, maybe working through LinuxFromScratch to get exposed to how the pieces of Linux fit together, reading periodicals like LWN (articles become un-paywalled after a week, if you're tight on money or need time to convince yourself it's worthwhile), and watching conference talks on YouTube like code::dive conference 2014 - Scott Meyers: Cpu Caches and Why You Care or "NTFS really isn't that bad" - Robert Collins (LCA 2020).

(I switched to Linux permanently while I was still in high school, several years before YouTube even existed, and I'm only getting back into Windows now that I'm buying used books to start learning hobby-coding for MS-DOS beyond QBasic 1.1, Windows 3.1, Windows 95 beyond Visual Basic 6, and classic Mac OS, so I haven't really picked up much deep knowledge for Windows.)

The best I can suggest for directed learning is to read up on how the relevant system (eg. the terminal, UNIX I/O) works until you start to get a sense for which are the right questions to ask.

For an interactive terminal program with the characteristics you want, you need to do two things:

1. Flush stdin before using it, similar to what things like sudo do. (Basically, once your program is all started up and ready to go, read everything that's already in there and throw it away.)
2. Disable the terminal's default echoing behaviour which traces back to when the terminal was a completely separate device possibly half-way around the world from the machine you were logged into on the other side of a slow modem and you didn't want the latency from waiting for the machine on the far end to handle echo. (See this if you want more context.)

Windows and POSIX (Linux, the BSDs, macOS, and basically everything else of note) have different APIs for it. On the Linux side, you want something that wraps the curses library, which can put your terminal in "raw mode" or some other configuration that operates unbuffered and lacking terminal-side echo. On the windows side, it can either be done by wrapping the Windows APIs directly or by using the pdcurses library.

Something like termwiz should do for both... though you'll probably need to reimplement print_typewriter but that should be trivial from what I see of its README.

I'm using the web UI, so I'm assuming whatever broad-spectrum Markdown rendering library it uses has smart quote rendering turned on.

Ahh, yeah. In the beginning, Rust was built around the idea that individual files and invoking rustc are internal details, only relevant for integration into some other build system like Bazel, and that "normal" Rust projects need to be inside a Cargo project structure.

There is in-development work to have official support for something along the lines of rust-script, but it's still just that... in development. If you want to keep an eye on it, here is the tracking issue.

That's not how it's supposed to be.

but for example Vec::new() doesn’t highlight anything at all.

If I do Vec::new(foo, bar), I get expected 0 arguments, found 2 (rust-analyzer E0107).

but things like passing too many arguments into the println macro doesn’t throw an error.

I don't get that either, but I'm still running with the Vim configuration I setup on my previous PC from 2011, where I turned off checks that require calling cargo check or cargo clippy in the background. From what I remember, a properly functioning default rust-analyzer config should pick up and display anything cargo check will catch and you can switch it to cargo clippy for even stricter results.

Or how shown in this example, it did not autocomplete the clone method, while also just accepting .clo; at the end of a String (it also didn’t autocomplete “String”).

I get clone(), clone_into(), and clone_from() as proposed completions for .clo on my as-you-type completions for foo where let foo = String::new(); and it proposed a whole bunch of things, with String at the top when I typed Stri. (eg. the stringify! macro, OsString, mixed in with various results from other crates in the project like serde)

Fair. That would have been more constructive... I think I didn't do that because it still would have felt like encouraging off-topicness.

Signal to noise ratio.

Aside from possibly making them feel better, it doesn't benefit anyone for them to drop into a topic about thing X and say nothing but "I use thing Y. I don't like thing X." and it wastes other people's time either scrolling past it or clearing out their RSS reader, depending on how they follow things.

...and I could just as easily disparage those frameworks and give concrete reasons, but I don't. If you don't have something constructive to say, please be courteous and say nothing.

Depending on your preferences, there's also Nom if you prefer parser combinators, or lalrpop or grmtools if you prefer LR(1) parsing.

Since reading Which Parsing Approach by Laurence Tratt (author of grmtools), my plan for my own parsing projects has been to use an LR(1) parser generator for the stronger compile-time guarantees.

Lemmy hangs whenever I try to post my response (I suspect it doesn't like the length), so here's a link to it on Github Gist:

https://gist.github.com/ssokolow/16c9311573eabc7343ff7ff2cc3513b3

It begins as follows and I've tried to hyperlink my sources as often as possible:

I'll try to fill in some of the knowledge gaps and respond to some of your answers from a more user-centric perspective.

He recently did one about how he and his team set up a fake bitcoin site that would direct scammers to a fake support hotline when they try to withdraw the fake bitcoin, where they'd get stuck running in circles in a voice mail menu maze chasing the illusory bitcoin payout.

I Trapped 200 Scammers in an Impossible Maze

As one commenter put it, "I love how Kit has evolved over the years to find out the best way of making scammers go crazy is to treat them basically the same way Comcast treats their customers."