Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A “Better C” Benchmark

zserge.com

Post reply on HN
Print view View original

51–60 of 192 posts

Re: A “Better C” Benchmark

#51

Post by maccard »

linkdd wrote: post #44
maccard wrote: post #38

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 sid…

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?

Cmake is pretty good, but you're right it's no dependency manager. And dependency management us definitely tough in c++. There's vcpkg and conan though which are huge improvements over the status quo.

Re: A “Better C” Benchmark

#52

Post by bluecalm »

renox wrote: post #3

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 point…

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.

Re: A “Better C” Benchmark

#53

Post by Zardoz84 »

justAnIdea wrote: post #32

> 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.

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

Re: A “Better C” Benchmark

#55

Post by enriquto »

chousuke wrote: post #12
marvel_boy wrote: post #4

Simplicity wins. Always.

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 rel…

> or that manual loops are "simpler" than proper iterator abstractions,

LOL at "proper iterator abstractions" to replace loops. You will take loops from my cold, dead hands!

Re: A “Better C” Benchmark

#56

Post by Ma8ee »

justAnIdea wrote: post #32

> 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.

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.

Re: A “Better C” Benchmark

#57

Post by naavis »

linkdd wrote: post #44
maccard wrote: post #38

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 sid…

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?

This is exactly my painpoint with C++ too. With Rust and such I'm one simple command line call away from installing a dependency. With C++ every dependency is a battle.

Re: A “Better C” Benchmark

#58

Post by lew89 »

david_for_you wrote: post #45
lew89 wrote: post #17

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…

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.

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.

Re: A “Better C” Benchmark

#59

Post by yakubin »

maccard wrote: post #38

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 sid…

> 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++.

Last week I debugged an issue in a big C++ codebase, where we were getting memory corruption. Source of the issue? Compiler, linker and build system being separate things and only compiler understanding types (also, lack of modules, which is another symptom of build system being separate from the language). Namely, conditional compilation was involved, someone made a struct which had a field in it based on whether a preprocessor constant was defined or not (passed with -D to the compiler on the command line). Turned out some files were compiled with the define and some not, so some files were compiled based on the assumption that this struct is N bytes long, and some with the assumption that this struct is N+M bytes long. But the linker doesn't have any information available to it to detect this error.

And then there is the issue that to write a C++ program these days, it doesn't suffice that you just know C++. Languages you need to know:

- C++

- language of your build system, which is always handicapped, yet Turing-complete

- Python

- if something goes wrong, and you need to debug something: Make with its custom shell-language

- shell

It's a tower of babel. For all the whining on users of other languages for using libraries, C++ users have a lot of complexity hidden in their build systems.

In Zig and the not-yet-released Jai, you only need to know the language you write your program in. The "if" in your language of choice is perfectly suitable for expressing conditional compilation. Structs in your language of choice are perfectly suitable for expressing declarative configuration.

Re: A “Better C” Benchmark

#60

Post by MaxBarraclough »

logicchains wrote: post #23
jackosdev wrote: post #11

Earlier quoted context omitted.

My boss defines it as a microservice for every method

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.

Raw Kubernetes, rather than Helm?
Post reply on HN