- Besides the logistical problems (shared ownership of MLB and minor league teams, the fact that almost all [good] players in the minors are really ultimately contracted with a major league team, etc), I truly believe that even the worst major league team would absolutely destroy AAA, and the best AAA team would probably set the single season loss record with ease in the bigs
- Since you mentioned Stan, feels relevant to mention https://stan-playground.flatironinstitute.org/, which lets you run Stan in WASM and analyze the results using WebR
- Yes, the opam repository has recently been working on an archival policy to reduce the size of the checkout and hopefully ease pressure on the dependency resolver by pruning 'obviously' wrong choices. However, the heuristic they chose seems to have mainly assumed that the things in the repository are libraries, and used dependencies for tracking usages. For executables like dune, this is obviously the wrong idea, and I think they're still deciding how to proceed while adding back most versions
- Not sure if you've watched the (entertaining but long) lecture by Casey Muratori linked at the start of this article, but I think this is sort of his point. ECS are powerful not just because of how modern computers schedule and execute code, but they also force you to break the traditional OOP encapsulation ideas, allowing more systems to 'reach across' systems.
He has a interesting discussion about how this 'omniscience' is viewed as a bad thing by many, but it is also incredibly powerful for business logic, especially with heavy user interaction like games.
- That can only happen if you as a user have the 'defaults' channel still configured as available, and conda-forge considers it a user error whenever this happens (the official line is `conda-forge is incompatible with the packages provided in defaults`). Many bug reports are closed simply by telling the user to fix their channel priorities and stop mixing the two
- This feels a bit like Stroustrops comment “There are only two kinds of languages: the ones people complain about and the ones nobody uses”. If MDN was not such an invaluable service, not nearly as many people would end up forming opinions!
As someone who only dabbles in the web platform I’ve always found the MDN pages to be very refreshing compared to a lot of documentation out there
- I think this is a very interesting way to think about and categorize languages. One of the reasons I've always preferred OCaml to Haskell, for example, is how less-escape-hatch-y mutation is. It's still not the preferred path, but it is certainly way closer to a first party feature and you won't immediately be asked to leave the room for suggesting using it to solve a problem.
You give up some stuff in exchange for this, of course!
- I first encountered the idea relatively recently with Clay [1] and I have been a fan since. Once you get past the “huh, weird” stage it has a lot of benefits!
- In particular, you can define the implementation flag and include the header in a .c file with no other contents to recover the more “traditional” build set up where you have a separate TU dedicated to the library.
I quite like the flexibility it provides in terms of making “unity builds” very easy, and scaling down quite well to small, single-TU projects with minimal build set ups.
- I was surprised to have to scroll this far to see someone bring up that the comparison point seems to be Python... I mean, I have absolutely no difficulty believing the statement
> For every time I experience a bug in Python that would have been prevented in Rust by its borrowchecker, I experience maybe twenty borrowchecker issues.
Now, if you replace "Python" with C or C++, my guess is the ratio at _least_ equalizes if not flips entirely
- There are reasons to be worried about additional safety beyond just security. My first thought when reading the article was it would be a huge bummer if a bug in tmux brought down a long-running or particularly stateful session. Of course, I’ve never encountered such a thing in my own usage, but if you could make it less likely that alone seems like a value add
- The idea of a language server also being some other kind of server is almost fiendishly clever to me and I'm shocked I hadn't seen other people play with this before. Definitely can think of applications to game programming -- a sufficiently dedicated engine team could fork their language's LS and allow you to e.g. integrate the map editor's feedback into the source code. I know hot-reloading is considered super valuable in games, but this is almost the dual of that idea. So clever!
- 748 is not tight. As given in the article, k=643 is independent of ZFC, and the author speculates that it's possible that something as small as BB(9) could be as well.
The 748/745/643 numbers are just examples of actual machines people have written, using that many states, that halt iff a proof of "false" is found.
At any rate, given the precise k, I believe your intuition is correct. I've heard this called 'proof by simulation' -- if you know a bound on BB(N), you can run a machine for that many steps and then you know if it will run forever. But this property is exactly the intuition for why it grows so fast, and why we will likely never definitively know anything beyond BB(5). BB(6) seems like it might be equivalent to the Collatz conjecture, for example.
https://oxcaml.org/documentation/modes/intro/