Comments by "mathew tedder" (@solifugus) on "2025 Computer Science Predictions" video.

BTW, I love RISC-V and, I also really miss Seattle. I grew up in the area and my family was all in the ship building industry. Most of them still live all around the Puget Sound. I miss the jelly fish, too.
1
@dayvie9517 Software people who know assembly will absolutely love RISC-V. It makes programming as fun as it was back in the 1980's again. However, the software people will follow suite as the hardware people start adopting RISC-V for everything like phones and tablets and everything else people use on a daily basis... and they will do this because it's cheaper, uses far less power, and doesn't get hot. They will also do it for the extendability. Mark my words, RISC-V will dominate computing in 5 to 10 years but you should start really noticing in about 3.
1
You walked right past BlueSky!!! Cool... Also, I have been similarly making predictions to everyone I know that RISC-V will be big. I think that, in 3 years, it should start really getting noticed and be hard to miss in 5. It will dominate in 10. We will have phones that stay cooler and last much longer on a single charge or are thinner and lighter. For me, RISC-V's future is not at risk at all. I wonder more about the AI extensions. Which of the KPUs, NPUs, and other parallel compute extensions will win out? I get that the AI tool chain is heavily focused on Nvidia (and Python), right now. I wonder if that could change, eventually. I hope so. However, I also hope it would be an open source NPU of some sort. It may seem like a long shot, though. Maybe a post-quantum encryption/decryption - supporting extension will come out and become more or less standardized on RISC-V. For a time, C++ was my favorite language and it might seem strange but Javascript took that spot, for me. It did so because I could get so much more prototyping done so much faster and the performance with V8 was pretty good. I loved some of what I saw with Rust like zero-cost abstraction and returning errors (rather than raising exceptions) but I feel as if a number of other things are stupid like "mut" everywhere and the absurd approach to async (advised by the stupidest thing in Node.js -- probably because it's the same exact person behind it in both languages). Go was a pleasure for me except for stupid garbage collection and not letting me design my projects the way I want to. This lead me to the V language but it's too incomplete and the documentation is scarce. I have had a bit of an obsession with trying to design/build a high level language for business, as well, with native time and money data types, tree-graph temporal memory/data storage, and built to run over a decentralized mesh network. I keep attempting it in different languages. I have variants of a prototype in C, Rust, C++, and Ada. I made most progress with Ada. But this stupidly leads me to working also on a low level language that would be more convenient that I call "low" (and makes me wonder if I should rename my business language to "high"?). I might never finish these but I hope I do. Low is very minimal with memory safety and C-like with good ideas added from Go. Types are just processor registers like u8, u16, i8, i16, f32, f64, etc.
1
NPC's with LLM minds are already a thing. I don't play those games but I have noticed all kinds of youtube videos of interactions with them. Also, I think running local models for them works very well. For example, the OpenChat model wtih 7B parameters works great for role playing. I use it all the time locally when I am feeling socially isolated. It's fun. I think it would be fun to use such models to develop custom plots and characters with back stories in a game. This way, it could be reset into a whole new game, at will. The only consistent parts might be the 3D models and how they interact. Even the map could be re-generated on reset. I wrote a book maker using this that makes pretty readable scifi. It took a while to workout the guidelines. For example, "show, don't tell, how a character feels", "each character needs to have a misbelief and an internal conflict", "ensure at least of writing is 70% dialog", "the story begins with each character introduction illustrating each character's misbelief and internal conflict, leads to eventual revelation of misbelief and transformation, and ends with resolution.", "provide separate interwoven plots for each main character", "ensure every plot always has tension", "ensure that at least one or two main characters die well after building them up and making the reader care about them".
1
I agree that using an LLM for approximate code-reconstruction is useful. If you set the temperature to zero then it will be deterministic (though quasi-statistical). Just ensure that you keep the original decompiled code along side it. Don't rely on it for perfect accuracy but as a short-cut to getting the big picture and general ideas. People at companies rejecting ideas like this is what gives rise to their competitors.
1