Our great sponsors
-
zig
General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
This comment suggests otherwise:
https://github.com/ziglang/zig/issues/89#issuecomment-122118...
Although I'm not sure the "self hosted compiler" is the same as "llvm free backend".
Since Rust 1.67.0, the compiler has a specific optimized code path for the (already older) include_bytes! macro: https://github.com/rust-lang/rust/pull/103812#issuecomment-1...
FWIW, both GNU objcopy and GNU ld (including e.g. the XCOPY-deployable ones from w64devkit[1]) are perfectly capable[2] of turning binary data into MSVC-acceptable COFF files with start and end symbols, while Free Pascal, for example, straight up ships with a bin2obj tool; the MSVC toolset is the outlier here.
[1] https://github.com/skeeto/w64devkit
[2] https://www.devever.net/~hl/incbin
I implemented a prototype version of the algorithm in that paper when exploring exhaustiveness checking for pattern matching in Dart.
I found it pretty easy to understand, but also really easy to get it to generate huge combinatorially large spaces. Some careful memoization and deduplication helped, but even so I never got the performance to a state I considered acceptable.
Instead, I went with Luc Maranget's classic approach and figured out a way to adapt it to a language with subtyping (with a ton of work from Johnni Winther to figure out all of the hard complex cases around generics):
https://github.com/dart-lang/language/blob/main/accepted/fut...
The performance (in the prototype!) was dramatically better. You can always make pattern matching go combinatorial, but I haven't seen any real-world switches get particularly slow with our approach yet, and we have some fairly large tests of matching on tuples of enums.