Hunting in modern rail vehicles is largely a solved problem using axle yaw dampers and other systems. I struggle to see why BART doesnt use a standard wheel profile and buy from a rolling stock supplier with experience of designing for good ride quality.
There are some trains which use independent wheels, but they need complicated mechanical centering mechanisms to replace the self-centering effect, and these are more expensive to maintain.
I would greatly greatly appreciate an effort to benchmark builds without optimizations too. We've seen some LLVM-related slowdowns in Crystal, and --release compile times are far less important than non-release builds to us.
DBMSes always keep their database in the file system in a consistent state to be able to recover from system crashes. Taking a file system snapshot is equivalent to pulling the power on the database server in terms of data recovery, but databases are designed to support this.
It seems a lot of people have these stories, and then people like me and OP who have had btrfs survive the most fucked up situations (I've had a btrfs nas built on "random drives I've had lying around" and abused it for 5 years and had 0 bugs at all).
I'm not sure what causes it, but there seems to be an effect where btrfs loves you or hates you and few people with mixed experiences regarding data loss. One possible cause is distro choice tends to be per person and how up to date said distro keeps it's kernel. But, I'm not sure.
The basic foundations of a Windows port are already in place for Crystal, merged into master. In fact you can can already cross-compile a "Hello World" on Windows.
This means the port is in a place where the community can pitch in and help port little bits of the standard library, and help bring it into a release-ready condition.
The JSON code is written in a way which forces the whole object to be loaded into memory - both in Nim and Crystal. It would be interesting to compare code clarity and benchmarks for a streaming JSON implementation though.
Agree that performance comparisons between Nim and Crystal are going to be largely moot. They're both "fast enough" for their target audiences.
I know, and it's unfortunate that there's not been time to work on this. I don't think people understand how small a language like Crystal is though. There's just one person working full-time on it currently!
If you'd like Windows support, one thing you could do to help is donate time or money to the Crystal project [1].
There's one small error, where the article says "With Nim, we were also able to link both the Nim and C files into the same executable, which Crystal sadly cannot do." However, this is not true! You've passed the object file you created directly to the linker, so it is in fact included directly in the executable.
I'm a core team member of Crystal, feel free to ask away.