The IDEs we had 30 years ago ... and we lost
blogsystem5.substack.com
1,180 root system drawings
images.wur.nl
Event Sourcing, CQRS and Micro Services: Real FinTech Example
lukasniessen.medium.com
SQL Anti-Patterns You Should Avoid
datamethods.substack.com
Attention Is a Luxury Good
seths.blog
Who invented deep residual learning?
people.idsia.ch
Flowistry: An IDE plugin for Rust that focuses on relevant code
github.com
Andrej Karpathy – It will take a decade to work through the issues with agents
dwarkesh.com
Lux: A luxurious package manager for Lua
github.com
Fast calculation of the distance to cubic Bezier curves on the GPU
blog.pkh.me
AMD's Chiplet APU: An Overview of Strix Halo
chipsandcheese.com
Our Paint – a featureless but programmable painting program
wellobserve.com
Rapid amyloid-β clearance and cognitive recovery by modulating BBB transport
nature.com
StageConnect: Behringer protocol is open source
github.com
Cruz Godar Generative Art Gallery
cruzgodar.com
Live Stream from the Namib Desert
bookofjoe2.blogspot.com
The Unix Executable as a Smalltalk Method [pdf]
programmingmadecomplicated.wordpress.com
Life, Work, Death and the Peasant, Part V: Life in Cycles
acoup.blog
This is interesting but I feel like a lot of these Rust-inspired package managers are a little... too inspired by Rust. This project for instance uses .toml as a config file format, presumably because that's what Cargo does.
But I think for this project in particular, Lua for the config files would have been a better choice!
I think that Lua tries to be a configuration language, and in fact Luarocks uses "rockspec" for their config, which is syntactically Lua. Lux claims to be inspired by Luarocks, and yet they chose to use toml over lua for config. I'm wondering why? What was wrong with lua that made toml a better choice?
edit: Okay, I've found more information where they say they support both formats... which, I don't know if that's the right call? Seems like going with one or the other is better from a project management standpoint, although I can see why they want to give users the option.
> Not everyone may want to migrate (nor use) the TOML system for describing a project. For this reason, I’d had liked Lux to support a rockspec file alongside the TOML file (similar to the old project.rockspec format). This has finally been implemented! By creating a file called extra.rockspec in the project root, you will instruct Lux to merge the TOML and the rockspec together when performing any sort of operation.