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

31–40 of 192 posts

Re: A “Better C” Benchmark

#31

Post by Leherenn »

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…

Are manual loops, the kind that that can be replaced by iterators, really "hideously error-prone"? Don't get me wrong, I'll take the iterator approach every day, because the index is simply complexity I don't need, but I've never seen issues with the basic for(int i...). Off by one errors tend to happen when you start doing index arithmetic, and iterator are not going to help you there.

Re: A “Better C” Benchmark

#32

Post by justAnIdea »

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

Re: A “Better C” Benchmark

#33

Post by drran »

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…

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.

Re: A “Better C” Benchmark

#34

Post by WalterBright »

makapuf wrote: post #8
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…

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

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.

Re: A “Better C” Benchmark

#35

Post by Flex247A »

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.

  System.gc()

Re: A “Better C” Benchmark

#36

Post by qart »

makapuf wrote: post #8
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…

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.

Re: A “Better C” Benchmark

#37

Post by WalterBright »

renox wrote: post #29
banachtarski wrote: post #5

Earlier quoted context omitted.

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

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

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

Re: A “Better C” Benchmark

#38

Post by maccard »

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.

Re: A “Better C” Benchmark

#39

Post by cb321 »

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…

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

Re: A “Better C” Benchmark

#40

Post by mhh__ »

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.

Post reply on HN