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

21–30 of 192 posts

Re: A “Better C” Benchmark

#21

Post by ruph123 »

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"

Lol thank you for that. I thought that was a joke language like Enterprise.

Re: A “Better C” Benchmark

#23

Post by logicchains »

jackosdev wrote: post #11
m12k wrote: post #9

Earlier quoted context omitted.

Yes, the trouble is agreeing on a definition of "simple"

My boss defines it as a microservice for every method

That sounds incredibly complex and hard to maintain. What you need is a Docker container for every method, for isolation, then just use K8s to orchestrate them and YAML for control flow.

Re: A “Better C” Benchmark

#25

Post by IshKebab »

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…

Because you're ignoring a lot of other reasons to use Go or Rust.

Go is simple, has very fast compile times, produces a single static binary, easy trivial to cross-compile, has very short GC pauses, has a fantastic standard library. The same cannot be said for those other languages.

Rust has a very strong type system that makes lots of runtime errors into compile time errors, it's basically as fast a language as you can get, except for GUIs it has a really good library ecosystem (way better than all the languages you mentioned except maybe Java), it produces a static binary, cross-compilation is relatively easy (as long as you aren't trying to cross compile to Mac).

Re: A “Better C” Benchmark

#26

Post by a3n »

jraph wrote: post #16
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…

> If you can use a GCd language like Go why would you go with Rust Memory leaks are possible in GCd languages and when they happens, sometimes you cannot fix them easily / properly because of architectural problems. Thinking about the lifetime of an object can help with this. We also still miss something in many languages that specifies whether we can modify or access an object after passing it as a argument to a cal…

Is there a nice idiom name that represents ensuring that an object gets "released" and eligible for garbage collection?

Re: A “Better C” Benchmark

#27

Post by [deleted] »

jraph wrote: post #16
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…

> If you can use a GCd language like Go why would you go with Rust Memory leaks are possible in GCd languages and when they happens, sometimes you cannot fix them easily / properly because of architectural problems. Thinking about the lifetime of an object can help with this. We also still miss something in many languages that specifies whether we can modify or access an object after passing it as a argument to a cal…

[deleted]

Re: A “Better C” Benchmark

#28

Post by CraigJPerry »

a3n wrote: post #26
jraph wrote: post #16

Earlier quoted context omitted.

> If you can use a GCd language like Go why would you go with Rust Memory leaks are possible in GCd languages and when they happens, sometimes you cannot fix them easily / properly because of architectural problems. Thinking about the lifetime of an object can help with this. We also still miss something in many languages that specifies whether we can modify or access an object after passing it as a argument to a cal…

Is there a nice idiom name that represents ensuring that an object gets "released" and eligible for garbage collection?

Memory leaks in Java are usually not so bad to fix. Maybe some off-heap scenarios could be trickier but IME people are pretty careful if they’re going to the extremes of off-heap.

Memory leaks in enterprise java in my experience are usually things like forgetting to close a resource of some sort or maybe doing something silly like continually growing a set or map with duplicate objects because of faulty equals() or hashCode(). Both of these cases are well covered by static analysis.

Maybe the trickiest but still relatively common scenario is a design issue where a weak reference is required - i guess that fits parent description pretty well.

Re: A “Better C” Benchmark

#29

Post by renox »

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

Re: A “Better C” Benchmark

#30

Post by renox »

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…

Having an array 'view' with a pointer to the end of the array seems much more simple to manage that having to manage a sentinel value.

Less accidentally quadratic algorithms, this way!

Post reply on HN