> Although much code can be optimized to get it to run 10-15% faster, if that comes at the expense of legibility then such "feature" get rejected nowadays.
Makes sense, and I'd probably make the same call if I was a maintainer and someone submitted a patch which increased performance at the cost of maintainability...
> Translating an existing codebase into a language that makes things more difficult¹ and (because of that) has (and most likely will have) fewer engineers willing to working in it looks very much akin to applying legibility-affecting optimizations to me.
Here I have to personally disagree. I think that Rust is easier than both C and C++. Especially when coming into an already existing project.
The chance of me contributing to a Rust project is higher than to a C project, because I feel more comfortable in knowing that my code is "correct". It's also easier to match the "style" since most Rust projects follow the same structures and patterns, whereas in C it can vary wildly.
E.g. I contributed my first feature to Valkey (Redis fork, C codebase) recently, and figuring out how the tests worked took me quite some time. In fact, in the end I couldn't figure out how to run a specific test so I just ran all tests and grepped the output for my test name. But the tests take tens of minutes to run so this was sub-optimal. On the other hand, 99% of all Rust projects use `cargo test`, and to run a single test I can just click the play button in my editor (Zed) that shows up next to the test (or `cargo test "testname"`).
(with this said, I think that Valkey is a really well structured code base! Great work on their part)
Anyhow, this is just to illustrate my experience. I'm sure that for someone more used to C or C++ they would be more productive in that. And I could go on for ages on all the features that make me miss Rust every day at work when I have to work in other languages, especially algebraic data types!
Isn't 10-15% faster compression, and 5-10% faster decompression, a very nice "feature"?
> [...] doesn't that mean the implementation is just... finished?
I don't think that it _necessarily_ means that, e.g. all projects that haven't had a release since 2019 aren't finished? Probably most of them are simply abandoned?
On the other hand, a finished implementation is certainly a _possible_ explanation for why there have been no releases.
In this specific case, there are a handful of open bugs on their issue tracker. So that would indicate that the project isn't finished.
(not the one you asked, but can chime in with some info)
This was a long time ago, but the way I did it was to use XcodeGen (1) and a simple Makefile. I have an example repo here (2) but it was before Swift Package Manager (using Carthage instead). If I remember correctly XcodeGen has support for Swift Package Manager now.
On top of that I was coding in VS Code at the time, and just ran `make run` in the terminal pane when I wanted to run the app.
Now, with SwiftUI, I'm not sure how it would be to not use Xcode. But personally, I've never really vibed with Xcode, and very much prefer using Zed...
If anyone is interesting in an example, here's mine:
> Based on your GitHub activity, you seem to have a penchant for projects that blend modern development practices with a touch of nostalgia. You're drawn to high-performance tools written in Rust, like 'bat' and 'fd', which reimagine classic Unix utilities. Your interest in 'fnm' and 'mise' suggests you're always looking for ways to streamline your development environment. The 'embassy' and 'retrowin32' projects hint at a fascination with both cutting-edge embedded systems and retro computing. You also appear to have a soft spot for quirky, niche projects like 'Factorio-SAT' and 'pokeyellow', which combine programming with gaming in unexpected ways.
and the roast:
> Oh, look at you, Mr. 'I-follow-940-repos-but-can't-decide-on-a-single-language-to-master'! You're like a kid in a candy store, but instead of candy, it's programming languages, and instead of a store, it's GitHub. I bet you start more side projects than you finish cups of coffee. Your GitHub profile is basically a museum of 'I'll get back to this someday' exhibits. You probably dream in Rust, wake up to Node.js, and spend your lunch breaks reverse-engineering Game Boy ROMs. I'm surprised you haven't tried to rewrite your coffee maker's firmware in WebAssembly yet. But hey, at least when the apocalypse comes, you'll be the go-to person for debugging Factorio optimizations on a Windows 95 machine using a command-line interface. Stay weird, you beautiful, overenthusiastic nerd!
> From here it’s easy to manually use the TPM to unlock the disk with the Clevis tooling and mount the root volume for hacking (it takes a few tries sometimes, but it gets there in the end):
They use the exploit to get dropped into a root shell, and then asks the TPM to unlock the disk for them, which it promptly does.
103 Early Hints is "experimental technology" (according to MDN) and isn't supported by Safari and Firefox. In Chrome it's only supported when using HTTP/2 or later (Firefox Nightly support it for HTTP/1).
I have >400 hours logged in Factorio, and almost all of that is on my laptop with an external Steam Controller. I think it works great, and play that way even when I'm home with access to keyboard and mouse.
The touch controls on the Steam Controller are excellent though, so I'm not sure how good it will be on the Switch which uses joysticks...
According to their site 100% of my funds should be covered since they are required to hold any client funds in a separate account which they cannot use for anything at all.
I've been using Monese since I moved here ~2.5 years ago. It was great as I was able to open the account in the weeks _before_ moving over, and thus already had a ready to go payment card & UK Bank Account when I arrived!
e.g. `Box::leak(Box::new( ... ))`