Live data from Hacker News

A “Better C” Benchmark

zserge.com

101–110 of 192 posts

Re: A “Better C” Benchmark

#101
post #8

Earlier quoted context omitted.

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.

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.

Re: A “Better C” Benchmark

#103

--- comment removed ---

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

Re: A “Better C” Benchmark

#105
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…

Regarding the string type in Zig, in case some people are interested by this you can read those two threads from the Zig github repository to understand a bit better previous discussions (I would recommend reading them, they are both interesting):

-------

"Improved handling of strings and unicode", https://github.com/ziglang/zig/issues/234

Andrew answer:

> I'm not convinced that this is a language change rather than a standard library feature.

(source https://github.com/ziglang/zig/issues/234#issuecomment-28927...)

-------

"Proposal: Add String to the type system", https://github.com/ziglang/zig/issues/7734

Andre answer:

> We won't have a string type in the language.

> OP problem can be solved with a better std.fmt.format API which better communicates intent. This is a deficiency of the std lib, not the language

(source https://github.com/ziglang/zig/issues/7734#issuecomment-7581...)

Re: A “Better C” Benchmark

#107

Simplicity wins. Always.

Unsophisticated engineering solutions are not always the best. Modern CPUs are monstrously complex, for example. Modern airliners are incredibly complex. Simple solutions would be woefully uncompetitive. In the domain of programming languages, minimalistic low-level languages like assembly, C, and Forth, tend to be unsafe. They enable categories of serious bugs that never occur in safe languages. Modern garbage colle…

I'd call Mars Rovers, especially the one recently sent, pretty "complex" or "modern". All of its software is C. So I'll simply call bullshit on anyone telling me "it's not possible to achieve what Safe Rust does" in C.

Re: A “Better C” Benchmark

#108
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…

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

Re: A “Better C” Benchmark

#109
post #10

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/005c6c48f0deb9c4bfc83bc75e0...

This is the most readable version for me. I like C++ also but I find the namespace clutter annoying.

There is no reason there has to be namespace clutter in C++

Re: A “Better C” Benchmark

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

Post reply on HN