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.
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
Zig is a very interesting language. You are able to do thing that would require wizard level skills in C with simple plain language construct. Like serializing/deserializing an enum variants over the wire for example in the most efficient way (look at std.json.{parser, stringify} [0]).
> soon we’ll also have a package manager
This. If they succeed to do this (and I have my doubts) it will be a paradigm shift for low-level "system" programming.
Let's hope this is not vaporware.
Finally, it's relatively easy to contribute to Zig. Andrew Kelley is very opinionated on where the language should go with an emphasis on simplicity which sometimes can make things awkward but he is also persuasive and welcoming. I have been using Zig for a month and I am still positively surprised so he must be onto something.
[0]: https://github.com/ziglang/zig/blob/master/lib/std/json.zig#...
It is a weird self-fulfilling thing. People talk about it like it's a thing, so it's a thing, even if there's very little actual evidence of anyone sincerely holding this belief. People repeat that there's this plague of folks requesting that projects be re-written, and while it is literally true that I have seen two or three instances of this (you link to one of them, and notably it is not anyone harassing maintainers about their choices), it's been two or three.
I actually got annoyed with this enough that I started doing a quantitative analysis; if you look at the canonical repository tracking this, it's got 44 total issues, most of which are jokes https://github.com/ansuz/RIIR/issues If you search GitHub for issues with these words in it, you get some, but many are either obvious jokes, people making issues on their own projects to think about doing this, and things like that. I never followed through on collecting it into a blog post though.
I didn't think your writing was inappropriate at all; memes are memes, and I'm convinced that this one is just never going to die, because it's taken a life of its own, regardless of the underlying truth or not.
> I've always tried as much as possible to treat strings as just opaque data and never look into them, which tends to work well, but in some domains you really need to look at and massage the characters/codepoints/grapheme clusters, and the lack of a first-citizen UTF-8-aware string type is, I think, a bit unfortunate in this day and age.
You don't need a UTF-8 type for that, you just need routines that handle UTF-8 strings, like utfcpp (https://github.com/nemtrif/utfcpp).
I prefer D, it can be fully compatible with C, the syntax is easy to learn if you've used any of the C family you already know 80%, the package system is simple, modules mean no more headers or include statements just import things where and when you need them, supports every style of programming, QOL improvements like ranges and foreach, proper strings, optional garbage collector, has a long history of continuous improvement and support. To me it's the clear choice if I'm going to rewrite an old C project since I can mostly just copy paste the old code and it runs, after which I can clean it up and simplify it using the new features mentioned. Oh! and integrated unit tests and documentation generation are superb. Helpful error messages too. I could go on but I'd prefer everyone just try it out and see for themselves.
https://dlang.org/
Agreed, and Zig also has a lib for that as well:
https://github.com/jecolon/ziglyph/
It might help to better understand the motivations behind unsafe Rust by reading some of The Rustonomicon[1].
[1] https://doc.rust-lang.org/nomicon/
I totally 100% agree. "Getting started" with a C/C++ project is a huge pain and IMO where most people get stuck and give up on their weekend project.
I'm working on a game engine in Zig[0], and I've been able to package up GLFW, write a build.zig file that `git clone`s all of the third-party system dependencies so that anyone can just:
```zig
const glfw = @import("glfw/build.zig");
...
lib.addPackagePath("glfw", "glfw/src/main.zig");
glfw.link(b, lib, .{});
```
And have GLFW building (and cross-compiling!) for their project, without installing anything other than Zig and Git. No XCode. No `apt-get install ...`. Nothing. Just `zig` and `git` binaries. Zig is the C compiler and builds the GLFW source, and I have repositories with the required prebuilt system libs for cross compilation.
[0] https://github.com/hexops/mach
> You're splitting hairs in a weird way. rustc cannot compile C code. zig can.
But why do I care? I don't use rustc directly, the build system of choice does. And very few of the major build systems have an issue handling multiple languages.
Cargo (rust's build system) supports build scripts and the community has already created C/C++ compiler hooks such as https://github.com/alexcrichton/cc-rs
rustup and cargo also provide easy cross-compilation support, too.
- C, Objective-C = https://github.com/jacob-carlborg/dstep
> its test blocks make unit testing trivial to integrate.
Again, D also has this:
https://tour.dlang.org/tour/en/gems/unittesting
void main() {
Keep in mind that filesystem paths aren't strings. On Linux, they are raw bytes without any fixed encoding (but usually UTF-8 on UTF-8-based locales), and on Windows, they are sequences of 16-bit codepoints which are expected to be UTF-16 but not validated.
Rust's OsStr is my favorite approach so far. It stores Linux's raw bytes as-is, and stores Windows's possibly-valid UTF-16 as WTF-8. This makes path management "just work", with the ability to operate normally on invalid UTF-8 or UTF-16 paths, and zero-copy conversion from UTF-8/ASCII strings to OsStr (though converting OsStr into UTF-16 requires parsing). (Qt's QString-based file dialogs on Linux fail to convert invalid UTF-8 paths like those in https://github.com/petrosagg/wtfiles into QString, causing Qt-based apps to open/save the wrong paths.)
However there are difficulties in printing an OsStr. For example, a file dialog that shows filenames as raw bytes can't show non-Latin/Unicode characters in a human-readable form, and a file dialog that shows filenames as Unicode strings can't handle invalid Unicode filenames. GTK3 file dialogs show filenames as Unicode strings, and when encountering files with invalid Unicode names, instead displays "file�name.txt (invalid encoding)".
Worse yet, how should a file dialog allow users to rename files? If it's based around byte arrays, the user can't enter Unicode characters directly, and if it's based around Unicode (or a locale-specific text encoding), it can't display existing files with invalid Unicode/etc. in the name (probably not an issue if it allows the user to rename to a valid name), nor allow users to enter invalid Unicode (which is not an issue IMO).