Just one point about testable assembly: I like the Golang guidelines which require to write a Go version before implementing the same in assembly. That way there is a baseline to compare with in terms of correctness and performance. Also the Go project has recently introduced mutation testing and test coverage on assembly code which is very interesting.
Finally about detecting at runtime the presence of simd: I am confused why a third-party dependency or even the std is needed. At least on x64, it’s just one instruction (“cpuid”) and then checking if a bit is set, right?
I agree with the premise, just use a specific version of your dependencies, that’s generally fine.
However: You absolutely do need a lock file to store a cryptographic hash of each dependency to ensure that what is fetched has not been tampered with. And users are definitely not typing a hash when adding a new dependency to package.json or Cargo.toml.
> And users are definitely not typing a hash when adding a new dependency to package.json or Cargo.toml
I actually much prefer that: specify the git revision to use (i.e. a SHA1 hash). I don't particularly care what "version number" that may or may not have.
I wrote a toy Kotlin compiler, for fun.
Then one day a Jetbrains employee opens an issue which only says: “Why? Just why?”.
Maybe it’s the language barrier… but I did not find that particularly polite.
On the other hand I open sourced my blog and received lots of small contributions to fix typos or such which were nice.
The guy was probably upset that someone might be trying to compete with them while their compiler is itself open source. But it still sucks that they couldn’t be more subtle about it. In the end both they and you got upset. A small change in his tone and you might both come off with a nice feeling, him for knowing you were just playing around, and you for perhaps getting recognition from a Kotlin dev.
Obviously I can't change how it made you feel, and as such it was a crappy reply to receive, but on one level at least it's a genuine question that projects should have an answer for.
It kinda matters if you build something as a proof of concept, or you build it to exercise some new technique, or you build it to improve the state of the art, or you build it as the foundation for a product etc.
You wrote it "for fun". That's an excellent reason to write something. I can appreciate your effort in that context. It's going to have rough edges etc. And when it's not fun anymore you move on.
Someone else might write the same thing, but for a different reason. Maybe they want a "better Kotlin compiler". They intend to make it perfect, build a product around it and so on. This sort of project encourages a different level of scrutiny than something fun.
So giving context to a project helps attract the right kind of attention. And more importantly the right kind of other-peoples-time.
But yeah, asking like that is not terribly polite.
>genuine question that projects should have an answer for.
Just because they take issue with the wording doesn't mean that they don't have an aswer for that question. Also, that is an awful entry point for a discussion about the purpose of the project.
A toy Kotlin compiler could probably be useful to bootstrap Kotlin from source, without any existing Kotlin binaries. Looks like there is no path to do that right now.
I’m a bit confused by this writeup. It seems to me that you’re experiencing two issues:
1. An object that’s really a Rust Vec under the hood is awkward when you try to pass ownership to C. ISTM you end up solving it by creating what is, in effect, a handle, and freeing that using a custom free function. Is this really a problem with Rust FFI? This style of API is very common in native C code, and it’s a lot more flexible and future-proof than having a library user call free() directly.
2. You’re consuming the API in Rust and being sad that there’s no native defer statement. But Rust can do RAII — could you build a little wrapper struct that implements Drop?
Valgrind sometimes has problems with encapsulated C libraries slow anonymous memory leaks. For example, the session caching in modern libcurl is obfuscated fairly well from novices.
Valgrind is good to run as a sanity check, but I prefer a month under a regression test hammer to validate something isn't going to slowly frag itself before scheduled maintenance. =3
I have implemented polling against a cluster of mixed mariadb/mysql databases which do not offer listen/notify. It was a pain in the neck to get right.
- The batch size needs to be adaptative for performance, latency, and recovering smoothly after downtime.
- The polling timeouts, frequency etc the same.
- You need to avoid hysteresis.
- You want to be super careful about not disturbing the main application by placing heavy load on the database or accidentally locking tables/rows
- You likely want multiple distributed workers in case of a network partition to keep handling events
It’s hard to get right especially when the databases at the time did not support SKIP LOCKED.
In retrospect I wish I had listened to the WAL. Much easier.
The x64 assembly would probably work natively on the Mac, no need for docker, provided the 2 syscall numbers (write and exit) are adjusted. Which llms can likely do.
If it’s an ARM Mac, under Rosetta. Otherwise directly.
About not having perf on macOS: you can get quite far with dtrace for profiling. That’s what the original flame graph script in Perl mentions using and what the flame graph Rust reimplementation also uses. It does not have some metrics like cache misses or micro instructions retired but still it can be very useful.
Just one point about testable assembly: I like the Golang guidelines which require to write a Go version before implementing the same in assembly. That way there is a baseline to compare with in terms of correctness and performance. Also the Go project has recently introduced mutation testing and test coverage on assembly code which is very interesting.
Finally about detecting at runtime the presence of simd: I am confused why a third-party dependency or even the std is needed. At least on x64, it’s just one instruction (“cpuid”) and then checking if a bit is set, right?