>Want undefined behaviour? C. Want segfaults? C. Want memory leaks? C. Want memory corruption? C. Want to write insecure code? C.

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++".

For the last decade or so writing physics engines has been a hobby project of mine; I shamefully read your comment and realized that absolutely describes my current toy. It's been in various stages of dev since c++11 was newfangled, and combined with being the "learning experience" of a programmer moving over from C; let's just say it shows... (mentally revising my plans to ever apply to C++ jobs and not just go hide in a forest)

Writing C++ is three times as fast?

Perhaps so, but reading it back takes 5 times as long.

No, not for similarly skilled writers. And C++ pushes certain pathologies into much more opaque, dark corners.

> Want to spend 3x as much time writing code as a comparable C++ solution

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...

I don't understand your complaint. There are mature regex libraries for C found with the obvious Google search. Source code included. Why would you not just pick and consume one, as you would 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.

> I don't understand your complaint. There are mature regex libraries for C found with the obvious Google search. Source code included. Why would you not just pick and consume one, as you would in Python?

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.

-I don't know how to find (and evaluate) libraries in C

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

Alright, I'm game. Where's the C library repository, and what's the manager I can use to handle dependencies automatically?

> Why would you not just pick and consume one, as you would in Python?

You probably wouldn't do that in Python; the regular expressions module is part of the language.

An alternative to the suggestion to use a regex C library is to embed Lua code into your C code. Lua+C is great for resource constrained embedded systems and can make text parsing a lot less painful than using pure C.

The Lua docs provide some examples of integrating Lua into C here - https://www.lua.org/pil/24.1.html.

The problem there is that usually you're constrained to 2 kb of RAM or so for an Arduino, so that's too heavyweight :/ Plus, it's outside my abilities currently, sadly.

> Plus, it's outside my abilities currently, sadly.

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.

Hmm, the example you posted doesn't actually look very complicated at all! And I agree, Lua is a very nice language, I've used it for other projects.

Perhaps because I've done it all my adult life, I've never understood how text manipulation in 'C' is all that painful.

I love python too. It's my favourite language for getting stuff done fast.

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!

Python let's you get stuff done fast, but it's almost more dangerous than C in some respects. Without a compiler, you run the risk of deploying code that will not run, and you don't know until that section of code is actually executed. Requiring a massive set of tests to actually validate your code.

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.

> Python let's you get stuff done fast, but it's almost more dangerous than C in some respects. Without a compiler, you run the risk of deploying code that will not run

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 completely agree. C sucks at runtime. I was trying to point out that Python sucks at runtime too.

I personally wouldn't choose either language for a new project.

Having the correct type doesn't guarantee correctness.

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.

> 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.

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.

