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

131–140 of 192 posts

Re: A “Better C” Benchmark

#131

Post by DennisP »

tutfbhuf wrote: post #91
antirez wrote: post #18

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.

How about 50 years old whiskey in a cask?

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

Re: A “Better C” Benchmark

#132

Post by dnautics »

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

Re: A “Better C” Benchmark

#133

Post by steveklabnik »

seoaeu wrote: post #120
edflsafoiewq wrote: post #116

Earlier quoted context omitted.

The Rust looks fine to me.

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

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://github.com/jswrenn/treescan/blob/main/src/main.rs

Re: A “Better C” Benchmark

#134

Post by dnautics »

himujjal wrote: post #69
tails4e wrote: post #42

Earlier quoted context omitted.

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

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.

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

Re: A “Better C” Benchmark

#135

Post by maccard »

naavis wrote: post #95
maccard wrote: post #78

Earlier quoted context omitted.

vcpkg install. It integrates with cmake too!

Then again, for every project you have to then setup vcpkg and cmake. I thoroughly enjoy that Rust comes with a build system, package manager and test framework out-of-the-box. But it is good that the situation with C++ is getting better.

Yep no arguments there. It's not perfect, but it's nowhere near as bad as the article makes it out to be. Also, you only set up a project once, but it's compiled and iterated on many many more times. Having some initial friction isn't ideal but it's better to solve for the real problems which are maintaining a project.

Re: A “Better C” Benchmark

#136

Post by ginko »

antirez wrote: post #18

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.

A sauternes or tokaji is just about in its prime at that age.

Re: A “Better C” Benchmark

#138

Post by Matumio »

lew89 wrote: post #73
carols10cents wrote: post #70

Earlier quoted context omitted.

I like that I don't have to spend the time debugging trivial problems like these in Rust though. The compiler catches them for me, and I get more time and brain power to spend debugging nontrivial problems. It adds up.

Everything is matter of price. Such an error is nobrainer actually, because just before I get an error message. If I don't know that yet, I run on gdb and everything's clear. Couple of seconds. How manyof them I have to do to ballance learning a new language(and I'm not sure if I like it eventually)? If I was a system software developer, that would probably be a good choice. I program mostly in high level languages,…

It's trivial to fix if you catch it early, and perfectly fine for a tool you run yourself. However if the problem is discovered two years later in production, there will be a forth-and-back until you get at the correct error message, possibly downtime, and if there isn't one you'll be instructing them how to install debug symbols for libX.

Re: A “Better C” Benchmark

#139

Post by slmjkdbtl »

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

Re: A “Better C” Benchmark

#140

Post by sundarurfriend »

kidfrommars wrote: post #114

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

Honestly I don't understand the complaints about the readability of this Rust code. I'm new to all three languages here, and I find it pretty readable. Maybe it was harder to write in Rust, I don't know, but in terms of readability the Zig and Rust code look pretty similar, and Go is the one that stands out as somewhat hard to parse and understand.
Post reply on HN