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?
I stopped everything and started writing C again
391–400 of 475 posts
Re: I stopped everything and started writing C again
#392Re: I stopped everything and started writing C again
#393Earlier 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.
Re: I stopped everything and started writing C again
#394Writing 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.
Re: I stopped everything and started writing C again
#395Earlier 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…
Do you mean the "Rust" programs are assembly?
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Re: I stopped everything and started writing C again
#396Earlier 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/...
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
#397Earlier 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.
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
#398I'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…
Re: I stopped everything and started writing C again
#399Earlier 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/...
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Re: I stopped everything and started writing C again
#400Earlier 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…
And another - always use size_t for anything that is used as an index.