Live data from Hacker News

I stopped everything and started writing C again

kmx.io

391–400 of 475 posts

Re: I stopped everything and started writing C again

#391
post #344
post #187

Earlier quoted context omitted.

Agreed. C, Go, Python, and Lua are my go-to languages because of their simplicity. It's unfortunate, but in my opinion, most mainstream languages are needlessly complex. In my experience, whether it's software architecture or programming language design, it's easy to make things complicated, but it takes vision and discipline to keep them simple.

> C, Go, Python, and Lua are my go-to languages because of their simplicity One of these things is not like the others! Python's complexity has been increasing rapidly (e.g. walrus operator, match statement, increasingly baroque type hints) - has this put you off the language at all?

Python's complexity has been increasing since Guido stepped away and it is off-putting. The language is still nowhere near as complex as Ruby or others, but I am keeping my eyes open for alternatives.

Re: I stopped everything and started writing C again

#392

Earlier quoted context omitted.

Can't you disable exceptions?

Yes, but the C++ library becomes inherently broken because there is no error reporting.

Only the parts that need to heap-allocate. Which includes most containers, but not e.g. algorithms.

Re: I stopped everything and started writing C again

#393

Earlier quoted context omitted.

For me, where linked lists, graphs and other structures are a common need, zig gives me slices and deferred frees. Rust is double expensive in this case. You have to memorize the borrow checker and be responsible for all the potential undefined behavior with unsafe code. But I am not a super human systems programmer. Perhaps if I was the calculus would change. But personally when I have to drop down below a GC langua…

> You have to memorize the borrow checker Correct me if I am wrong, but Rust at least has a borrow checker while in C (and Zig) one has to do the borrow checking in their head. If you read a documentation for C libraries, some of them mention things like "caller must free this memory" and others don't specify anything and you have to go to the source code to find out who is responsible for freeing the memory.

The point is that any formal borrow checking will reject perfectly valid patterns because they are impossible to statically prove, and this comes up especially often with data structures like graphs. So you end up struggling against the compiler - either you just go unsafe (in which case you have to be even more careful than in C and Zig because Rust makes more optimization assumptions based on ownership which you're now responsible for), or else you use hacks like using indices instead of pointers to, basically, work around the borrow checker.

Re: I stopped everything and started writing C again

#394
post #251

Writing code in C is very unpleasant, verbose and repetative. For example, if I want to have a structure in C and have a way to print its contents, or free its memory and memory of nested structures, or clone it recursively, it is very difficult to make automatically. I found only two options: either write complicated macros to define the structure and functions (feels like writing a C++ compiler from scratch), or de…

Simplify. If you try to write the same complicated mess in C as you would in any other language it's going to hurt. Not having a package manager can be a blessing, depends on your perspective.

There's no amount of simplification that'll free you from the need to manually check and handle/propagate errors or deallocate resources in C. You might be able to reduce the amount of code you need to write, but it's still several lines of C versus one line of something else - and if you make a mistake or even forget something in those several lines, things will often compile and run fine, but you'll have memory leaks or sporadic crashes.

Re: I stopped everything and started writing C again

#395

Earlier quoted context omitted.

Rust is not free of trade offs and you're not helping the cause the way you think you are. Just a few off the top: - Rust is a much more complex language than C - Rust has a much, much slower compiler than pretty much any language out there - Rust takes most people far longer to "feel" productive - Rust applications are sometimes (often?) slower than comparable C applications - Rust applications are sometimes (often?…

> Rust applications are sometimes (often?) slower than comparable C applications Could you cite some examples? There are plenty of counter-examples - ripgrep is 5-10x faster than grep ( https://github.com/BurntSushi/ripgrep/blob/962d47e6a1208cf21... ). There's a reason ripgrep is embedded within VS Code to power search. - Memory-safe implementations of PNG (png, zune-png, wuffs) now dramatically outperform memory-uns…

> I don't consider the benchmarks game a worthwhile comparison because they're only writing assembly

Do you mean the "Rust" programs are assembly?

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Re: I stopped everything and started writing C again

#396
post #395

Earlier quoted context omitted.

> Rust applications are sometimes (often?) slower than comparable C applications Could you cite some examples? There are plenty of counter-examples - ripgrep is 5-10x faster than grep ( https://github.com/BurntSushi/ripgrep/blob/962d47e6a1208cf21... ). There's a reason ripgrep is embedded within VS Code to power search. - Memory-safe implementations of PNG (png, zune-png, wuffs) now dramatically outperform memory-uns…

> I don't consider the benchmarks game a worthwhile comparison because they're only writing assembly Do you mean the "Rust" programs are assembly? https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

> Do you mean

No I don't mean. I said what I said.

If you click the C program right next to the Rust program for "spectral-norm" you get the equally unreadable - https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Re: I stopped everything and started writing C again

#397

Earlier quoted context omitted.

except nobody has to cater to every worst case scenario

I am sure the Rust community would welcome feedback from blind developers about their error messages. Accessibility is a good thing.

One thing that could help here is that the compiler is able to offer output in JSON, allowing you to format the messages however you'd like: https://doc.rust-lang.org/rustc/json.html

I'm not aware of an existing tool to produce blind-friendly output, but this would at least be a part of that!

Re: I stopped everything and started writing C again

#398
post #127

I'm kinda in the opposite camp. After doing a bunch of VB in my tweens and teens, I learned Java, C, and C++ in college, settling on mostly C for personal and professional projects. I became a core developer of Xfce and worked on that for 5 years. Then I moved into backend development, where I was doing all Java, Scala, and Python. It was... dare I say... easy! Sure, these kinds of languages bring with them other pro…

But TFA is not writing in C. TFA is writing in a language that compiles to C.

Re: I stopped everything and started writing C again

#399
post #395

Earlier quoted context omitted.

> I don't consider the benchmarks game a worthwhile comparison because they're only writing assembly Do you mean the "Rust" programs are assembly? https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

> Do you mean No I don't mean. I said what I said. If you click the C program right next to the Rust program for "spectral-norm" you get the equally unreadable - https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Do you mean the "Rust" programs are assembly but the "C" programs forced them to be that way?

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Re: I stopped everything and started writing C again

#400

Earlier quoted context omitted.

I'd imagine the main way one reduces instances of these mistakes is to restrict resource ownership into certain patterns which have a clear place for freeing, and rules that ensure it's always reached, and only once.

There are many approaches depending on the type of program or suite of programs being built. Always pairing the creation of free() code and functions with every malloc() is one discipline. Another, for a class of C utilities, is to never free() at all .. "compute anticipated resource limits early, malloc and open pipes in advance, process data stream and exit when done" works for a body of cases. In large C projects…

Right. Another one, small but effective, is to put an overflow check on the calculation of the size to pass to malloc().

And another - always use size_t for anything that is used as an index.

Post reply on HN