Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'd be curious how C (and C++ for that matter) stacks up on some arbitrary "freshness" metric that measures some kind of statistic/statistics that indicate the average/median time it takes for the population of engineers to reach some particular level of "done"ness with a language.

I have no idea how you would measure it, but I'm assuming that C, VBScript, Perl, sed, AWK, bash, and Haskell (please don't hurt me I'm thinking about the code maintenance, time draining nightmare that is a real-world use case of mega-scaled purely functional codebases as opposed to a mixed dynamic with a purely functional core).

Curious what other languages would top the list. I'm going to assume also that some low-barrier entry scripting languages that are well designed, similar to Python, and languages that save the hypothetical, proverbial broken backs of their ancestors, like Rust, to be near the bottom of the list. I'm curious what that bottom part of the list would look like too, oddly enough. :D :))))



C is an amazing language. If you want to integrate into another language via FFI you basically have 0 other options.

That being said, it’s too easy to do something wrong in C. The desire to use Rust isn’t because C is stale, rather it’s too hard to write C correctly.


"amazing language"

ye ye, sure it is

uses physical pathes instead of logical namespaces for includes

average code base could be summed in such a way: everything is fucking "int" or its cousin - such a great tool for system modeling!

basic concepts as for $current_year are still non-trivial in C - like strings

when opening non-trivial codebase my VS Code goes crazy.

Maybe I do have high standards after using C# for years, but holy shit, writing Rust is 10 times better experience for me than using C.


My desire to write Rust is for both reasons. C tooling is awful, the language offers insufficient abstraction capabilities, and, finally, is unsafe.


Rust and C++ both have C FFI boundaries that the compiler can inline across. What more do you want?


Well for one, I don’t want to add another language to my tool chain. Many languages can compile C directly. For instance in Swift or Go you can add C source files directly to your project and have them compile as part of your Swift or Go build. You can’t do that with Rust or C++.

C is the lingua franca of the software development world.


Er....


Modern C++ now has nearly all of Rust and other modern language features built in, some as flags. At the same time it has 30 years of ecosystem, cruft, and bad habits. It’s entirely possible to write performant, memory safe C++, even in a functional style. It’s a bazooka, and won’t stop you from firing at your feet, but it is also the right tool for big jobs.


The main problem with C++ is that it's too vast, it does everything and everyone has its very own choice of a subset of the language he should use.

The result is codebases hard to navigate, code hard to undestand with lots of clever code and unintuitive syntax.


Except... you know... the most important feature of Rust... the borrow checker.


The last time I checked, there were only nascent efforts to add the borrow checker to C++.

That's the main reason to implement in Rust (the others being syntactic sugar like match, ?, and, of course, the library ecosystem that learned from ~ C++17's mistakes).


It still lacks memory safety.


I would also really love to read a statistics-based approach to all of modern software engineering. Like, does SOLID actually increase bugs? Is Agile more likely to slow things down? Etc.

This is the closest I’ve ever found: http://www.knosof.co.uk/ESEUR/


It strongly depends on the type of software being developed.

As the abstract of that book suggests (when referring to ego and bluster), 100% of the agile proponents I have encountered are incompetent. (This especially includes organizations that claim they are "agile").




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: