On a serious note, I've never actually understood where the term "hung" comes from in computing. Why is the process "hung" and not simply "stalled" or something else.
Hung is used like that outside computing. For example in the terms "hung jury" and "hung parliament". I have no idea how this word became common in computing though.
To your second question, WebAssembly shouldn't be affecting your day-to-day standard frontend development, unless you're developing very performant applications like games, simulations, etc.
For resources, MDN has a great introduction. Pretty up-to-date too. [1].
On GitHub, it seems like the javascript sources behind your pages is throwing their syntax highlighting off. Seems like when you embed HTML it hiccups. Any idea how one would fix this?
Oh, hah, it's getting bit by lone single quotes, (AKA apostrophes). I think it's something GitHub would have to fix, although perhaps a .jsx extension would help.
Using cloc against the Go source code, I found that it has 934025 loc with 3080 files. This averages to about 300 loc per file. There are 149688 lines of comments, which averages to about 50 per file.
I don't see how it's useful then. Maybe someone can give me a good use case?
redis is already very bare-bones and dead simple to set up and maintain, what more does one want? Wouldn't adding more logic into a redis-like environment be a little cumbersome from an architecture perspective?
Could be used for proxying redis connections, be it for clustering or I don't know, add sophisticated access control or something.
You could expose a memcached cluster as a redis server using this. (Not sure why would you want to do that.. Maybe if you have an existing memcached cluster and have redis client code?)
Or you could go crazy and implement the entire set of redis commands on top of sqlite and call it a "strongly persistent redis" or something like that.
It's just a nice building block, I'm sure people would find ways to abuse it :)
This is not for recreating Redis, but for custom server implementations such as the Tile38 project, proxying services, and microservices that might need to use the RESP protocol.
I'm not sure, either. By the time you've implemented all the actual Redis functions, there's no telling whether the server will be more or less performant than Redis itself. (Most likely less, since Redis is written in optimized C.)
Of course the existing benchmark shows that the example Go implementation is faster. For one, the Go implementation provided avoids a lot of functionality that the Redis server implements, such as TTL checking.
The use case would be implementing the redis protocol for client server communication in your own software. There is a specification for using the redis protocol [1]. The fact that redis is widely used and there are a number of client libraries in many languages may make it an attractive option compared to creating your own protocol from scratch.
I believe disque, the distributed message broker [2] uses the redis protocol for client server communication.
You have a more complicated data storage, or an established one that you don't wanna change, or a mandate from on high that all data must be put in X due to auditing or whatever - and a program that wants to talk to Redis.
Seeing Carmack's thoughts on programming always reminds me that I have such a long way to go. When he was my age, he had already created DOOM and DOOM 2 (along with the wtf? r_sqrt trick).
Fun story: both ID and Epic started out making 2D games. When Tim Sweeny saw Quake for the first time, he literally gave up on gamedev because he thought he wouldn't be able to keep up with game tech. But, shortly afterwards a friend of Tim wrote a Quake-like 3D renderer as a fun project. Tim figured if that guy could do it, he could do it and went on the make Unreal.
One important insight into all of this is that, while there might not have been BSP renderers until 1995, the BSP rendering algorithm was probably 10-20 years old at that point.
Another good example of this is the Phong shading model. IIRC it was invented in the mid-70s, and some software rasterizers implemented it, but it didn't really make its way into graphics cards with fixed pipeline rendering until the mid-90s.
Graphics tech in the 90s and even early 2000s involved a lot of hardware and software catching up to theory from the 70s and 80s because we were finally getting enough compute power to make it worthwhile to use "approximate" rasterization-based algorithms in order to get real-time rendering.
I had to dig up my source for this. I did misquote. It was Wolfenstein that gave Tim a shakeup and it drove him from coding to management, not out of games.
> Did you think about doing a first-person shooter after their success with Wolfenstein 3D and Doom?
> TS: It was funny how we got to that point. When I saw Wolfenstein for the first time, that was truly shocking. I'd never envisioned that you could do 3D in a computer game; I don't know why.
> The research had indicated that you could do that for at least 15 years before that, but it was this 3D game with real-time texture mapping; you know, real-time bitmaps scaled up and displayed in 3D on the screen. It never occurred to me that you could actually write code to do that. It was just another lack of foresight there.
> But seeing that for the first time, I was like, "Wow, I'm totally not worthy. I need to get out of programming now, because I'm never going to be able to compete with this." So they just basically demoralized me into becoming a manager for a few years.
> Around 1994, James Schmalz had written this 3D texture-mapping code, and I was starting to think, "Hmm, maybe that's not so hard." So I started reading up on references there and experimenting with it, and it turns out that, yeah, it's just another piece of code that you can learn how to create.
Yup, in hindsight it's interesting because the key innovation was realizing that real-time 3D was possible.
The algorithms themselves (like 3D texture-mapping) are college third year problem set level difficulty to actually implement, but having the curiosity, courage, and ambition to be the first to do it real-time is huge!
The algorithms used in today's 3-d game engines are definitely more complex than something I'd expect a college student to do, but the state of the art has also progressed substantially since the 90's.
That is incredible. I think that with games in particular, it is very easy to feel like you will never bridge the gap between where you are and whatever current AAA game is doing. It's easy to forget that those games we compare to are made by huge teams. The smaller games that are created by individuals and small teams are the product of a lot of effort. One simply has to stay the course and understand that a game is not made overnight. Still, it can be discouraging.
https://www.beyond3d.com/content/articles/8/ for the history of it. The original author is still unclear, but that article digs back as far as Gary Tarolli at 3dfx/SGI (by way of Carmack, Abrash, and Terje Mathison)
The man is a legend. I remember using his little set of DOS utilities (things like stuffit.com [2]) back in the early 1990s, which I got from a friend whose dad was a colleague of his at Hydro. They were all written in assembly language, and were superb little extensions to DOS.
I'm also a programmer who does 3d modeling as a hobby. I'd never do 3d modeling as a job. Not only does it pay less, but a lot of the novelty would be lost. There's something endearing about being able to come home, shrug off my job for a bit, and model something.
