[mamcx]

> ... use of the freedom C provides (while being unsafe) you have the ability to implement whatever complex algorithm you can envision

This is highly misleading. That is not true. At all.

Just take a sample: Do you write OO on C? No, because C is a terrible OO language. Do you write short optimized array-oriented code on C? No, because C is not APL.

People write C how people write C, the way C make them write it.

Moving into other paradigms, you see things differently.

Rust makes a lot of idioms that are inexistent on C viable: Algebraic types alone will shape the way you do algorithms by a lot. Then they push for better errors, then know exactly where things alloc, etc.

Coding in Rust is distinctly different from code in C. It is like the best way you can refactor a codebase: You come for the safety and tooling, you stay because the algorithms write better themselves.

[surajrmal]

Writing oo style code in c is extremely common. At least where I work we often pass around structs of function pointers to accomplish roughly the same thing a vtable would give you and name methods such as foo_verb for methods that operate on struct foo.

An algebraic data type is just a c union with an auto generated flag and moving some type validation to compile time. Unions used in this manner are quite common in C. I do think the increased ergonomics and safety exist, but only when paired with other features like pattern matching. Selling algebraic data types alone as the major novel feature improvement is a bit misleading and dismissive of existing c features.

I do agree that additional compile safety in rust makes it far easier to confidently refactor without introducing bugs. Accomplishing the same in C requires a lot of unit tests which add maintenance overhead. Python is a more extreme example of that playing out. That all said, I don't think it's necessarily relevant to writing a performant scheduler.

Rust has many strengths and I endorse using it over C any day. That said, the way it's marketed feels misleading and gives experiences c developers bad vibes.

[the_third_wave]

> Do you write OO on C?

Yes, have a look at GTK, GOBject and parts of Gnome.

> Do you write short optimized array-oriented code on C?

If you want to stay close to C you'd use something like SAC [1] but no, pure C is not an array programming language.

> People write C how people write C, the way C make them write it.

C is sometimes called 'structured assembly' for a reason: it is a toolbox which can be used to construct things the way you see fit. This does mean you need to involve yourself more with certain implementation details since C itself does not force you to use any specific paradigm and as such does not provide you with the basic tenets of those paradigms. If you want to do OO in C you'll have to provide a pointer to the object you're working on in any function call related to that object since C does not assume there to be a 'current object'.

Does this mean C is the most optimal language to do OO programming or array programming? No, clearly not, this is why languages like C++/Java and APL were created. On the other hand it does mean that it is possible to do these things in C and - given the success of Gnome and GTK - doing so can be a viable proposition. The advantage of using C is that it is nearly universally portable, more so than many other languages.

So yes, use of the freedom C provides (while being unsafe) you have the ability to implement whatever complex algorithm you can envision is actually true in that it is possible to do so. You may not want to use C for these purposes but that is irrelevant when considering whether it is possible to do so.

[1] https://www.sac-home.org/index

[hajile]

Isn't GTK effectively dynamically typed in C?

[Ferret7446]

OO and other paradigms are not algorithms. They are particular ways of organizing code. Any algorithm can be implemented with OO, FP, or plain procedural style. Objects can be closures. Loops can be TCO recursion.