zig VS regex

It really isn't that much different though. After skimming through the source code of Zig, you can see that well over 90% of the code is OS independent.

Not only that, it looks like they do have windows support and it's just failing atm. It also looks like they have cleanly separated all OS functionality from the logic. This is where it looks like the majority of the OS dependent code lives[0], and the implementation for this is 1000 lines of code. So clearly, it looks like it shouldn't take more than a few hours to get even a programming language up and running when porting it.

Further, it looks like they're using the cpp stdlib to assist with some OS dependent functions[1]. They're clearly using at least:

* std filesystem

* std future

* std iostream

* std mutex

* std thread

* std atomic

And more. So if you're being smart about things, which it looks like the developers most certainly are, then you don't need to reinvent 90% of the OS dependent code and can instead use the stdlib that already exists to automagically get that functionality.

[0]: https://github.com/ziglang/zig/blob/master/src/stage1/os.hpp

[1]: https://github.com/ziglang/zig/blob/a9c4dc84f487c4764c578743...

Zig, the programming language Bun is written on, is currently having some Windows headaches of its own: https://github.com/ziglang/zig/issues/12420

I wonder how much of Bun's immaturity is due to Zig's own immaturity.

Take https://github.com/ziglang/zig/issues/12251 as an example. Several people from the Rust and Haskell community slacked off on twitter about how awful of a language design this is. However, when you think about what the language actually compiles to it makes perfect sense, and is pretty straightforward.

Rust has the goal of putting as much smartness between what you type and what gets produces, which is a perfectly fine goal, but without a specification for the input semantics it's a pretty wobbly thing, especially for a systems programming language. A lot of bit packing code is simply not writable in rust today without immediately invoking UB, that works for now but might break with every bugfix release.

> This is unavoidable in any language that (supports dynamic memory allocation and) moves dynamic memory allocation into a library.

Not necessarily. The Zig[1] standard library forces callers to provide at runtime an allocator to each data structure or function that allocates. Freeing is then handled either by running deinit() on the datastructure returned (a standard convention), or, if the function returns a pointer, using the same allocator you passed in to free the returned buffer. C's problem here is it doesn't have namespaces or member functions, so there's a mix of conventions for what the freeing function should be called.

C++ allows this as well for standard library containers, although I've rarely seen it used.

> Also, say a DLL function returns a char pointer containing a string. How would you know whether to call free or delete on it? Or, maybe, the equivalent of free in Frob, the language that DLL happens to be written in?

I have to concede this one. I can't see a way out of this other than documentation.

[1]: https://ziglang.org/

On modern hardware, you should instead use a count-leading-zeroes instruction to directly generate the exponent bits from a uniform bit pattern. This is what is done in the Zig standard library:

https://github.com/ziglang/zig/pull/10428

Issue for it being removed

A simpler language exists, named Zig. Zig is a newish language that still hasn't hit a 1.0 milestone release quite yet, it's currently at 0.9.1. But Zig is, in my eyes, a very good language. It's plain, it's simple, and you can read through the documentation pretty easily. It lends itself to classic C, and borrows ideas from other languages in a few places.

it's more than just file sharing. you can view the history of each git commit, different branches of the same codebase, an issues tab to manage bugs, pull requests for the merging of code from one branch to another and plenty more

I can't seem to find any rationale for Zig not supporting function overloading, only mentions from Andrew that Zig does not and probably never will have it. Meanwhile that's one of the worst flaws of C, and one very easily correctable. Have there been any hard counter-arguments given?

Out of curiosity, when's the last time you looked into it? The deflate implementation got completely rewritten ~6 months ago: https://github.com/ziglang/zig/pull/10552

I found an unwrap() bug committed by me: https://github.com/rust-lang/regex/issues/555

In fact, there are a lot of crates in Rust where in other programming languages, it would be included in the standard library. Examples are regex, random number generators, additional iterator methods, macros for other collections, num traits, loggers, HTTP libraries, error handling, async runtimes, serialization and deserialization, date and time, and many more.

Link: https://docs.rs/regex

You had me at hello! https://github.com/rust-lang/regex/pull/883

regex : An implementation of regular expressions for Rust.

burntsushi is also the original author of the regex crate https://github.com/rust-lang/regex/graphs/contributors

On the tech side of this, there is really nothing to write home out- I used the ever-reliable clap-rs and regex crates for all of the heavy lifting. For the HTML rendering I decided to try out maud, which I found quite pleasant to write despite the lack of IDE support. I was particularly impressed with the quality of the error messages returned from the html! macro.

We were talking about EREs, which are an artifact of POSIX, not UTS#18. So the relevant standard for this specific conversion is POSIX.

To redirect to UTS#18, I don't think UTS#18 subsumes POSIX. UTS#18 doesn't support [[=a=]] for example AFAIK. And UTS#18 more generally doesn't require locale support. UTS#18 Level 3 was actually removed from the spec.

I think UTS#18 is a tortured document, but yes, the regex crate supports pretty much all of UTS#18 Level 1: https://github.com/rust-lang/regex/blob/master/UNICODE.md

Going beyond Level 1 is difficult.