15 ms·

A “Better C” Benchmark

183 points by bshanks 6y ago

deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
renox 6y ago
What I find funny is his choice of languages: 'hipe driven' I'd say. 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 If you can't why evaluate Go instead of Ada or DasBetterC? 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..
- banachtarski 6y ago
  > 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.. Sorry but if this sort of UAF is actually frequent, I would hazard a guess that your coworkers would struggle in pretty much any language? RAII-based lifetime management really isn't that difficult, and the type of bug you are referring to isn't even subtle.
  - jchw 6y ago
    I dunno what you’re saying; this kind of bug also proves difficult to avoid in large, security-critical projects like web browser engines.
    - WalterBright 6y ago
      D is very good at detecting dangling pointers into the stack at compile time.
    - saagarjha 6y ago
      Usually I think tooling is fairly good at catching these; I feel like misuse of dynamic memory allocation is usually harder to catch these days.
      - pjmlp 6y ago
        Provided developers actually bother to use it. Most surveys place the use of such tooling around 11%, which is why all major OS vendors are pushing for hardware memory tagging, as by then is no way to avoid using them.
        saagarjha 6y ago
        All three of the web browser engines are extremely heavy users of these tools; actually they are often the ones that develop and contribute to them.
        pjmlp 6y ago
        A negligible amount of source code when placed against the amount of C , C++ and Objective-C written daily across the globe. Those browsers are part of the 11% mentioned above.
    - malf 6y ago
      They’re talking specifically of pointers to the stack.
  - renox 6y ago
    >I would hazard a guess that your coworkers would struggle in pretty much any language? Uh? This issue wouldn't happen in Java because everything is heap(GC) allocated. Which is probably why developers new to C++ have this issue. Walter Bright said below that the D compiler find most of these issue at compile time, well that's nice for D but unfortunately that isn't the case for C++ at least not for gcc9.
    - WalterBright 6y ago
      Doing what D does to detect references to expired stack frames would require some restructuring of C++'s semantics, which seems unlikely. For example, D can detect this error: @safe: int* f(int* p) { return p; } int* g() { int i; return f(&i); } Compile with: dmd test -dip1000 and the result: Error: reference to local variable i assigned to non-scope parameter p calling test.f
      - scatters 6y ago
        At -O2 or above, gcc emits Wreturn-local-addr.
        mlyle 6y ago
        Within a single compilation unit, and only in this most trivial case.
        WalterBright 6y ago
        Here's an example of a much more complex case that is detected: https://issues.dlang.org/show_bug.cgi?id=21745 https://issues.dlang.org/show_bug.cgi?id=21745
        mlyle 6y ago
        Yes, sorry if my comment isn't clear. D is very capable in this regard. While gcc with C/C++ code will spot a few trivial cases... including the one in the example above.
  - viraptor 6y ago
    If you can make some mistake, it's only a matter of time until someone will make it. This scales with the codebase size. And you only need one person to make the mistake and another to miss it in review - it doesn't matter if everyone else is a 40 years of experience coder.
    - alfiedotwtf 6y ago
      "Nobody would write that type of code, and if they did, you should just get better programmers" is such a common theme in these discussions. ... yet every time time I've been told "you don't need Rust, just use C++", I can point to at least one UAF in their own code, and have even pointed to CVEs on Mitre for their own projects! People make mistakes. Use tools that stop these mistakes, rather than helping you to "write code faster" like in the article (aka writing bugs faster).
      - bluejekyll 6y ago
        “If debugging is the process of removing bugs, then programming must be the process of putting them in.” -- Dykstra's Observation
  - vitus 6y ago
    I disagree, as there are lots of ways it can manifest in C++. To list a few examples: - Implicit lambda capture where you use & (admittedly often out of laziness). - A string_view constructed from an accidental string copy (e.g. if your function parameter is a const std::string instead of a const std::string&, or if you write for (auto foo : v) { ... }). - A callback that references some member variables of some object on the stack, which usually completes before the function returns (but maybe you forget to synchronize in an edge case). Tooling can help identify a number of these issues, but it's not perfect. And a number of these issues are very much C++-specific.
  - CyberDildonics 6y ago
    I agree and don't understand why this would be controversial. There are plenty of aspects of programming that need systematic solutions instead of just telling people to get better, but returning pointers to the stack should not be high on that list. If people are doing that, it means they don't understand what they are doing or aren't thinking about what they are writing, probably both. It is much easier to return regular data structures. In modern C++ it is rare that a raw pointer should be returned in the first place. I wouldn't be sure what to think if I had a team full of people consistently and frequently returning pointers to the stack frame of the function they came from.
    - renox 6y ago
      It doesn’t happen very often but each time there was a new developer on the team they made such mistake, that’s a way to teach them about valgrind (what a wonderful software!) I guess. We work in a ‘low latency’ domain where heap allocation is avoided, this may explain that it happens more often to us.
      - CyberDildonics 6y ago
        Why would avoiding heap allocation explain it? Why is anyone getting the address of a stack allocated variable in the first place since it already in scope? What are people returning pointers from functions at all?
- makapuf 6y ago
  Had to look it up, DasBetterC is not german, it's "D as a better C"
  - ruph123 6y ago
    Lol thank you for that. I thought that was a joke language like Enterprise.
  - WalterBright 6y ago
    I originally wrote a slide titled "D as Better C", and since I was in München at the time, it suddenly morphed into "Das Better C" and so the pun was born. In my head it is always said with a German accent.
    - ksec 6y ago
      If I was the marketing manager of D I would turned this "pun" into Super Hype. And yes this got me interested in D. I always knew of its existence but for some reason I never really looked into it.
      - throwaway316943 6y ago
        Try it out, I’m thoroughly enjoying learning it at the moment and it really does feel like “better C”. The only thing I dislike is that the official docs are so thorough that they’re not very approachable to a novice (but much appreciated once you grok D’s features). I’ve found this book to be a better programmer’s introduction with lots of useful examples https://www.packtpub.com/product/d-cookbook/9781783287215 https://www.packtpub.com/product/d-cookbook/9781783287215
  - qart 6y ago
    In German, it would have been besser, not better.
    - acka 6y ago
      It wasn't aiming for correct spelling, nor correct grammar for that matter. Rather, I think one can compare it to something like "Das Keyboard"[0]. [0] https://en.wikipedia.org/wiki/Das_Keyboard https://en.wikipedia.org/wiki/Das_Keyboard
