> Similar to how students who spend most of their time practicing what they are studying with actual exercises achieve higher grades
This is spot on.
> build a mental model of the code with every new line of code
This idea has been explored in depth in the Peter Naur's excellent paper, "Programming as theory building" [1] (also extensively discussed on HN [2]). If you haven't read it yet, I bet you will enjoy it a lot. :)
"Eliza" is a bit unusual for Zachtronics as it's not a programming/puzzle game but a visual novel. But it's excellent and I think it's one of their most under-appreciated games. It's well-written, well-acted, and very prescient. Highly recommended!
What a great and timely question! :) I quit a week ago to take a year-long sabbatical.
> 1. What pushed you to do it?
The pursuit of curiosity, for the most part. That's what makes quitting a lot harder when you have a good job and nothing to complain about: you feel like you're making a huge mistake on a whim. Doubly so when you consider the state of the job market at this time.
That said, we don't live to work; we work to live. It's a lot of risk and uncertainty, but you should remember that while some unknown bad things can happen in the future, unknown good things can happen too! [1] When you own your time, you increase your luck surface considerably: you have more opportunities to travel, to wander, to play, to meet new people, to tinker, to discover.
So I've been thinking and reading about this a lot. The final push came from two books I read: "The Pathless Path" by Paul Millerd [2] and "The Inner Compass" by Lawrence Yeo [3]. I can't recommend them enough.
> 2. What will you be doing? (Even if nothing!)
I have a huge Steam backlog to beat... :) Besides that, I'll be studying computer science and maths. Programming language theory, compilers, and functional programming are particularly close to my heart.
> I've rarely seen a repo and a problem that claude can't chew through with the right prompt
> a skill/PEBKAC issue
But then I remember how Anthropic couldn't fix the flickering issue for many months. It just does not compute.
Is it that people working at Anthropic can't prompt and it's a "skill issue" too? I mean, the terminal does not flicker in a lot of other complex TUI apps that I use every day - Midnight Commander, Emacs, tmux, etc. These are open source, Claude could be prompted to "just do what Midnight Commander does". So what is it?
It's not just Google AI Studio, it's also Google proper. Just one search result page consumes gigabytes of RAM. How did this happen? I've switched to DDG and never looked back.
> Is this what getting old feels like? Hating everything the rest of society is racing to embrace?
I don’t think so. Some societies are racing to embrace mass surveillance and abuse of civil rights. Pointing this out and complaining about it is not “hate” and not reserved for old people only. :)
I think spreadsheets have been severely undervalued by software engineers and they're generally under-researched. It's definitely possible to use them in more non-obvious and interesting ways. E.g., see AmbSheets [1]
I have a feeling that the same idea absolutely does apply to code. Writing code is much closer to writing prose than it may seem. And the act of writing code also makes you think as you write. Even if you're writing boilerplate. Because how else would you uncover subtle opportunities to reduce the boilerplate and introduce new, better abstractions?
> only to have it completely obsoleted a few years later
Not really. There aren’t as many fundamentally new ideas in modern tech as it may seem.
Web servers have existed for more than 30 years and haven’t changed that much since then. Or e.g., React + Redux is pretty much the same thing as WinProc from WinAPI - invented some time in ~1990. Before Docker, there were Solaris Zones and FreeBSD jails. TCP/IP is 50 years old. And many, many other things we perceive as new.
Moreover, I think it’s worth looking back and learning some of the “old tech” for inspiration; there’s a wealth of deep and prescient ideas there. We still don’t have a full modern equivalent of Macromedia Flash, for example.
I strongly recommend to check all other papers and articles on https://okmij.org/ftp/, every single one of them is brilliant and insightful. I love the pedagogy, the writing style and clarity. Oleg Kiselyov is one of the best technical writers I've discovered recently.
To understand unsafe code you need to understand what's safe code and pointers first.
Basically, safe code is automatically managed to get rid of memory leaks [0], dangling pointers [1], null pointer dereferencing [2], race conditions [3], and many other memory management bugs.
You don't encounter any of these in JavaScript because it's a managed language, meaning there's a garbage collector [4] that looks after all your memory allocations.
Contrary to the managed languages, C & C++ are unsafe and "native" (meaning that they're very close to the hardware level) - it's a wild land where you manage memory manually yourself. If you miss a single deallocation, you're left with a memory leak. If you deallocate a memory region twice, you have a double free situation [5]. So you have to be very cautious when writing code in C & C++. There are many techniques to make it easier (e.g. smart pointers [6]), but not all developers use them.
Rust takes the middle ground: it combines safety with unsafety by using a know-how affine type system with a borrow checker, which allows values/variables to have only one owner. This system has properties of both managed and unmanaged code. "Unsafe" code in the context of Rust means that you consciously turn off the borrow checker, leaving on your own and managing memory deallocations manually, as in C. That makes it possible to interface your Rust code with the native code, at the cost of making you prone to all errors and bugs that are listed above. So it's a good thing to minimize usage of unsafe code, to allow the Rust compiler to check your code for safety.
Rust doesn't require a VM or any prerequisites installed on a target system. In this regard it's comparable to Go (though I'm not sure that it's viable to statically compile everything into one binary, but technically it should be possible). Anyway, it compiles down to the machine code, so at most you'll need to have a bunch of libraries along with your executable file.
Hopefully you'll have a lot of fun with learning! :) Oh, and almost forgot: Rust community is one of the best that I've seen, so feel free to ask any questions on http://users.rust-lang.org - I'm sure there's a lot of people who'll be glad to help you.
It's pretty stable at this point (1.x means that no backwards compatibility will be lost as in the past), and it's already used in production (e.g. Skylight [0] is written in Rust, as far as I know, and don't forget about Servo).
Dependency management with Cargo is hands down one of the best out there, it just works. The standard library continues to expand, but there are also many other external libraries you can find on crates.io.
> it looks pretty functional... is it basically a systems-ish scala?
I think it's better to compare Rust to ML languages family (OCaml, F#, and so on), as it was clearly influenced by it. It has many features you can find in ML languages - pattern matching, ADTs (algebraic types that are enums in Rust), and many other similarities.
Overall, the language feels very robust now, and I enjoy it much - it's a very decent replacement for C++, basically "C/C++ done right".
My blog: http://nbaksalyar.github.io/