You're actually talking about typed vs untyped, which isn't so much about C vs Python. Python is slowly acquiring static type checking (and it's working rather well nowadays).

Yes, I should have been clearer that this wasn't in support of C over Python. I'm commenting on the relative safety of Python and the downstream costs of using it.

C is not typesafe either, and blows up for other reasons at runtime.

Yep, agreed. I'm very excited about the optional type checking in Python, and can't wait for it to improve so I can use it in all my projects.

Give Cython a try, you can get huge gains in memory/speed by carefully transitioning from Python to C with it. (Or use it to "write C in Cython"[0])

[0] https://explosion.ai/blog/writing-c-in-cython

This is why (depending on exactly where in the stack you're working, and on what kind of device; I'm assuming you're developing a graphical application on an embedded device with an ARM-like CPU and a small screen for this example) you should be using Qt Embedded. It's C++, and has a very good regex library. You get the power and speed of C++ and all kinds of nice features like regexes.

Sure, but you're giving up control. There's a trade-off and there is a whole world of things which simply aren't practice to do in Python, but work just fine in C.

It's (nearly) trivial to write FSM in 'C' that do what regexp do in Python.

Yes, if you're matching constant regular expressions on an embedded device using a general-purpose runtime regular expression processor, you're probably Doing It Wrong™.

There are regex libraries for C. Worst argument so far.

>There are regex libraries for C

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.

Exactly. The biggest problem I have is just finding appropriate libraries. With PyPI I know where they are, how to get them and which one is popular. With C, I'm completely lost. I use PlatformIO's manager, but it's limited to embedded libraries, so I just don't know where to find things at all.

Its not just finding the libraries, its also marrying the makefiles.

With Linux that's trivial to know.

...google

Sure, and to get that Python requires a big runtime to be present wherever it goes. Trade-off.

apt-get install Done!

Do people actually use pip when you can just use the package manager of your distro?

I would upvote this if it weren't for the second sentence.

I think it's a bad thing that hacker news is so allergic to strong editorialization.

I do not. There is enough of it elsewhere on the web, it's nice to be somewhere relatively free of it for a change.

The conversations that occur here generally seem much more structured.

I agree that they are more structured, but I don't see any evidence that this is in any way due to how immediately people are attacked for wording things strongly.

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.

It looks like we agree that attacks are not helpful, but freedom of expression can be.

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.

D? You sure you can get a compiler for that on an "obscure platform"? Do the libraries you want to use work when the GC is off?

You can use D on platforms LLVM amd gcc support. Some libraries work, some don't. Stick @nogc on main and you're guaranteed to not use the GC. Besides, on constrained systems you're not going to be wanting many dependencies.

I love Rust with a passion, but in all fairness it does not make tiny binaries. On my system, hello world in C is 6.5k, hello world in Rust is 805k (124 times bigger). After running 'strip' on the binaries it's a little better: 4.3k vs 345k, which is better but is still 80 times bigger.

(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)

Hello world is large primarily because it statically links in jemalloc and libunwind, which are obviously fixed overhead. Both can be removed (and indeed I would expect jemalloc to be turned off by default sometime soon because each jemalloc release seems to be less stable than the last). If you do this you'll get a much healthier binary size.

C binaries are small because they're assuming you've installed what is ultimately the C runtime on your system (libc).

A direct comparison like that is somewhat comparing apples to oranges. Don't get me wrong, defaults matter, but Rust still does offer the control required to get small binaries, and, those defaults are not nearly as bad for low-level domains where one isn't using the standard library, which is where binary size is most critical. See also https://lifthrasiir.github.io/rustlog/why-is-a-rust-executab... and even http://mainisusuallyafunction.blogspot.com/2015/01/151-byte-... .

Those aren't tricks. Rust does not choose the same defaults as C, and, among other things, statically links to the stdlib and jemalloc.

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.

You're not comparing apples and oranges there.

For more: https://lifthrasiir.github.io/rustlog/why-is-a-rust-executab...

You forgot to respond to the first one: "Want minimal syntactic sugar and a language that's not prone to feature-of-the-week hipsterism"

That's a lot of words to declare oneself a masochist

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 didn't forget to respond. I consider minimal syntactic sugar a big, not a feature.

The answer to this is Scheme.

Everyone has a different idea of what 'optimal' means here.

> I want optimal syntatic sugar

Like Rust or C++ templates? I prefer C syntax over the "optimal" alternative.

Why in god's name would Rust or C++ templates be the optimal amount (or optimal syntactic sugar design)?

Well, that's my point! There is no alternative with "optimal syntactic sugar design". You have to choose between something 'minimalistic' (C) and something less minimalistic (i.e. Rust).

If you spend 3x the time writing equivalent code in C as you do in C++ you're either a bad C programmer, a bad C++ programmer, or likely, both.

Concatenate two strings with resource management in C then C++ and see which is easier.

This is a relatively trivial thing in either - depending on how you define "with resource management." I understand completely that people want to translate patterns directly across languages, but since "string manipulation with resource management" as a delta-detail going from 'C' to say, Python was a design goal, it's somewhat specious.

It's not trivial in C, it's a pain is what it is. I'd put it another way: if someone can't write C++ 3x faster than C they're not a very good C++ programmer. Maybe they're writing C with classes.

You just won't get agreement from me here - string manipulation in 'C' is quite easy. Concatenation operators and the like mostly get in the way. This has nothing to do with design approaches. The str() suite from the standard library is very easy to use safely, if you're careful in your constraints. You do have to think "this is a buffer" and behave accordingly. The resulting code is pretty tedious, but there's no way it takes 3x as long.

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.

The CVE database shows how easy it is to use correctly, bah.

Warts like no guaranteed NUL termination for strncpy and strncat if the buffer length is reached are especially fun to contend with in code reviews.

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