- jraph 6y ago
  > If you can use a GCd language like Go why would you go with Rust Memory leaks are possible in GCd languages and when they happens, sometimes you cannot fix them easily / properly because of architectural problems. Thinking about the lifetime of an object can help with this. We also still miss something in many languages that specifies whether we can modify or access an object after passing it as a argument to a call, which can can problems not related to memory safety. (I've played with Rust but I don't practice it daily. I've also played with D but don't practice anymore. I don't know Go.)
  - a3n 6y ago
    Is there a nice idiom name that represents ensuring that an object gets "released" and eligible for garbage collection?
    - CraigJPerry 6y ago
      Memory leaks in Java are usually not so bad to fix. Maybe some off-heap scenarios could be trickier but IME people are pretty careful if they’re going to the extremes of off-heap. Memory leaks in enterprise java in my experience are usually things like forgetting to close a resource of some sort or maybe doing something silly like continually growing a set or map with duplicate objects because of faulty equals() or hashCode(). Both of these cases are well covered by static analysis. Maybe the trickiest but still relatively common scenario is a design issue where a weak reference is required - i guess that fits parent description pretty well.
    - varjag 6y ago
      resource management
  - deleted 6y ago
    [deleted]
- IshKebab 6y ago
  Because you're ignoring a lot of other reasons to use Go or Rust. Go is simple, has very fast compile times, produces a single static binary, easy trivial to cross-compile, has very short GC pauses, has a fantastic standard library. The same cannot be said for those other languages. Rust has a very strong type system that makes lots of runtime errors into compile time errors, it's basically as fast a language as you can get, except for GUIs it has a really good library ecosystem (way better than all the languages you mentioned except maybe Java), it produces a static binary, cross-compilation is relatively easy (as long as you aren't trying to cross compile to Mac).
- drran 6y ago
  I have here program in Go and in Rust. They are very similar (Rust program is shorter), but Rust version is 5x faster than Go version.
  - simpleguitar 6y ago
    I bet you are allocating/deallocating something in a loop. Give the Go profiler a whirl. I bet it will be pretty easy to remove, too. I have not run into a case where go can't be within 2x speed of C. And I love how zig is even closer to C, but has the ergonomics of go. What an amazing time to be alive.
    - axaxs 6y ago
      That's what I was thinking. When I was learning Go years ago, I decided to go through and speed up some of the Benchmark Game's Go code. Some were on the order of 20x speedup if I remember right. Of course, the maintainer of the site rejected it because of what I perceive as a clear bias against the language, but the point is...it's easy to fix hotspots in Go.
      - drran 6y ago
        My contributions to Benchmark Game for Rust are accepted. ;-)
      - gher-shyu3i 6y ago
        Can you link to the bitbucket pull requests?
        axaxs 6y ago
        Which repo? If it has a full history, perhaps I could find it? I have a link, but it's dead now... http://benchmarksgame.alioth.debian.org/u32/program.php?test=binarytrees&lang=go&id=6 http://benchmarksgame.alioth.debian.org/u32/program.php?test... This was in 2013. My first submission was using memory pools for binary trees. It was rejected for using memory pools, even though the C version quite literally used mempool. I even redid it to use a 'third party' mempool library, rejected for the same reason. I didn't even bother submitting any others.
- cb321 6y ago
  An attempt in Nim [1]. Something like 7 minutes, but yeah..this is even more crazy dependent upon dev familiarity with the target language/stdlib and their IDE/editor (aka unscientific) than the usual attempted measurements. [1] https://lobste.rs/s/ndxi2r/better_c_benchmark#c_m9toap https://lobste.rs/s/ndxi2r/better_c_benchmark#c_m9toap
- bluecalm 6y ago
  GCed language style just seem so messy to me. I like manual memory management. It forces you to think about lifetimes and encourages better design. Does an object persist or is it temporary? Maybe it's a good idea to have well defined state. GC languages encourage lousy thinking and design. GC pauses are still a thing as well.
  - gameswithgo 6y ago
    There are a lot of sweeping unsubstantiated assertions here, and unclearly defined ideas. What is lousy thinking and design? What are the practical downsides of it in the program? Given how many exploits are caused by memory mistakes in C and C++, maybe using those is actually the lousy thinking?
    - stiray 6y ago
      This is irrelevant, if you give F1 racing car to an enthusiastic casual driver, you will get a wracked car and few dead in matter of hours. And should I remember you how many exploits we had due to simple sql injection? The last buffer overrun, stack overflow, that I did was like 5 years back and wasn't remotely exploitable. But I agree that not making stupid mistakes takes years to master (in my case 20+). The problem is not in exploits, the problem is in price of people having enough knowledge to not do stupid mistakes and every company wants developer that pays him nothing (or as little as possible) and gets everything or close to it (open source(tm); I want to build a house. I am still searching for an idiot that would make it for "recognition"). And as such they search for most fool proof technology where they could replace expensive and knowledgeable developers with, ideally, street bums that would work for food. And most of the software we are using today is like that: made from street bums. The difference between 1990s software and today is too obvious to not notice the difference, even the "great breakthroughs" and new hypes are just xeroxing what we already had.
      - varjag 6y ago
        Formula 1 is on the bleeding edge of technology, which C is resolutely not. If you're really into car analogies a better one would be racing a Ford T, which is indeed just as unsafe. (No offense, doing a fair bit of C work myself)
- gameswithgo 6y ago
  The whole point of his experiment was to learn about the ergonomics of these languages, to investigate the hype. If you did the experiment and say, found that Rust was super easy, then you could avoid GC and get some free efficiency. If you found that Rust was hard, then you know only to use it when you NEED the efficiency.
- lhorie 6y ago
  I'm not the OP, but could try to venture an answer as someone who's used some of those languages. D is nice. I could see myself picking it instead of go. It's much more expressive than go and it's mature enough. Cross compilation story isn't as great though. Haven't tried asBetterC. I was under the impression this corner of D isn't as mature as D proper. Java, IMHO, has limited uses, in the sense that making distributable binaries for client side usage (e.g. CLIs) is quite a hassle, and the need for a JRE makes it quite a bit bulkier than a C or go thing. I'm partial to Nim and Crystal (and V). They aren't as appealing to me personally because they feel complex compared to C and go (and zig). If the appeal of these languages is "a better golang", I think D has beat them to the punch. Also, again, cross compilation tends to be a bit of a deal breaker for me. Another language that seem interesting in this space is Odin, but I could not for the life of me find stdlib docs for it. Another seemingly interesting language is Beef, which has a sort of C# feel (a good thing in my books), but unfortunately I haven't had a chance to play around with it yet. Cosmopolitan is cool, but is just C, and younger than even zig.
- dnautics 6y ago
  I belive the "no outlasting pointers to stack variables" is a very hard problem but it is in the Zig issues list and it will probably be worked on: https://github.com/ziglang/zig/issues/5725 https://github.com/ziglang/zig/issues/5725
- audunw 6y ago
  It's a bit early to say what Zig does and doesn't do. Memory safety aspects is still under development, and there seems to be a lot of focus on making it safer. But it might be a model where you focus on detecting errors in debug/safe-builds during development, but release fast builds using less safe code generation and allocators. Zig will probably never be as safe as a GCed language or Rust in this regard. But that's because it would go against other core design goals. I feel like the future of non-GC languages is Zig as better C (dead simple and explicit language), and Rust as better C++ (complex language with more memory management facilities, etc). The choice of languages was a bit odd. But I think Go is still in C's territory when it comes to being simple and explicit. Memory management (GC/not-GC) isn't necessarily the most important distinction in programming languages.
  - tialaramex 6y ago
    What would "simple and explicit" even mean if somehow it includes "Oh, sometimes, maybe, I'll incur the expense of garbage collection in the middle of this other algorithm running and it'll take much longer than usual" ? I don't care about that in a Python program, but I can't see why I would accept it from something that's supposed to replace C. I also think you're imagining a lot of hard work during execution in Rust that just isn't there, most of the tricky stuff happens at compile time. If you can prove you really don't need the safety that does have runtime implications, you can choose not to have it, but of course you probably don't have proof, just the same gut instinct that usually gets us into trouble in other languages.
marvel_boy 6y ago
Simplicity wins. Always.
- m12k 6y ago
  Yes, the trouble is agreeing on a definition of "simple"
  - jackosdev 6y ago
    My boss defines it as a microservice for every method
    - logicchains 6y ago
      That sounds incredibly complex and hard to maintain. What you need is a Docker container for every method, for isolation, then just use K8s to orchestrate them and YAML for control flow.
      - barbarbar 6y ago
        This is an excellent advice. Maybe double docker for every method?
      - MaxBarraclough 6y ago
        Raw Kubernetes, rather than Helm?
- chousuke 6y ago
  I dunno. One could say that C string handling is "simple" (it's just byte buffers!) or that manual loops are "simpler" than proper iterator abstractions, but those are both constructs that are hideously error-prone in practice. Perhaps it's the other way around and manual buffer management is actually the complex thing, since your application logic will have to involve a lot of code doing toil that isn't directly related to what you want to accomplish. EDIT: To expand a bit, I'm a huge proponent of simplicity; I think overabstraction is a massive problem with software nowadays. However, my thinking is that the problem isn't so much with the abstractions themselves, but that they aren't transparent. ORMs are a frequent offender here: a good abstraction wouldn't allow you to perform a thousand database queries by accident just by looping over a list. You could still model a list of database-backed persistent objects as a list, but any operation that hits the database should be an explicit fetch, not an implicit one.
chhs 6y ago
I threw together a D Programming language glob-grep based off of the Zig version the author posted, if anyone is curious: https://gist.github.com/aruthane/005c6c48f0deb9c4bfc83bc75e0e95f7 https://gist.github.com/aruthane/005c6c48f0deb9c4bfc83bc75e0...
- perennus 6y ago
  This is the most readable version for me. I like C++ also but I find the namespace clutter annoying.
  - CyberDildonics 6y ago
    There is no reason there has to be namespace clutter in C++
- drannex 6y ago
  Great work! Really hope the author decides to run and see the performance in comparison.
lew89 6y ago
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. 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. 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: https://github.com/BartekLew/dumbgrep https://github.com/BartekLew/dumbgrep 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. Another thing is that C has very narrow application nowadays. A benchmark should be focussed on them and not on generic algorithms.
- david_for_you 6y ago
  This seems to be missing a return in the NULL check for handle in the match_file function. This leads to fgets being called with a NULL pointer, which I don't know what it does, it may be OK. I would argue that this is why a "better C" can be useful, it's the kind of error that would be much harder to make in rust.
  - lew89 6y ago
    There is missing NULL check, but it doesn't crash, because the function would get nonexistent filename only if filesystem driver would do something strange (or file would be deleted just between readdir and fopen). xD I also noticed, that I don't close files and directories. Not a big deal, because fully functional and 100% correct program wasn't the goal here. :) EDIT: Actually fopen would return NULL when file is not readable. My bad. Anyway, such problems are trivial to debug.
    - carols10cents 6y ago
antirez 6y ago
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.
- tutfbhuf 6y ago
  How about 50 years old whiskey in a cask?
  - DennisP 6y ago
    Difficult to keep it from just being super oaky at that age, but a great distiller willing to throw away a lot of bad casks can make something amazing. Macallan sold some 72 year old scotch in 2018: https://www.foodandwine.com/news/macallan-scotch-72-year-old-lalique-genesis-decanter https://www.foodandwine.com/news/macallan-scotch-72-year-old...
    - stock_toaster 6y ago
      Or just use very tired casks for most of that 50 years.
- ginko 6y ago
  A sauternes or tokaji is just about in its prime at that age.
  - antirez 6y ago
    Both are special wines, indeed.
notorandit 6y ago
C is not C++! Where is the implementation in C? Boob!
- deleted 6y ago
  [deleted]
himujjal 6y ago
Zig is promising. The UX problem that the author talks about will be solves by Zig. About documentation, its still not 1.0, the language. So, its a work in progress.
- tails4e 6y ago
  I'm curious about this. It seemed to be alot of 'work' just to get arguments. While I could read the code with no prior experience, there were enough unexpectedly verbos things in there that suggested it could take a considerable time to learn
  - himujjal 6y ago
    No task is too easy. For easy, we need to jump down to Python. Even C is too easy to learn but difficult to write. Zig is kind of in between Go and Rust in terms of the learning curve. In terms of programming, it is in between C and Rust. But it is simple enough. The documentation as I said for the stdlib isnt that great right now as I said.
    - dnautics 6y ago
      While I agree that Zig is in between Go and Rust, you're gonna find a lot of crazy stuff that will tie your brain in knots with Go. A few examples: - Json parsing being special cased into the language - multiplying a user-input integer with a time value to be a timeout - channels and goroutines (sorry, I've been spoiled by erlang) Aside from things that are actually bugs, I haven't found anything like this in Zig. On the contrary, I typically have found something that doesn't work how I expect, and then I think about it, and it's "of course it's like this, why isn't C like this??".
    - tails4e 6y ago
      I found the cxx example very easy to read, which surprised me, it was not thst verbose. The D example another poster has in this thread was the easiest and cleanest IMHO.
  - lhorie 6y ago
justAnIdea 6y ago
> With no previous experience I opened vim and started coding. 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.
- Flex247A 6y ago
  System.gc()
- linkdd 6y ago
  Obviously, you never spent a minute trying to configure Vim. Vim is a fully featured IDE, learning to use it efficiently can greatly increase your productivity, and most important: it's also fun. > VIM, oh please... time to have a nap, grandpa. Such disrespect, all that's missing from your snarky comment is "ok boomer"...
- mrwoggle 6y ago
  People of all ages use VIM!
- Zardoz84 6y ago
  I work on some serious commercial big and old code base using Eclipse and NeoVim every time that I touch XML, SCSS or JavaScript files. Correctly configurators, VIM/NeoVIM it's better IDE for CSS/SCSS and JavaScript that Eclipse
- Ma8ee 6y ago
  You need to learn how to code without crutches. IDEs are great, and people should definitely use them, but I’ve met too many programmers who just are lost without them. The worst example was a guy who couldn’t even navigate his own small program except with the debugger. Even though he wrote this small program himself, he didn’t managed to have a mental image of the call stack. So, some of you who rely on the IDE all the time maybe need to do without it a little to train some muscles that have atrophied.
- dang 6y ago
maccard 6y ago
I think there is definitely merit in these kinds of posts. This developers measure of productivity is "how low level can I go" clearly; they declared zig was clear despite saying this: > 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. 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? 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++. 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.
- mhh__ 6y ago
  > using cake and LLVM Sure they (not sure about LLVM as a build system?) work but they really aren't all that great in my experience.
  - maccard 6y ago
    I've had excellent experience with cmake over the last 10 years. It's no cargo, that's for sure, but it gives you a crossplatform cross toolchain extensible reliable build system Llvm was specifically in reference to the "tooling" comment in the blog post. Clang format and clang-tidy(which conveniently has a neat integration with cmake!)
  - mhh__ 6y ago
    How did I not notice it corrected cmake to cake...
- linkdd 6y ago
  CMake, SCons, Autotools, Meson, Premake, to quote only them. They are build systems alright, but they miss the most crucial point: dependency managment. On the other side we have: - cargo for Rust - buck and buckaroo for C++ which seems nowhere near complete Am I missing something?
Zardoz84 6y ago
Seeing the title, I expected an article benchmarking DLang "Better C". Instead, the author even don't mentioned anything about DLang...
- drannex 6y ago
  You aren't alone there
vitus 6y ago
A nit/bug re: the glob matching algorithm in use: '?' evidently represents "any character" per the !glob("h?i", "hi") test. But, if I add a test for glob("???", "hi"), that succeeds unexpectedly even though it should run out of input. 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. (This looks like it's the case for all four languages, as the glob algorithm looks identical in all four, modulo syntax differences)
alfiedotwtf 6y ago
These comparison articles can be reduced into 3 types... Write code: 1. In less time 2. That runs faster 3. That's less buggy Pick one. ... this article advocates for (1).
kgeist 6y ago
>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. Strange conclusion considering their benchmark was I/O-bound by design
lerno 6y ago
Would have liked comparisons with Nim, Crystal, Odin, D.
maxpert 6y ago
Heeyyyyy! Where is my Nim and Crystal? If you think GC based languages are acceptable I highly highly encourage Crystal.
systemBuilder 6y ago
--- comment removed ---
- hu3 6y ago
  Have you never written a bug in your life? Should we not believe your conclusions too? > His pretty buggy code infinite loops if pattern == "". Does anyone truly believe his conclusions, if he evaluates programming languags according to how well they execute buggy code? -systemBuilder
lhorie 6y ago
> 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 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. 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. What works for me is having stdlib docs and source code from github side by side and jumping back and forth between them. 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.
kidfrommars 6y ago
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.
- edflsafoiewq 6y ago
  The Rust looks fine to me.
  - seoaeu 6y ago
    Nothing looks necessarily wrong to me but there are some elements that aren't exactly how this code would normally be written. Like that they don't take advantage of Iterator::enumerate() which makes the the for loop more awkward than necessary. Or how strings are treated as arrays of bytes (rather than sequences of unicode characters as the language pressures you to).
    - steveklabnik 6y ago
      Yeah. This code isn’t bad, but it’s not what I’d write. The largest difference is that, if given this problem, I would start with walkdir (and maybe glob), rather than trying to write all of this myself. Not to mention Cargo instead of a Makefile. The loops also feel very C-like, but that might still be the best you can do. I'd have to actually give it a try, but I feel like iterators could clean this up, as you say. To reiterate: that doesn’t mean this is bad or wrong. It might be a bit harder or more complex than it has to be. But also, you have to know that these things exist in the first place, which is it’s own challenge. EDIT: Oh look, someone on lobsters thought the same: https://lobste.rs/s/ndxi2r/better_c_benchmark#c_k2kwjs https://lobste.rs/s/ndxi2r/better_c_benchmark#c_k2kwjs https://github.com/jswrenn/treescan/blob/main/src/main.rs https://github.com/jswrenn/treescan/blob/main/src/main.rs
bfrog 6y ago
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.
fithisux 6y ago
A benchmark with "better c" mode of Dlang would be amazing.
slmjkdbtl 6y ago
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
vram22 6y ago
>They often complain the syntax is unclear and requires paying attention to details. 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.
drannex 6y ago
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.
arunc 6y ago
Wondering why D was not considered. D is probably the better C I've come across.

183 points by bshanks 6y ago

deleted 6y ago

[deleted]

deleted 6y ago

[deleted]

renox 6y ago

What I find funny is his choice of languages: 'hipe driven' I'd say. 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 If you can't why evaluate Go instead of Ada or DasBetterC? 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..

banachtarski 6y ago
> 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.. Sorry but if this sort of UAF is actually frequent, I would hazard a guess that your coworkers would struggle in pretty much any language? RAII-based lifetime management really isn't that difficult, and the type of bug you are referring to isn't even subtle.
- jchw 6y ago
  I dunno what you’re saying; this kind of bug also proves difficult to avoid in large, security-critical projects like web browser engines.
  - WalterBright 6y ago
    D is very good at detecting dangling pointers into the stack at compile time.
  - saagarjha 6y ago
    Usually I think tooling is fairly good at catching these; I feel like misuse of dynamic memory allocation is usually harder to catch these days.
    - pjmlp 6y ago
      Provided developers actually bother to use it. Most surveys place the use of such tooling around 11%, which is why all major OS vendors are pushing for hardware memory tagging, as by then is no way to avoid using them.
      - saagarjha 6y ago
        All three of the web browser engines are extremely heavy users of these tools; actually they are often the ones that develop and contribute to them.
        pjmlp 6y ago
        A negligible amount of source code when placed against the amount of C , C++ and Objective-C written daily across the globe. Those browsers are part of the 11% mentioned above.
  - malf 6y ago
    They’re talking specifically of pointers to the stack.
- renox 6y ago
  >I would hazard a guess that your coworkers would struggle in pretty much any language? Uh? This issue wouldn't happen in Java because everything is heap(GC) allocated. Which is probably why developers new to C++ have this issue. Walter Bright said below that the D compiler find most of these issue at compile time, well that's nice for D but unfortunately that isn't the case for C++ at least not for gcc9.
  - WalterBright 6y ago
    Doing what D does to detect references to expired stack frames would require some restructuring of C++'s semantics, which seems unlikely. For example, D can detect this error: @safe: int* f(int* p) { return p; } int* g() { int i; return f(&i); } Compile with: dmd test -dip1000 and the result: Error: reference to local variable i assigned to non-scope parameter p calling test.f
    - scatters 6y ago
      At -O2 or above, gcc emits Wreturn-local-addr.
      - mlyle 6y ago
        Within a single compilation unit, and only in this most trivial case.
        WalterBright 6y ago
        Here's an example of a much more complex case that is detected: https://issues.dlang.org/show_bug.cgi?id=21745 https://issues.dlang.org/show_bug.cgi?id=21745
        mlyle 6y ago
        Yes, sorry if my comment isn't clear. D is very capable in this regard. While gcc with C/C++ code will spot a few trivial cases... including the one in the example above.
- viraptor 6y ago
  If you can make some mistake, it's only a matter of time until someone will make it. This scales with the codebase size. And you only need one person to make the mistake and another to miss it in review - it doesn't matter if everyone else is a 40 years of experience coder.
  - alfiedotwtf 6y ago
    "Nobody would write that type of code, and if they did, you should just get better programmers" is such a common theme in these discussions. ... yet every time time I've been told "you don't need Rust, just use C++", I can point to at least one UAF in their own code, and have even pointed to CVEs on Mitre for their own projects! People make mistakes. Use tools that stop these mistakes, rather than helping you to "write code faster" like in the article (aka writing bugs faster).
    - bluejekyll 6y ago
      “If debugging is the process of removing bugs, then programming must be the process of putting them in.” -- Dykstra's Observation
- vitus 6y ago
  I disagree, as there are lots of ways it can manifest in C++. To list a few examples: - Implicit lambda capture where you use & (admittedly often out of laziness). - A string_view constructed from an accidental string copy (e.g. if your function parameter is a const std::string instead of a const std::string&, or if you write for (auto foo : v) { ... }). - A callback that references some member variables of some object on the stack, which usually completes before the function returns (but maybe you forget to synchronize in an edge case). Tooling can help identify a number of these issues, but it's not perfect. And a number of these issues are very much C++-specific.
- CyberDildonics 6y ago
  I agree and don't understand why this would be controversial. There are plenty of aspects of programming that need systematic solutions instead of just telling people to get better, but returning pointers to the stack should not be high on that list. If people are doing that, it means they don't understand what they are doing or aren't thinking about what they are writing, probably both. It is much easier to return regular data structures. In modern C++ it is rare that a raw pointer should be returned in the first place. I wouldn't be sure what to think if I had a team full of people consistently and frequently returning pointers to the stack frame of the function they came from.
  - renox 6y ago
    It doesn’t happen very often but each time there was a new developer on the team they made such mistake, that’s a way to teach them about valgrind (what a wonderful software!) I guess. We work in a ‘low latency’ domain where heap allocation is avoided, this may explain that it happens more often to us.
    - CyberDildonics 6y ago
      Why would avoiding heap allocation explain it? Why is anyone getting the address of a stack allocated variable in the first place since it already in scope? What are people returning pointers from functions at all?
makapuf 6y ago
Had to look it up, DasBetterC is not german, it's "D as a better C"
- ruph123 6y ago
  Lol thank you for that. I thought that was a joke language like Enterprise.
- WalterBright 6y ago
  I originally wrote a slide titled "D as Better C", and since I was in München at the time, it suddenly morphed into "Das Better C" and so the pun was born. In my head it is always said with a German accent.
  - ksec 6y ago
    If I was the marketing manager of D I would turned this "pun" into Super Hype. And yes this got me interested in D. I always knew of its existence but for some reason I never really looked into it.
    - throwaway316943 6y ago
      Try it out, I’m thoroughly enjoying learning it at the moment and it really does feel like “better C”. The only thing I dislike is that the official docs are so thorough that they’re not very approachable to a novice (but much appreciated once you grok D’s features). I’ve found this book to be a better programmer’s introduction with lots of useful examples https://www.packtpub.com/product/d-cookbook/9781783287215 https://www.packtpub.com/product/d-cookbook/9781783287215
- qart 6y ago
  In German, it would have been besser, not better.
  - acka 6y ago
    It wasn't aiming for correct spelling, nor correct grammar for that matter. Rather, I think one can compare it to something like "Das Keyboard"[0]. [0] https://en.wikipedia.org/wiki/Das_Keyboard https://en.wikipedia.org/wiki/Das_Keyboard
jraph 6y ago
> If you can use a GCd language like Go why would you go with Rust Memory leaks are possible in GCd languages and when they happens, sometimes you cannot fix them easily / properly because of architectural problems. Thinking about the lifetime of an object can help with this. We also still miss something in many languages that specifies whether we can modify or access an object after passing it as a argument to a call, which can can problems not related to memory safety. (I've played with Rust but I don't practice it daily. I've also played with D but don't practice anymore. I don't know Go.)
- a3n 6y ago
  Is there a nice idiom name that represents ensuring that an object gets "released" and eligible for garbage collection?
  - CraigJPerry 6y ago
    Memory leaks in Java are usually not so bad to fix. Maybe some off-heap scenarios could be trickier but IME people are pretty careful if they’re going to the extremes of off-heap. Memory leaks in enterprise java in my experience are usually things like forgetting to close a resource of some sort or maybe doing something silly like continually growing a set or map with duplicate objects because of faulty equals() or hashCode(). Both of these cases are well covered by static analysis. Maybe the trickiest but still relatively common scenario is a design issue where a weak reference is required - i guess that fits parent description pretty well.
  - varjag 6y ago
    resource management
- deleted 6y ago
  [deleted]
IshKebab 6y ago
Because you're ignoring a lot of other reasons to use Go or Rust. Go is simple, has very fast compile times, produces a single static binary, easy trivial to cross-compile, has very short GC pauses, has a fantastic standard library. The same cannot be said for those other languages. Rust has a very strong type system that makes lots of runtime errors into compile time errors, it's basically as fast a language as you can get, except for GUIs it has a really good library ecosystem (way better than all the languages you mentioned except maybe Java), it produces a static binary, cross-compilation is relatively easy (as long as you aren't trying to cross compile to Mac).
drran 6y ago
I have here program in Go and in Rust. They are very similar (Rust program is shorter), but Rust version is 5x faster than Go version.
- simpleguitar 6y ago
  I bet you are allocating/deallocating something in a loop. Give the Go profiler a whirl. I bet it will be pretty easy to remove, too. I have not run into a case where go can't be within 2x speed of C. And I love how zig is even closer to C, but has the ergonomics of go. What an amazing time to be alive.
  - axaxs 6y ago
    That's what I was thinking. When I was learning Go years ago, I decided to go through and speed up some of the Benchmark Game's Go code. Some were on the order of 20x speedup if I remember right. Of course, the maintainer of the site rejected it because of what I perceive as a clear bias against the language, but the point is...it's easy to fix hotspots in Go.
    - drran 6y ago
      My contributions to Benchmark Game for Rust are accepted. ;-)
    - gher-shyu3i 6y ago
      Can you link to the bitbucket pull requests?
      - axaxs 6y ago
        Which repo? If it has a full history, perhaps I could find it? I have a link, but it's dead now... http://benchmarksgame.alioth.debian.org/u32/program.php?test=binarytrees&lang=go&id=6 http://benchmarksgame.alioth.debian.org/u32/program.php?test... This was in 2013. My first submission was using memory pools for binary trees. It was rejected for using memory pools, even though the C version quite literally used mempool. I even redid it to use a 'third party' mempool library, rejected for the same reason. I didn't even bother submitting any others.
cb321 6y ago
An attempt in Nim [1]. Something like 7 minutes, but yeah..this is even more crazy dependent upon dev familiarity with the target language/stdlib and their IDE/editor (aka unscientific) than the usual attempted measurements. [1] https://lobste.rs/s/ndxi2r/better_c_benchmark#c_m9toap https://lobste.rs/s/ndxi2r/better_c_benchmark#c_m9toap
bluecalm 6y ago
GCed language style just seem so messy to me. I like manual memory management. It forces you to think about lifetimes and encourages better design. Does an object persist or is it temporary? Maybe it's a good idea to have well defined state. GC languages encourage lousy thinking and design. GC pauses are still a thing as well.
- gameswithgo 6y ago
  There are a lot of sweeping unsubstantiated assertions here, and unclearly defined ideas. What is lousy thinking and design? What are the practical downsides of it in the program? Given how many exploits are caused by memory mistakes in C and C++, maybe using those is actually the lousy thinking?
  - stiray 6y ago
    This is irrelevant, if you give F1 racing car to an enthusiastic casual driver, you will get a wracked car and few dead in matter of hours. And should I remember you how many exploits we had due to simple sql injection? The last buffer overrun, stack overflow, that I did was like 5 years back and wasn't remotely exploitable. But I agree that not making stupid mistakes takes years to master (in my case 20+). The problem is not in exploits, the problem is in price of people having enough knowledge to not do stupid mistakes and every company wants developer that pays him nothing (or as little as possible) and gets everything or close to it (open source(tm); I want to build a house. I am still searching for an idiot that would make it for "recognition"). And as such they search for most fool proof technology where they could replace expensive and knowledgeable developers with, ideally, street bums that would work for food. And most of the software we are using today is like that: made from street bums. The difference between 1990s software and today is too obvious to not notice the difference, even the "great breakthroughs" and new hypes are just xeroxing what we already had.
    - varjag 6y ago
      Formula 1 is on the bleeding edge of technology, which C is resolutely not. If you're really into car analogies a better one would be racing a Ford T, which is indeed just as unsafe. (No offense, doing a fair bit of C work myself)
gameswithgo 6y ago
The whole point of his experiment was to learn about the ergonomics of these languages, to investigate the hype. If you did the experiment and say, found that Rust was super easy, then you could avoid GC and get some free efficiency. If you found that Rust was hard, then you know only to use it when you NEED the efficiency.
lhorie 6y ago
I'm not the OP, but could try to venture an answer as someone who's used some of those languages. D is nice. I could see myself picking it instead of go. It's much more expressive than go and it's mature enough. Cross compilation story isn't as great though. Haven't tried asBetterC. I was under the impression this corner of D isn't as mature as D proper. Java, IMHO, has limited uses, in the sense that making distributable binaries for client side usage (e.g. CLIs) is quite a hassle, and the need for a JRE makes it quite a bit bulkier than a C or go thing. I'm partial to Nim and Crystal (and V). They aren't as appealing to me personally because they feel complex compared to C and go (and zig). If the appeal of these languages is "a better golang", I think D has beat them to the punch. Also, again, cross compilation tends to be a bit of a deal breaker for me. Another language that seem interesting in this space is Odin, but I could not for the life of me find stdlib docs for it. Another seemingly interesting language is Beef, which has a sort of C# feel (a good thing in my books), but unfortunately I haven't had a chance to play around with it yet. Cosmopolitan is cool, but is just C, and younger than even zig.
dnautics 6y ago
I belive the "no outlasting pointers to stack variables" is a very hard problem but it is in the Zig issues list and it will probably be worked on: https://github.com/ziglang/zig/issues/5725 https://github.com/ziglang/zig/issues/5725
audunw 6y ago
It's a bit early to say what Zig does and doesn't do. Memory safety aspects is still under development, and there seems to be a lot of focus on making it safer. But it might be a model where you focus on detecting errors in debug/safe-builds during development, but release fast builds using less safe code generation and allocators. Zig will probably never be as safe as a GCed language or Rust in this regard. But that's because it would go against other core design goals. I feel like the future of non-GC languages is Zig as better C (dead simple and explicit language), and Rust as better C++ (complex language with more memory management facilities, etc). The choice of languages was a bit odd. But I think Go is still in C's territory when it comes to being simple and explicit. Memory management (GC/not-GC) isn't necessarily the most important distinction in programming languages.
- tialaramex 6y ago
  What would "simple and explicit" even mean if somehow it includes "Oh, sometimes, maybe, I'll incur the expense of garbage collection in the middle of this other algorithm running and it'll take much longer than usual" ? I don't care about that in a Python program, but I can't see why I would accept it from something that's supposed to replace C. I also think you're imagining a lot of hard work during execution in Rust that just isn't there, most of the tricky stuff happens at compile time. If you can prove you really don't need the safety that does have runtime implications, you can choose not to have it, but of course you probably don't have proof, just the same gut instinct that usually gets us into trouble in other languages.

marvel_boy 6y ago

Simplicity wins. Always.

m12k 6y ago
Yes, the trouble is agreeing on a definition of "simple"
- jackosdev 6y ago
  My boss defines it as a microservice for every method
  - logicchains 6y ago
    That sounds incredibly complex and hard to maintain. What you need is a Docker container for every method, for isolation, then just use K8s to orchestrate them and YAML for control flow.
    - barbarbar 6y ago
      This is an excellent advice. Maybe double docker for every method?
    - MaxBarraclough 6y ago
      Raw Kubernetes, rather than Helm?
chousuke 6y ago
I dunno. One could say that C string handling is "simple" (it's just byte buffers!) or that manual loops are "simpler" than proper iterator abstractions, but those are both constructs that are hideously error-prone in practice. Perhaps it's the other way around and manual buffer management is actually the complex thing, since your application logic will have to involve a lot of code doing toil that isn't directly related to what you want to accomplish. EDIT: To expand a bit, I'm a huge proponent of simplicity; I think overabstraction is a massive problem with software nowadays. However, my thinking is that the problem isn't so much with the abstractions themselves, but that they aren't transparent. ORMs are a frequent offender here: a good abstraction wouldn't allow you to perform a thousand database queries by accident just by looping over a list. You could still model a list of database-backed persistent objects as a list, but any operation that hits the database should be an explicit fetch, not an implicit one.

chhs 6y ago

I threw together a D Programming language glob-grep based off of the Zig version the author posted, if anyone is curious: https://gist.github.com/aruthane/005c6c48f0deb9c4bfc83bc75e0e95f7 https://gist.github.com/aruthane/005c6c48f0deb9c4bfc83bc75e0...

perennus 6y ago
This is the most readable version for me. I like C++ also but I find the namespace clutter annoying.
- CyberDildonics 6y ago
  There is no reason there has to be namespace clutter in C++
drannex 6y ago
Great work! Really hope the author decides to run and see the performance in comparison.

lew89 6y ago

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. 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. 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: https://github.com/BartekLew/dumbgrep https://github.com/BartekLew/dumbgrep 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. Another thing is that C has very narrow application nowadays. A benchmark should be focussed on them and not on generic algorithms.

david_for_you 6y ago
This seems to be missing a return in the NULL check for handle in the match_file function. This leads to fgets being called with a NULL pointer, which I don't know what it does, it may be OK. I would argue that this is why a "better C" can be useful, it's the kind of error that would be much harder to make in rust.
- lew89 6y ago
  There is missing NULL check, but it doesn't crash, because the function would get nonexistent filename only if filesystem driver would do something strange (or file would be deleted just between readdir and fopen). xD I also noticed, that I don't close files and directories. Not a big deal, because fully functional and 100% correct program wasn't the goal here. :) EDIT: Actually fopen would return NULL when file is not readable. My bad. Anyway, such problems are trivial to debug.
  - carols10cents 6y ago

antirez 6y ago

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.

tutfbhuf 6y ago
How about 50 years old whiskey in a cask?
- DennisP 6y ago
  Difficult to keep it from just being super oaky at that age, but a great distiller willing to throw away a lot of bad casks can make something amazing. Macallan sold some 72 year old scotch in 2018: https://www.foodandwine.com/news/macallan-scotch-72-year-old-lalique-genesis-decanter https://www.foodandwine.com/news/macallan-scotch-72-year-old...
  - stock_toaster 6y ago
    Or just use very tired casks for most of that 50 years.
ginko 6y ago
A sauternes or tokaji is just about in its prime at that age.
- antirez 6y ago
  Both are special wines, indeed.

notorandit 6y ago

C is not C++! Where is the implementation in C? Boob!

deleted 6y ago
[deleted]

himujjal 6y ago

Zig is promising. The UX problem that the author talks about will be solves by Zig. About documentation, its still not 1.0, the language. So, its a work in progress.

tails4e 6y ago
I'm curious about this. It seemed to be alot of 'work' just to get arguments. While I could read the code with no prior experience, there were enough unexpectedly verbos things in there that suggested it could take a considerable time to learn
- himujjal 6y ago
  No task is too easy. For easy, we need to jump down to Python. Even C is too easy to learn but difficult to write. Zig is kind of in between Go and Rust in terms of the learning curve. In terms of programming, it is in between C and Rust. But it is simple enough. The documentation as I said for the stdlib isnt that great right now as I said.
  - dnautics 6y ago
    While I agree that Zig is in between Go and Rust, you're gonna find a lot of crazy stuff that will tie your brain in knots with Go. A few examples: - Json parsing being special cased into the language - multiplying a user-input integer with a time value to be a timeout - channels and goroutines (sorry, I've been spoiled by erlang) Aside from things that are actually bugs, I haven't found anything like this in Zig. On the contrary, I typically have found something that doesn't work how I expect, and then I think about it, and it's "of course it's like this, why isn't C like this??".
  - tails4e 6y ago
    I found the cxx example very easy to read, which surprised me, it was not thst verbose. The D example another poster has in this thread was the easiest and cleanest IMHO.
- lhorie 6y ago

justAnIdea 6y ago

> With no previous experience I opened vim and started coding. 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.

Flex247A 6y ago
System.gc()
linkdd 6y ago
Obviously, you never spent a minute trying to configure Vim. Vim is a fully featured IDE, learning to use it efficiently can greatly increase your productivity, and most important: it's also fun. > VIM, oh please... time to have a nap, grandpa. Such disrespect, all that's missing from your snarky comment is "ok boomer"...
mrwoggle 6y ago
People of all ages use VIM!
Zardoz84 6y ago
I work on some serious commercial big and old code base using Eclipse and NeoVim every time that I touch XML, SCSS or JavaScript files. Correctly configurators, VIM/NeoVIM it's better IDE for CSS/SCSS and JavaScript that Eclipse
Ma8ee 6y ago
You need to learn how to code without crutches. IDEs are great, and people should definitely use them, but I’ve met too many programmers who just are lost without them. The worst example was a guy who couldn’t even navigate his own small program except with the debugger. Even though he wrote this small program himself, he didn’t managed to have a mental image of the call stack. So, some of you who rely on the IDE all the time maybe need to do without it a little to train some muscles that have atrophied.
dang 6y ago

maccard 6y ago

I think there is definitely merit in these kinds of posts. This developers measure of productivity is "how low level can I go" clearly; they declared zig was clear despite saying this: > 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. 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? 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++. 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.

mhh__ 6y ago
> using cake and LLVM Sure they (not sure about LLVM as a build system?) work but they really aren't all that great in my experience.
- maccard 6y ago
  I've had excellent experience with cmake over the last 10 years. It's no cargo, that's for sure, but it gives you a crossplatform cross toolchain extensible reliable build system Llvm was specifically in reference to the "tooling" comment in the blog post. Clang format and clang-tidy(which conveniently has a neat integration with cmake!)
- mhh__ 6y ago
  How did I not notice it corrected cmake to cake...
linkdd 6y ago
CMake, SCons, Autotools, Meson, Premake, to quote only them. They are build systems alright, but they miss the most crucial point: dependency managment. On the other side we have: - cargo for Rust - buck and buckaroo for C++ which seems nowhere near complete Am I missing something?

Zardoz84 6y ago

Seeing the title, I expected an article benchmarking DLang "Better C". Instead, the author even don't mentioned anything about DLang...

drannex 6y ago
You aren't alone there

vitus 6y ago

A nit/bug re: the glob matching algorithm in use: '?' evidently represents "any character" per the !glob("h?i", "hi") test. But, if I add a test for glob("???", "hi"), that succeeds unexpectedly even though it should run out of input. 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. (This looks like it's the case for all four languages, as the glob algorithm looks identical in all four, modulo syntax differences)

alfiedotwtf 6y ago

These comparison articles can be reduced into 3 types... Write code: 1. In less time 2. That runs faster 3. That's less buggy Pick one. ... this article advocates for (1).

kgeist 6y ago

>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. Strange conclusion considering their benchmark was I/O-bound by design

lerno 6y ago

Would have liked comparisons with Nim, Crystal, Odin, D.

maxpert 6y ago

Heeyyyyy! Where is my Nim and Crystal? If you think GC based languages are acceptable I highly highly encourage Crystal.

systemBuilder 6y ago

--- comment removed ---

hu3 6y ago
Have you never written a bug in your life? Should we not believe your conclusions too? > His pretty buggy code infinite loops if pattern == "". Does anyone truly believe his conclusions, if he evaluates programming languags according to how well they execute buggy code? -systemBuilder

lhorie 6y ago

> 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 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. 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. What works for me is having stdlib docs and source code from github side by side and jumping back and forth between them. 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.

kidfrommars 6y ago

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.

edflsafoiewq 6y ago
The Rust looks fine to me.
- seoaeu 6y ago
  Nothing looks necessarily wrong to me but there are some elements that aren't exactly how this code would normally be written. Like that they don't take advantage of Iterator::enumerate() which makes the the for loop more awkward than necessary. Or how strings are treated as arrays of bytes (rather than sequences of unicode characters as the language pressures you to).
  - steveklabnik 6y ago
    Yeah. This code isn’t bad, but it’s not what I’d write. The largest difference is that, if given this problem, I would start with walkdir (and maybe glob), rather than trying to write all of this myself. Not to mention Cargo instead of a Makefile. The loops also feel very C-like, but that might still be the best you can do. I'd have to actually give it a try, but I feel like iterators could clean this up, as you say. To reiterate: that doesn’t mean this is bad or wrong. It might be a bit harder or more complex than it has to be. But also, you have to know that these things exist in the first place, which is it’s own challenge. EDIT: Oh look, someone on lobsters thought the same: https://lobste.rs/s/ndxi2r/better_c_benchmark#c_k2kwjs https://lobste.rs/s/ndxi2r/better_c_benchmark#c_k2kwjs https://github.com/jswrenn/treescan/blob/main/src/main.rs https://github.com/jswrenn/treescan/blob/main/src/main.rs

bfrog 6y ago

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.

fithisux 6y ago

A benchmark with "better c" mode of Dlang would be amazing.

slmjkdbtl 6y ago

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

vram22 6y ago

>They often complain the syntax is unclear and requires paying attention to details. 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.

drannex 6y ago

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.

arunc 6y ago

Wondering why D was not considered. D is probably the better C I've come across.