News for hackers. Stuff that matters.
Re:Speed of Rust vs. C by rocqua on Saturday March 13, 2021 @06:14AM (#26445829)
Yesterday I upgraded an entire code-base from C to C++ just because it was faster than writing my own dynamically resizing array in C.

Writing programs in C is harder just because there are essentially no containers in the stdlib.

Re:Speed of Rust vs. C by JohnStrangeII on Saturday March 13, 2021 @06:26AM (#26445872)
Aren't there good container libraries for C?
Re:Speed of Rust vs. C by ben0x539 on Saturday March 13, 2021 @08:03AM (#26446274)
There are a lot of great libraries for sure, but they aren't in the stdlib and C doesn't make it as easy to use external libraries as languages with modern tooling. Everybody gets grumpy about dependencies and a lot of people probably figure it's easier to maintain their own container code in their application than to deal with that.
Re:Speed of Rust vs. C by rocqua on Saturday March 13, 2021 @08:36AM (#26446453)
They are either based on void * with performance issues, or macro based with weird ergonomics that look like function calls, but aren't.

It's doable, but not very easy.

Re:Speed of Rust vs. C by cb321 on Saturday March 13, 2021 @09:06AM (#26446647)
You are right in a library-demographical sense, but not in a fundamental sense. There is a 3rd way. Have a look at the CTL I linked to (downvoted..maybe I should have explained more?).

Once you give up the closed source/prebuilt binary library idea and embrace the C++-like header library idea and write implemenations in terms of "assumed macro/inline function" definitions, the problem becomes straightforward with no performance issue and different ergonomics issues than you probably think.

It's a more "manual instantiation" than C++ templates or generics in other languages where just refering to them works, but most of C is quite manual. So, it fits the headspace & the hard parts of data structures/meddlesome hands remain factored out. Since you parameterize your files/code with #define/#include, you have to name your parameters which can make the instantiating client code more obvious than C++ templates with many arguments. OTOH, there is no/poor type checking of these parameters.

Re:Speed of Rust vs. C by rocqua on Saturday March 13, 2021 @02:19PM (#26449120)
I had a look, and it feels like template programming but with even worse guarantees.

Having a type declaration dependent on #define P whether it is plain old data or not, and needing to know what that means, is not the kind of ergonomics I'd want. That requires learning a whole new paradigm to ensure I am not doing wrong things.

In my mind it is so big an extension of the C language, that it leaves the C headspace and becomes its own headspace.

Re:Speed of Rust vs. C by cb321 on Sunday March 14, 2021 @07:34AM (#26454486)
Yeah. It's not for everyone. I think "different ergonomic issues" may cover that and I did mention the type checking already. :-)

It is a smaller learning curve from pure C than "all of Rust" or even "all of C++/STL". You got the basic idea in short order (that may be for ill as well as good..I was never trying to make a normative claim).

Re:Speed of Rust vs. C by cb321 on Saturday March 13, 2021 @06:38AM (#26445928)