First, Casey offers refunds on the handmade website for anyone who purchased the pre-order. Second, the pre-orders were primarily purchased by people who wanted to get the in-progress source code of the project, not people who just wanted to get the finished game. I'm not aware of anyone who purchased the pre-order solely to get the finished game itself. (Though it's certainly possible that there were some people.) Whether that makes a difference is up to the reader I suppose, since the original versions of the site didn't say anything about how likely the project was to finish and did state that the pre-order was for both the source-code and the finished game.
Second, the ten-year timeline (I believe the live streams only spanned 8 years) should be taken with the the note that this is live streaming for just one hour per day on weekdays, or for two hours two or three times a week later in the project. There's roughly 1000 hours of video content not including the Q&As at the end of every video. The 1000 hours includes instructional content and white board explanations in addition to the actual coding which was done while explaining the code itself as it was written. (Also, he wrote literally everything from scratch, something which he stated multiple times probably doesn't make sense in a real project.)
Taking into account the non-coding content, and the slower rate of coding while explaining what is being written, I'd estimate somewhere between 2-4 months of actual (40hr/week) work was completed, which includes both a software and a hardware renderer. No idea how accurate that estimate is, but it's definitely far less than 10 years and doesn't seem very indicative that the coding style he was trying to teach is untenable for game projects. (To be clear, it might be untenable. I don't know. I just don't see how the results of the Handmade Hero project specifically are indicative either way.)
Florida (and the USA as a whole) have been discussing getting rid of the daylight savings change on-and-off for several years.
If that law goes through in December of this year, the date I stored for my event will now be off by an hour because come July 2025 Florida will be on UTC offset -6, not -5.
On the other hand, if I store the date with a fully qualified tz database timezone like this: "2025-07-04 03:00:00 America/New_York" the time will continue to be displayed correctly because the tz database will be updated with the new offset information.
Sublime Text works pretty well for me. I think you need to turn on spell check in the settings (off by default?) Then you can choose which syntax highlighting scopes you want to spell check. I have mine configured to spell check comments and string literals.
All the other symbols, parens, etc. are mapped to similar one-finger-two-key shortcuts.
Significantly cut down on finger stretching which used to cause me mild pain.
Using a larger font size or a font that renders larger at the same font size means you can write less content in the same space.
https://github.com/Jayshua/tg-daemon
I found there were a number of things that I wanted a personal telegram bot to do which would have been relatively difficult or annoying to implement in a full-blown programming language, but pretty easy to string together a shell script for. So I wrote this program that acts sort of like a classic CGI gateway for Telegram conversations, forwarding messages over stdin/stdout.
It just bothers me a bit that the stuff I'm putting in the comment is documentation that I would put inside a @doc on any non-private function, but I can't use @doc.
That's extent my personal experience can push things as far as active production applications go, but it seems to me there's something a bit more in Elm beyond just the type system. Haskell and PureScript both have static typing, but I've had runtime errors in both those languages. Not as often as JS or C or even Rust, but they do happen. In Haskell because the 'error' function exists and so people use it. In PureScript because it has its version of Elm's native modules, permitting arbitrary functions to be implemented in JS. The JS can (and does) produce runtime exceptions.
It seems to me that the promise from TS, Haskell, PureScript, etc. is something like "with this language/type system runtime errors will rarely happen" whereas the promise from Elm is "with this language/type system runtime errors can never happen."
I think that transition from 'rarely' to 'never' has been a big part of the Elm project for a long time. It's been on their homepage for as long as I can remember. At least prior to the big 0.18 native modules controversy.
If the idea is "no runtime exceptions can ever happen" with the implicit addendum "no matter what you do" native modules have to go. They were a vector by which user code could crash the application, breaking the promise. In that sense the restrictions are not arbitrary, but instrumental in upholding a major design goal of the Elm project.
That said, I don't know how much value there is in the "can never crash" promise. It feels like a step in the right direction, but at the same time it seems all the benefits in production code that I've personally experienced and cited in my earlier comment don't fall under the edge cases Elm prevents with its stricter promise. The two or three exceptions I've encountered in PureScript as a result of its version of native modules existing were all in toy programs, so maybe it's just not a big deal in real production apps.
Contrast with an elixir app of similar size that I also maintain. I fix on average 1-2 bugs per week, almost all of them are things that the elm compiler would have prevented like calling a function that was removed or renamed last month or not handling a case where a database request returned 0 records instead of 1.
Honestly though the biggest draw for me is the refactoring experience. For various reasons I had to do a major refactor of both code-bases. Not adding new features or anything, just restructuring the code and module layout to line up with the way the code actually functioned. Paying the tech debt essentially. I'd say both refactors were of roughly similar complexity, touching probably 75% of the files in each project.
The elm refactor took about 5 hours and worked as soon as I fixed all the compiler errors. I never had to fix a bug from that refactor - it just worked. And the code was way easier to understand after paying all that tech debt back.
The elixir refactor took 4 days, full time. 25ish hours. It also required me to write about 150 tests that weren't there before because the compiler wasn't able to point out code that would always fail at runtime. After deployment I had to fix a handful of bugs that still made it into production, despite how careful I was to not break anything.
Idk, being able to completely restructure the code without worrying about breaking anything really appeals to me for some reason.
It's a relatively new feature - within the last year I think.
I'm curious what price ranges are out there for getting a single server (with your own hardware) in a local data center.
You would have a function like this:
parseJsonString : String -> Result Error Person
Where Result is a value that is either an Error or a Person.
To get the Person value out, the type system forces you to also do something with the Error if it exists. Not handling both possibilities in some way is a type error.