Want all of that and a whole bag of inconsistent design choices? C++. Because, yes, one day you will meet a C++ codebase which is a mixture of "forbidden C++" and "modern C++".
Perhaps so, but reading it back takes 5 times as long.
Coming from Python and dabbling in C for embedded software, this is the one that gets me the most. It's so frustrating to be spending hours doing something you can do with one line of the regex library in Python...
Overall though I think what you may be seeing is simply the stratification of software development; what began in the 70s and 80s has come to fruition. There are different planes of existence, like thermoclines in the oceans. A developer may (and is likely to) live in one forever, without crossing above or below. Each has its purpose. While I wrote my own database and rendering engines in the 80s as part of applications development, I wouldn't dream of it today unless there was a very, very good reason. Same goes for network stacks. Or math libraries. Memory managers. Etc.
Sure, coming from the Python ecosystem, you will feel as though there is a shortage of auto-pilot-like assistance, but you must realize you are in a very different world now - Embedded work is (frequently) focused on predictability, responsiveness, efficiency, and even moreso with realtime work. You are the engineer in charge, and all the safe boundaries and cushions of the interpreted language world are now missing. Want to REALLY feel naked? Drop down to assembly on any platform and try to emit a simple "hello world." For those who have never done so, it's a humbling experience but rewarding.
Remember that C was designed as a "universal assembly language", easily portable to different architectures and close (enough) to the metal so the programmer can have full control over the machine. Best analogy I've heard: C is like a chainsaw - used carelessly one can cause enormous damage and destruction, but in the hands of a skilled/experienced craftsman, very clever solutions are possible.
Mostly because I'm used to one single place for libraries (PyPI) and I don't know how to find (and evaluate) libraries in C. I also don't know if they'll run on my MCU or how much RAM they require. I have found one or two embedded regex libraries, but they were very limited in what they could do or failed some other criterion.
Besides, that was just an example, it's just death by a thousand cuts with similar things one after the other.
you can replace C with any language. you're evangelising about the toolbox you know instead of learning about the hammer you are familiar with and don't want to learn how to operate
You probably wouldn't do that in Python; the regular expressions module is part of the language.
The Lua docs provide some examples of integrating Lua into C here - https://www.lua.org/pil/24.1.html.
If your target only has two KB of RAM, Lua is a no-go, I guess. But skill-wise, I can highly recommend it. The reference manual is very well-written, the Lua language itself is very nice and easy to learn, and Lua's C interface is very pleasant to use; and again: the documentation is very good. (Also, the community is very friendly!)
If you ever take a shot at it, the Lua Users Wiki (http://lua-users.org/wiki/) is a good starting point.
However it doesn't give you the control or the performance of C without some serious work, some of which is usually work in C!
On top of the additional testing, you also will have a performance problem at some point after success. And then people will discuss or even plan for a rewrite in a more performant, language. But we all know that rewrites usually fail to materialize. PoC's turn into products, products turn into companies, and companies bottom lines can't generally spare time and money to rewrite the entire service.
I'm not advocating for C, but I wouldn't put Python up as a comparable thing.
C code that compiles can and does blow up at runtime.
There are languages whose type systems do go a long way toward minimizing the risk of this happening, but C is not really one of them.
I personally wouldn't choose either language for a new project.
As a noob C programmer, in my programs segfaults often occur along with undefined behaviour (which is much worse, as your program will silently give the wrong output).
While in Python, you'd get a traceback which is much easier to debug.
> Requiring a massive set of tests to actually validate your code.
Both require tests to validate your code. Sure, static typing can verify some trivial mistakes, but they can't check that array accesses are in bounds, integer overflow, etc.
> While in Python, you'd get a traceback which is much easier to debug.
Well, C's segfault will also generate core dump, which is essentially the same thing as Python's traceback - it tells you where the program crashed.
C is not typesafe either, and blows up for other reasons at runtime.
Which everybody here knows and nobody doubted. So, a big duh!
What the parent means is with Python you don't need to go and install one, adjust your makefiles, etc. Regex are right there in the standard library, and things that are not are immediately usable in just a "pip install" away.
Do people actually use pip when you can just use the package manager of your distro?
The conversations that occur here generally seem much more structured.
Engineering is a life and death business more often than people think; it deserves people who feel strongly about it.
As an aside, I think the rules about trolling and personal attacks are pretty clear and easy to enforce. What I'm specifically concerned about is that those rules are evoked outside of the spirit in which they were created to attack emphasis in general. In fact, most of the discussion here is in clear violation of "Please avoid introducing classic flamewar topics unless you have something genuinely new to say about them." but obviously we rightly care a lot about this topic and, since people are acting like adults, no one needs to tap on the poster so to speak.
I appreciate that the majority of people in this forum express their opinions in a highly productive manner void of animosity, as you've just demonstrated. The previous's user's remark "Worst argument so far." did not convey this spirit. Whether intentionally or not, antipathy and pure negativity do not bring out the best of people in online forums. It is my hope that those are two things which this community seeks to discourage, but not all freedom of expression. This is how I interpreted the comment which sparked your initial response.
(I know there are some "tricks" you can use to make smaller Rust binaries by chopping things out, but of course the same applies to C. For example, I can take the C binary and just truncate the file down to 2230 bytes without breaking it)
C binaries are small because they're assuming you've installed what is ultimately the C runtime on your system (libc).
The tricks you describe are just changing the compile options to those that C uses by default.
on top of that you can apply the same tricks as C; e.g. by running strip, truncating the binary, writing a linker script, etc.
For more: https://lifthrasiir.github.io/rustlog/why-is-a-rust-executab...
Or if being verbose is desired, do you want to do a job for a computer that you are not suited to do but the computer is?
I want optimal syntactic sugar.
Like Rust or C++ templates? I prefer C syntax over the "optimal" alternative.
Can be solved by not doing stuff that are considered as undefined. Think of them as the standard's say of saying "don't do that". It's quite easy to do in most cases.
> Want segfaults? C > Want memory corruption? C > Want to write insecure code? C
There is absolutely nothing in C that makes it more prone to these in comparison to other languages. Moreover you can easily solve these by using an implementation that protects you. (such as one of the multiple C compilers that guarantee to produce safe code without UB or the sanitisers in gcc and clang)
> Want memory leaks? C
Can be easily avoided by avoiding dynamic memory allocation. Moreover nothing stops an implementation from using a GC.
> Want to write your own containers? C
This applies to all the languages as none of them happen to have an implementation of every container in their standard library. It is true that C lacks that in comparison to some other languages, however implementing the common ones (or using a library) is an extremely trivial thing to do.
> Want to spend 3x as much time writing code as a comparable C++ solution (not to mention more productive languages)? C
You must be quite the shitty C programmer to need 3 times less time to write something in C++.
I have a list of "don't do that" rules. I still do them, usually by accident.
> There is absolutely nothing in C that makes it more prone to these in comparison to other languages
If you believe that, then there's nothing I can say that will change your mind.
> Moreover nothing stops an implementation from using a GC
Many applications can't use a GC. For tiny systems, forget it.
> none of them happen to have an implementation of every container in their standard library
That completely sidesteps the fact that in pretty much every other language the containers one would like to use 99% of the time are implemented in the standard library or the language itself.
> You must be quite the shitty C programmer to need 3 times less time to write something in C++.
Only a shitty C++ programmer _doesn't_ write code 3 times as fast as they'd write C.
Throw in the level of control with sprintf() and there's a pretty clear win.
What is easier with C++ ( and most scripting languages ) are things like combinators and regexp.
As is *cat being O(N) with respect to destination length.
So easy that there's been constant flamewars over nonstandard alternatives such as strlcpy, strcpy_s... https://news.ycombinator.com/item?id=6940368
C++, D, Rust, ...
> Want to trivially import any of the huge array of existing libraries? You guessed it...
If C can talk to it, so can anything else. Granted, having the preprocessor means no bindings, but C++ has that too.
> Want to do something you really shouldn't, and any 'sensible' language might attempt to stop, but is called for right here and now...
C++, D.
Want undefined behaviour? C. Want segfaults? C. Want memory leaks? C. Want memory corruption? C. Want to write insecure code? C. Want to write your own containers? C. Want Go's approach to generics? C. Want to spend 3x as much time writing code as a comparable C++ solution (not to mention more productive languages)? C.
I've known C for 21 years now. I just quit a job as a C programmer for embedded systems. If I can help it, never again.