A “Better C” Benchmark • Hacker News Board

Re: A “Better C” Benchmark

#111

Post by logicchains » Sat, Mar 27, 2021, 3:33 PM UTC

yakubin wrote: post #59

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

>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

No offense but this just sounds like bad design. Haskell has the C preprocessor so technically that particular criticism would apply to it too, but nobody would say it's Haskell's problem just because in theory people could use this feature to write terrible code. (I understand maybe this approach was necessary for interfacting with some other vendor/legacy code somewhere, but in that case the fundamental issue is still bad code, not C++: the bad vendor/legacy code).

Re: A “Better C” Benchmark

#112

Post by CyberDildonics » Sat, Mar 27, 2021, 3:36 PM UTC

stiray wrote: post #87

bluecalm wrote: post #52

Earlier quoted context omitted.

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.

I agree with you. I am doing a lot of coding in Go for my multiplatform home projects and C/C++ at work 8 hours per day. Go brings faster results due to the really great and easy to integrate 3rd party libraries. There is literally no way that I would go for such a large number of third party dependencies with any C++ software - it is just too much work to prepare the libraries for use. The amount of thinking to make…

Are you actually using new and delete outside your own data structures? I have barely used new or delete for years, I don't even use them when building data structures - the vast majority of the time I make compound data structures out of what is in the standard library. It is only when memory layout needs to be very specific that I use new and even then it is placement new.

Re: A “Better C” Benchmark

#113

Post by logicchains » Sat, Mar 27, 2021, 3:37 PM UTC

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…

>This combined with "strings" being byte buffers like in C are not a good thing.

It depends what the problem you're facing with. If the problem is "people writing C++ code with terrible latency characteristics because they don't understand how it works underneath and the stdlib doesn't even provide a way to efficently concatenate strings (i.e. by using a buffer, not allocating new memory)", Zig's approach is a great thing.

Re: A “Better C” Benchmark

#114

Post by kidfrommars » Sat, Mar 27, 2021, 3:42 PM UTC

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 OCaml and Haskell as they are by C and C++. It's not surprising, then, that someone who is predominately a C programmer would need more than a couple hours to be able to really judge the difference between the languages.

Re: A “Better C” Benchmark

#115

Post by lhorie » Sat, Mar 27, 2021, 3:48 PM UTC

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'm not the OP, but could try to venture an answer as someone who's used some of those languages.

D is nice. I could see myself picking it instead of go. It's much more expressive than go and it's mature enough. Cross compilation story isn't as great though. Haven't tried asBetterC. I was under the impression this corner of D isn't as mature as D proper.

Java, IMHO, has limited uses, in the sense that making distributable binaries for client side usage (e.g. CLIs) is quite a hassle, and the need for a JRE makes it quite a bit bulkier than a C or go thing.

I'm partial to Nim and Crystal (and V). They aren't as appealing to me personally because they feel complex compared to C and go (and zig). If the appeal of these languages is "a better golang", I think D has beat them to the punch. Also, again, cross compilation tends to be a bit of a deal breaker for me.

Another language that seem interesting in this space is Odin, but I could not for the life of me find stdlib docs for it.

Another seemingly interesting language is Beef, which has a sort of C# feel (a good thing in my books), but unfortunately I haven't had a chance to play around with it yet.

Cosmopolitan is cool, but is just C, and younger than even zig.

Re: A “Better C” Benchmark

#116

Post by edflsafoiewq » Sat, Mar 27, 2021, 3:53 PM UTC

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…

The Rust looks fine to me.

Re: A “Better C” Benchmark

#117

Post by bfrog » Sat, Mar 27, 2021, 4:05 PM UTC

Honestly Rust is pretty expressive. There's always some things that you are going to run into. But mostly Rust is a really nice language and environment to work in.

Re: A “Better C” Benchmark

#118

Post by lhorie » Sat, Mar 27, 2021, 4:22 PM UTC

maccard wrote: post #77

flohofwoe wrote: post #74

Earlier quoted context omitted.

> This combined with "strings" being byte buffers like in C are not a good thing. The problem of C strings is that they are zero-terminated, not that they are byte buffers. Strings in Zig are foremost slice types (pointer/size pairs), but for C compatibility, Zig also has the concept of 'sentinel terminated arrays': https://ziglang.org/documentation/master/#Sentinel-Terminate... > how do you handle an umlaut in zig V…

> utf-8 as it should be Agreed, but now your standard library doesn't have string support, it has byte buffer support. That's no improvement over C, compared to rust.

Zig does have utf8 APIs, though to be fair, the docs are quite sparse

Re: A “Better C” Benchmark

#119

Post by lhorie » Sat, Mar 27, 2021, 4:28 PM UTC

tails4e wrote: post #42

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

IIRC there's a std.os.args or some such that is just a slice of byte arrays in unix platforms. The iterator API builds cross-platform support on top of it, as I understand. In my books, that's acceptable for an actually-low-level language.

Re: A “Better C” Benchmark

#120

Post by seoaeu » Sat, Mar 27, 2021, 4:29 PM UTC

edflsafoiewq wrote: post #116

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…

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