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

41–50 of 192 posts

Re: A “Better C” Benchmark

#41

Post by pjmlp »

saagarjha wrote: post #13
jchw wrote: post #6

Earlier quoted context omitted.

I dunno what you’re saying; this kind of bug also proves difficult to avoid in large, security-critical projects like web browser engines.

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.

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.

Re: A “Better C” Benchmark

#42

Post by tails4e »

himujjal wrote: post #22

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.

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

Re: A “Better C” Benchmark

#43

Post by saagarjha »

pjmlp wrote: post #41
saagarjha wrote: post #13

Earlier quoted context omitted.

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.

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.

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.

Re: A “Better C” Benchmark

#44

Post by linkdd »

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?

Re: A “Better C” Benchmark

#45

Post by david_for_you »

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.

Re: A “Better C” Benchmark

#46

Post by linkdd »

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.

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

Re: A “Better C” Benchmark

#47

Post by barbarbar »

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.

This is an excellent advice. Maybe double docker for every method?

Re: A “Better C” Benchmark

#48

Post by maccard »

mhh__ wrote: post #40
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…

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

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!)

Re: A “Better C” Benchmark

#49

Post by acka »

qart wrote: post #36
makapuf wrote: post #8

Earlier quoted context omitted.

Had to look it up, DasBetterC is not german, it's "D as a better C"

In German, it would have been besser, not better.

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

Re: A “Better C” Benchmark

#50

Post by mrwoggle »

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.

People of all ages use VIM!
Post reply on HN