C is almost 50 years old. That’s a great age for a bottle of wine, but not for a programming language in a fast-moving industry. In the past decade, a number of new languages with different styles have emerged, all of which attempt to be C’s replacement in some way.
When a new language becomes more or less popular — developers start writing benchmarks that show the performance of software written in that language, CPU utilization and memory usage, binary file size, and so on.
Here, I want to experiment on a number of different levels — the UX of programming languages, the effectiveness of developers using those languages, how easy it is to use them, common frustrations, how it feels to read code. I believe that UX in programming languages is as important as their technical characteristics and has contributed to the success of languages.
Note: The rest of the article is very subjective.
The experiment
Let’s write an application that recursively scans all the files in the current directory and prints the lines in a file that matches the given wildcard. Similar to ag or grep, but using wildcards instead of regular expressions. Binaries should be ignored.
I found this problem to be a good exercise because it shows how to implement a very simple wildcard matching algorithm (which can be used for pure data like strings and numbers without learning any libraries or apis). The algorithm should pass some very simple tests. Then, it needs some very general underlying API, such as recursively scanning directories or reading files line by line. All parts of the problem are very simple, small, and wide-ranging. This little program can of course be implemented in any other language.
I wanted to test how “friendly” the language was with the regular “write-compile-run-debug” loop, the complexity of writing tests for matching algorithms, how easy it was to find the required apis, systems, and basic I/O to use with files, how friendly the compiler was when errors were detected, the “intuitiveness” of the language, and so on.
My sample size is fairly modest — just me. But to avoid bias, it’s recommended that you do it yourself (don’t take too long) and compare the results. After writing small programs in different languages, I asked my fellow developers (about 20 people) to read them and give me feedback about which boundaries were unclear and which were “easier” to read and understand. These developers have no experience with the language, but are proficient in other languages, such as Java, C#, JavaScript, Kotlin, Swift, etc.
The languages I tested here were C++, Go, Rust, and Zig. The results I got can be found at GitHub: github.com/zserge/glob… Please feel free to criticize.
Zig
I started with Zig, because I wanted to see what kind of language Zig was. I’ve heard good feedback on this language before, but haven’t used it yet. With no experience to speak of, I opened Vim and started writing code.
It took me about an hour to finish the program. The wildcard matching algorithm (which I knew before, only needed to be implemented in Zig) took me about 20 minutes. The rest are mainly looking for apis for directory scanning and file reading.
TLDR: nice, intuitive little language, worse than stdlib and Docs.
What I like is that the language is surprisingly intuitive for C programmers. It feels simple, and the documentation on the language (as opposed to stdlib) is clear and friendly.
Vim integration is also pretty good for young languages (before the Vim plug-in was enabled — formatting errors (compiler errors) frustrated me).
I like error handling. Like the testing tools that come with the language. Even like strings to be just byte arrays, as they are in C.
My first reaction to the attached allocator was shock, but in fact it didn’t even register. It has a minimalist feel, meaning that the core of the language is so simple that it doesn’t even use dynamic memory. Again, very close to C.
I had to read a lot of Zig compiler and STdlib source code to write this code, and the code is very clean.
What I don’t like: The STdlib documentation sucks. Everything I learned from directory scanning and file I/O — I got it from GitHub search results, which are also scarce.
The compiler prompt messages are not very friendly either, but for those familiar with C, this is no big deal.
The lack of string-handling routines in stdlib is unexpected, and to concatenate strings, you have to do everything manually — allocate buffers, put strings there. Or use a formatter and allocator to print both strings at the same time and then release the buffer. But that’s still very different than s1 plus S2.
Overall, the core language is simple and I like it, but STdlib is more limited than LiBC. I hope this is just an early sign of the language.
In fact, everyone who reads Zig code mentions this. It’s a bit verbose, but clear, predictable and easy to understand. Not surprisingly, since the language was designed with readability in mind (no hidden control flow, no hidden allocations, no macros, no operator overloading, no metaprogramming, etc.).
Rust
I tried to learn Rust and failed. It took me over 2 hours to complete the program, and I was disappointed when I finished.
TLDR: Complex.
What I like: Compiler prompts are message friendly. The documentation for the language is also good. But that’s it. I didn’t learn about life cycles, error handling, etc. The tools around the language are modern and good.
What I don’t like: Compiler messages are too verbose and take up the entire screen. I don’t want ruSTC –explain running around for every mistake. Please, don’t punish me. Documentation is sometimes too long. I mean, it’s better to have more documentation than less, but it’s better to have the TLDR version first. The same is true for STdlib, where a short piece of functionality and the work done in one sentence will be easier to read. There are &str, STR and [U8], to the surprise of the novice.
In general, coding in Rust feels like problem solving to me. Can be interesting and exciting, especially if Rust is used as an amateur language, but for most tasks I’d rather use an “ergonomic” language that will barely attract attention.
While reading Rust code, it is common to swear at least two “WTF” words. They often complain about unclear grammar and the need to pay attention to details. Moreover, pattern matching is still alien to “mainstream” developers.
Go
This is cheating. I used to use Go, but I wanted to give it a try in this experiment. As I expected, it took me about 15 minutes to get my full “Glob” utility working.
TLDR: Productive, but opinionated.
What I like: Felt very useful, the documentation was magical to me – short but useful, and I could immediately open the relevant stdlib function source code for further research. Based on past experience, WHEN I wrote my application, I imagined how to make it multithreaded and improve performance (simple Fan-out).
What I don’t like: Too many things (buffered I/O, GC) exist. You don’t feel in control (like in Zig). Too smug – this is the only language on the list where I had to create 3 separate files to make it work. You still make some silly mistakes, such as the unexpected variable shadow or using defer within the loop.
Reading the Go code, it is clear that some people are curious about the inline Walker functions (they are not necessarily inline, they are correct). Some people want to know about multiple assignments, like a, b = c, D, which is more confusing. Ironically, if I were new to the Go language, I would write more direct Go code.
C++
Although I had some experience with C, it was nowhere near modern C++, so I decided to give it a try. It took me about 20 minutes to finish, which was unexpected.
TLDR: Good old friend.
What I like: It feels familiar, like getting to know an old friend from the past. I like the documentation and it provides lots of examples and good readability. I was surprised to see how strong stdlib is today. Support in the text editor and IDE is also very solid.
What I don’t like: Poor tools – no build system, no test tools, no Linter. We used to use it, but it’s not what modern developers expect. Too powerful – C++ feels very productive for this task, but I can imagine myself in decision paralysis at a time when there are many different ways to do something and everything is the same (or bad).
People who read C++ code have actually read at least C or C++ in the past as part of their college courses. I guess a lot of people complain about using ::, so I should use namespaces correctly. Overall, since I have no “taste” in C++ code — I’m sure it could have been written more clearly, but I’ve also seen how it could have been written worse without noticing.
Other benchmark
All languages generate static executables of the same size (2 to 5MB). The smallest is Zig, the largest is Rust. When scanning the entire /usr/include file tree, their performance is almost identical. This is why I emphasize that technical features (primarily performance) are often less important than the developer experience.
I would also like to mention the build time. I ran the entire Build + test + clean loop a hundred times. Go is the fastest (as expected), the other three are llVM-based and are 3 to 4 times slower.
What does that mean? The results aren’t surprising, and there are often cliches about languages: Go is easy to read, Rust is complex, C++ is familiar, Zig looks promising, but too young to judge.
If I had to write a new service/utility that didn’t have a lot of interaction with C code — I would definitely Go. If I have to call some C or C++ library — unfortunately, I’ll stick with C++. Where Rust and Zig will fit into the modern programming world — only time will tell. I wish Zig had better documentation so it might catch on before it becomes too niche and inundated. I’ll definitely pay more attention to it, and so far this is the first real C alternative I’ve come across, especially when it comes to low-level coding.
Of course, despite the age, C still exists. In many places, C is the only practical option. I’m glad C is still young.
Original link: zserge.com/posts/bette…
**PS: In addition, for those who are learning programming or working, if you want to improve your programming ability or even change careers, you can overtake on the corner and take a step faster! The author here may be able to help you ~
C language C++ programming learning exchange circle, **QQ group [765803539] ** wechat public number: C language programming learning base
Share (source code, project actual combat video, project notes, basic introduction tutorial)
Welcome to change careers and learn programming partners, use more information to learn and grow faster than their own thinking oh!
