Nice and clear article. I like an idea of looking at quality of the process and not only the product. It was pleasant to read.<p>I didn't like that C itself was missing, because C is still my language of choice for some tasks and I still use it because I'm happy about it, I don't feel I would need any of its competitors. Maybe if this benchmark included C it would be some argument to give them a try. So I decided to do it for you.<p>It took me 30 minutes, only change is that I don't check if file is binary, I guess. I liked that I was doing it in C because I know it and I'm comfortable with it. Few checks in man and everything's clear. Only disadvantage of C is that it doesn't have standard API for directories, so my code is only for POSIX. Here's the code: <a href="https://github.com/BartekLew/dumbgrep" rel="nofollow">https://github.com/BartekLew/dumbgrep</a><p>The other thing are sources you've done. They are almost the same (it'd be nice to see the more feeling of the language, idiomatic code, etc.) and I didn't like reading them at all, not a clean code and all are longer than my C code.<p>Another thing is that C has very narrow application nowadays. A benchmark should be focussed on them and not on generic algorithms.
What I find funny is his choice of languages: 'hipe driven' I'd say.<p>If you can use a GCd language like Go why would you go with Rust(which add a lot of complexity) or Zig(which is unsafe(1)) instead of the numerous existing GCd languages D,Nim, Crystal, Java,... which provides memory safety without complexity<p>If you can't why evaluate Go instead of Ada or DasBetterC?<p>1: At work a frequent issue in C++ is UAF a pointer to a stack variable which outlives the function, Zig don't help you here..
I threw together a D Programming language glob-grep based off of the Zig version the author posted, if anyone is curious: <a href="https://gist.github.com/aruthane/005c6c48f0deb9c4bfc83bc75e0e95f7" rel="nofollow">https://gist.github.com/aruthane/005c6c48f0deb9c4bfc83bc75e0...</a>
50 years is not a good age for a bottle of wine. There are wines that are still enjoyable after such long time, but will hardly express the same potential they had at the peak of their maturity. Many other bottles will be already totally gone after 50 years.
A nit/bug re: the glob matching algorithm in use:<p>'?' evidently represents "any character" per the !glob("h?i", "hi") test.<p>But, if I add a test for glob("???", "hi"), that succeeds unexpectedly even though it should run out of input.<p>I believe it's because the '?' case checks nt < text.length() (which AIUI is for consuming variable input for '*') instead of t. Changing that case to t < text.length() seems to fix that problem.<p>(This looks like it's the case for all four languages, as the glob algorithm looks identical in all four, modulo syntax differences)
I think there is definitely merit in these kinds of posts.<p>This developers measure of productivity is "how low level can I go" clearly; they declared zig was clear despite saying this:<p>> The lack of string handling routines in the stdlib was unexpected, to concatenate strings one has to do everything manually - allocate the buffer, put strings there. Or use formatter and an allocator to print both strings side by side and free the buffer afterwards.<p>This combined with "strings" being byte buffers like in C are not a good thing. I had a quick look and the author appears to be german; how do you handle an umlaut in zig?<p>His dismissal of C++ as "not having a build system" seems like considering the language without the ecosystem. Using cmake and llvm solves all of his gripes on C++.<p>Finally, this post measures the productivity of a single developer, On a 1-3 file project. How these projects work with 2-5 developers, or on projects that support more than the anglosphere are very important.
Zig is promising. The UX problem that the author talks about will be solves by Zig.<p>About documentation, its still not 1.0, the language. So, its a work in progress.
> The lack of string handling routines in the stdlib was unexpected, to concatenate strings one has to do everything manually - allocate the buffer, put strings there<p>Not sure how long the author spent looking at zig stdlib, but there is std.mem.join for this. Most string utils are under std.mem, it seems. To be fair, I also rolled my own std.mem.eql for string comparison before stumbling upon it as a beginner, so this definitely an area for improvement.<p>Overall I agree with the assessment about stdlib docs. Many things are not even listed in docs, and many that are have little to no description. Also some of type signatures are not really clear, e.g. when they use `var` as a type.<p>What works for me is having stdlib docs and source code from github side by side and jumping back and forth between them.<p>But overall, as someone who's gone through a similar language evaluation process, his assessment feels pretty on point: zig's lack of maturity still shows in a lot of places, Rust feels complicated and puzzling at the beginning, etc. My only difference is I'd lean towards C if I had to pick between it and C++, but that's largely a matter of personal preferences IMHO.
The Rust code is very non-idiomatic, which is probably part of the reason why it seemed difficult to put together and why reading it is a bit of a chore. Compared to Zig or Go, naively translating C code into Rust isn't going to work nearly as well. This isn't necessarily because Rust is more complicated (although it definitely is) but has a lot to do with the fact that it's semantics are inspired almost as much by OCaml and Haskell as they are by C and C++. It's not surprising, then, that someone who is predominately a C programmer would need more than a couple hours to be able to really judge the difference between the languages.
Honestly Rust is pretty expressive. There's always some things that you are going to run into. But mostly Rust is a really nice language and environment to work in.
These comparison articles can be reduced into 3 types...<p>Write code:<p>1. In less time<p>2. That runs faster<p>3. That's less buggy<p>Pick one.<p>... this article advocates for (1).
>All had about the same performance when scanning through my whole /usr/include file tree. That’s why I wanted to highlight that technical characteristics are often not as important as the developer experience.<p>Strange conclusion considering their benchmark was I/O-bound by design
im worried about something managed to actually replace C, now every platform provides their lowest level sdk in C which is super nice, if you want to do cross platform native dev like games and ui, just using C can get you anywhere, i dont't want it to be like graphics where better tech came out but each vendor uses their own specs (OpenGL everywhere -> Vulkan / Metal / D3d / WebGPU) and makes it impossible to do actual cross-platform dev unless you can put up with some HAL bloat
I am really surprised that D's --betterC subset (or just D proper) wasn't even tested, considering that's exactly what it is called and would likely outrank a good bit of everything else on the list.
>They often complain the syntax is unclear and requires paying attention to details.<p>Attention to detail comes with the territory for programming roles. People who can't or don't want to pay attention to details are not fit to be programmers.
We are working with precise binary digital machines, FFS. I sometimes find this attitude among students of my training courses - the misconception "computer, do what I mean, not what I say". Obviously such students don't do well in my course or in their career.
> With no previous experience I opened vim and started coding.<p>That is where i stopped reading. If you're not using an IDE in 2021, you're not working on serious software/big codebases/commercial projects and what you have to say is not something I'm interested in, ESPECIALLY when talking about UX of programming! VIM, oh please... time to have a nap, grandpa.