Simplicity wins. Always.
Yes, the trouble is agreeing on a definition of "simple"
My boss defines it as a microservice for every method
A “Better C” Benchmark
11–20 of 192 posts
Re: A “Better C” Benchmark
#12Simplicity 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 related to what you want to accomplish.
EDIT:
To expand a bit, I'm a huge proponent of simplicity; I think overabstraction is a massive problem with software nowadays. However, my thinking is that the problem isn't so much with the abstractions themselves, but that they aren't transparent. ORMs are a frequent offender here: a good abstraction wouldn't allow you to perform a thousand database queries by accident just by looping over a list. You could still model a list of database-backed persistent objects as a list, but any operation that hits the database should be an explicit fetch, not an implicit one.
Re: A “Better C” Benchmark
#13Earlier 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.
I dunno what you’re saying; this kind of bug also proves difficult to avoid in large, security-critical projects like web browser engines.
Usually I think tooling is fairly good at catching these; I feel like misuse of dynamic memory allocation is usually harder to catch these days.
Re: A “Better C” Benchmark
#14[deleted]
Re: A “Better C” Benchmark
#15Earlier 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.
I dunno what you’re saying; this kind of bug also proves difficult to avoid in large, security-critical projects like web browser engines.
They’re talking specifically of pointers to the stack.
Re: A “Better C” Benchmark
#16What 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 call, which can can problems not related to memory safety.
(I've played with Rust but I don't practice it daily. I've also played with D but don't practice anymore. I don't know Go.)
Re: A “Better C” Benchmark
#17Nice 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 it for you.
It took me 30 minutes, only change is that I don't check if file is binary, I guess. I liked that I was doing it in C because I know it and I'm comfortable with it. Few checks in man and everything's clear. Only disadvantage of C is that it doesn't have standard API for directories, so my code is only for POSIX. Here's the code: https://github.com/BartekLew/dumbgrep
The other thing are sources you've done. They are almost the same (it'd be nice to see the more feeling of the language, idiomatic code, etc.) and I didn't like reading them at all, not a clean code and all are longer than my C code.
Another thing is that C has very narrow application nowadays. A benchmark should be focussed on them and not on generic algorithms.
Re: A “Better C” Benchmark
#1850 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.
Re: A “Better C” Benchmark
#19C is not C++!
Where is the implementation in C? Boob!
Re: A “Better C” Benchmark
#20C is not C++! Where is the implementation in C? Boob!
[deleted]