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

81–90 of 192 posts

Re: A “Better C” Benchmark

#81

Post by Ar-Curunir »

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

Maybe it doesn’t matter for small programs, but probably in large programs tracing the control flow would be non trivial, so, as the parent said, over the lifetime of the program it would add up

Re: A “Better C” Benchmark

#82

Post by alfiedotwtf »

viraptor wrote: post #61
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.

If you can make some mistake, it's only a matter of time until someone will make it. This scales with the codebase size. And you only need one person to make the mistake and another to miss it in review - it doesn't matter if everyone else is a 40 years of experience coder.

"Nobody would write that type of code, and if they did, you should just get better programmers" is such a common theme in these discussions.

... yet every time time I've been told "you don't need Rust, just use C++", I can point to at least one UAF in their own code, and have even pointed to CVEs on Mitre for their own projects!

People make mistakes. Use tools that stop these mistakes, rather than helping you to "write code faster" like in the article (aka writing bugs faster).

Re: A “Better C” Benchmark

#83

Post by perennus »

chhs wrote: 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.

Re: A “Better C” Benchmark

#85

Post by naavis »

galangalalgol wrote: post #63
naavis wrote: post #57

Earlier quoted context omitted.

This is exactly my painpoint with C++ too. With Rust and such I'm one simple command line call away from installing a dependency. With C++ every dependency is a battle.

There is conan or vcpkg. I do wish crates.io and julia would make it easier to develop on non internet machines. The ease of dependency management has bred staggeringly deep dependency trees for rust and julia. If I could run a cargo command to get a human readable dependency list that I could then go to an internet facing machine and run a cargo command to put into a tgz to drag back over that would be helpful. Is t…

Yes, Conan and vcpkg have gotten better lately, but that is a relatively recent development. Just two years ago I still had a hard time finding some common libraries with Conan. It's good that the situation is better now.

Re: A “Better C” Benchmark

#86

Post by vitus »

banachtarski wrote: post #5
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…

> 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 disagree, as there are lots of ways it can manifest in C++. To list a few examples:

- Implicit lambda capture where you use & (admittedly often out of laziness).

- A string_view constructed from an accidental string copy (e.g. if your function parameter is a const std::string instead of a const std::string&, or if you write for (auto foo : v) { ... }).

- A callback that references some member variables of some object on the stack, which usually completes before the function returns (but maybe you forget to synchronize in an edge case).

Tooling can help identify a number of these issues, but it's not perfect. And a number of these issues are very much C++-specific.

Re: A “Better C” Benchmark

#87

Post by stiray »

bluecalm wrote: post #52
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…

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 Go programs run fast and with low memory fingerprint is about the same as C++ with a huge minus that you dont have a delete/free keyword that designates "now the memory is de-allocated". With go, you need to think hard, I would prefer GC language that has a deallocation keyword, so I can forget about everything I dont care about but still deallocate what I want in specific moment.

For me personally, the hugest difference of Go against C/C++ is the ecosystem and how simple is to use 3rd party libraries/modules/whatever.

Re: A “Better C” Benchmark

#88

Post by Ygg2 »

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…

Curious. Did you use proper strings or null terminated character array?

Re: A “Better C” Benchmark

#89

Post by kgeist »

>All had about the same performance when scanning through my whole /usr/include file tree. That’s why I wanted to highlight that technical characteristics are often not as important as the developer experience.

Strange conclusion considering their benchmark was I/O-bound by design

Re: A “Better C” Benchmark

#90

Post by stiray »

gameswithgo wrote: post #76
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.

There are a lot of sweeping unsubstantiated assertions here, and unclearly defined ideas. What is lousy thinking and design? What are the practical downsides of it in the program? Given how many exploits are caused by memory mistakes in C and C++, maybe using those is actually the lousy thinking?

This is irrelevant, if you give F1 racing car to an enthusiastic casual driver, you will get a wracked car and few dead in matter of hours. And should I remember you how many exploits we had due to simple sql injection? The last buffer overrun, stack overflow, that I did was like 5 years back and wasn't remotely exploitable. But I agree that not making stupid mistakes takes years to master (in my case 20+).

The problem is not in exploits, the problem is in price of people having enough knowledge to not do stupid mistakes and every company wants developer that pays him nothing (or as little as possible) and gets everything or close to it (open source(tm); I want to build a house. I am still searching for an idiot that would make it for "recognition").

And as such they search for most fool proof technology where they could replace expensive and knowledgeable developers with, ideally, street bums that would work for food. And most of the software we are using today is like that: made from street bums.

The difference between 1990s software and today is too obvious to not notice the difference, even the "great breakthroughs" and new hypes are just xeroxing what we already had.

Post reply on HN