WebAssembly seems like the most interesting thing to come out in virtual machines in a while; in theory if you build something for wasm then you can run it with native performance in all kinds of browsers, as well as, for instance, in Fastly's edge nodes. Fastly released their wasm compiler and VM, Lucet, last year; it can spawn new evaluation contexts about an order of magnitude faster than Linux can spawn processes. For security, that's potentially a big deal, because it means you don't have to reuse those evaluation contexts.

Golang is very practical for building systems. But it's worthless for building libraries except for Golang. Rust seems poised to displace C and C++ as the standard language to write libraries you can invoke from any language, and you'll be able to get better performance with Rust than with Golang. Maybe it's going to be as practical as Golang for writing systems too, I don't know. Parametric polymorphism is definitely a point on Rust's side.

Computer security in general is a really big deal. Unfortunately, 95% of the market is fake, like, 19th-century patent-medicine fake. Sooner or later the people who are doing real security instead of fake security will come out on top, but possibly only after the next major war.

Observable (d3.express) looks like it's probably going to be the way people write software in ten years. But probably not on ObservableHQ's SaaS offering, which may mean not in Observable's language.

If you're writing stuff on the JVM, use Kotlin or Clojure, not Java. There is literally no reason to use Java rather than Kotlin except if your cow-orkers don't know Kotlin yet. Despite its heavy costs, the JVM is a really useful skill to have in your utility belt, because of Android and because of all the libraries already available on the JVM.

Embedded development is really hot, and getting more so, as computers get smaller, cheaper, and lower power. You can get a computer now for less money than a transistor, if the computer is one of those 4¢ Padauk OTP jobbies and the transistor is a common transistor like a 2N7000. Right now this is all done in C, C++, and Arduino; Rust might get there soon, but the JVM won't.

By default, for embedded development, you should probably be using a BluePill or an Espressif board (with the Arduino IDE, if that's what you like) rather than an old AVR-based Arduino. The STM32 line used on the BluePill has an amazing selection of chips; the GigaDevice GD32 line of STM32 clones looks really appealing, but I don't have any yet. It looks like GigaDevice is going to offer a RISC-V version.

That's at the low end; at the high end, we have unprecedented computing power available, but generally no way to program it effectively, as in the days of the 1970s "software crisis". The things we know about that do get real benefits from this massive computing power include signal-processing algorithms, linear algebra, and artificial neural networks. Probably learning about numerical methods and signal-processing algorithms would be a good idea. The software tools (Numpy, Octave, Tensorflow, GLSL, CUDA) are important but secondary.

Provers got a lot better in the last decade; Lean, based on Coq's CoC, is good enough that Kevin Buzzard is making real progress in formalizing mathematics with it. People are also making real headway with HoTT-based systems. It's becoming practical to actually do machine-checked proofs for the first time, which means maybe we can automate a lot of the reasoning process involved in programming.

Speaking of which, Hypothesis can get you a significant amount of that extra reasoning power already, despite not attempting sound reasoning; if you're not using Hypothesis or something similar for your testing, you should be. It's worth writing a Python binding for your C or C++ project so you can test it with Hypothesis. (Alloy and TLA+ might be similarly useful as a way to verify higher-level models; Alloy, like Hypothesis, only looks for counterexamples, but it evidently finds them often enough to be very useful.)

SAT/SMT solvers like Z3 can be applied to constraint satisfaction. If you're not familiar with constraint satisfaction, basically the idea is that instead of writing the implementation, you write the tests, and the solver figures out the implementation for you. This is the way virtually all parametric 3-D CAD models are done, which is itself an increasingly interesting area, precisely because the cost of embedded computers is now low enough that we can surround ourselves with enchanted objects.

In terms of webdev, the most interesting thing I've seen lately (other than ObservableHQ) is Streamlit; it's a lot like React or redo, but running on the server side to render a webpage.

Who knows what's going to happen with cryptocurrencies, but you should at least play a bit with Bitcoin.