Hacker News Reader

Experience shows that almost every time someone writes a project like this in C, applying modern fuzzing tools (e.g. AFL) will uncover bugs that let a maliciously crafted input file hijack execution and act with the privileges of whatever's running the code. It is a lot of work to remove all such bugs (and not reintroduce any) and you never know when you're done. That is a very severe problem with C that is having devastating effects on society.

It is therefore irresponsible to use C for a new project like this, unless you know your code will never be exposed to malicious input. (Note that if you share the code with anyone else, it's hard to have such confidence.)

> It is therefore irresponsible to use C for a new project like this

So, given all this doom that hangs above my head, what should I have used?

C++ is easy to transition to.

The powerful libraries growing up around it make dropping down to the dangerous level mentioned largely unnecessary, without giving up performance.

Every time you use references in C++ you are "dropping down to the dangerous level".

Passing things by reference is safe. Any other use is mostly just pointless; it what reference types are for. If you are doing something else with them, it easy to stop.

Passing parameters by reference is certainly not always safe. You can, for example, pass a reference to a deref'ed unique_ptr into a function call, while the function call does something that clears the unique_ptr.

If you want to avoid objects containing references (or raw pointers), then you have to avoid using lots of standard library stuff --- `string_view`, C++20 `span`, or even STL iterators.

Now you are talking about pointers.

There isn't much difference between references and pointers. That is the problem.

A reference only ever points at one thing, from birth to death, and it always points at something.

No, it is entirely possible to delete the underlying object so a reference is left dangling. See https://github.com/isocpp/CppCoreGuidelines/issues/1038 for example.

You wrote "Even if I know there are better alternatives out there"...so you tell us!

You also wrote: "Not pretty, known to hurt you if you abuse it but still plenty sharp and well capable of doing the job if you treat it well."

To me it seems you know it can be dangerous, but like it too much not to use it.

> Even if I know there are better alternatives out there

I could have chosen Java, Python, Go or C++ instead. Instead I chose the tool I'm most familiar with because that will get me focused on the problem rather than on the tool. It's a disadvantage of getting older: there is less time left to waste.

> To me it seems you know it can be dangerous, but like it too much not to use it.

It is mostly a familiarity thing, not a like or dislike.

I don't know all your requirements so it's hard to say.

It is very likely that Rust would be a good choice, especially if the libraries you used have Rust equivalents.

Isn't Rust right now (1) still a niche language (2) terribly slow to compile (3) a bad fit in the first place since I don't actually know the language and (4) still immature?

As for libraries, the most important ones that I rely on deal with the loading of .wav files, writing of midi files, decoding of mp3s and fftw ( http://www.fftw.org/ ).

1) Define "niche language". Lots of people are using Rust in production. Rust isn't in the top 10 most popular languages, but it is in the top 100, and rising. 2) Compilation speed is a problem for some projects, but not for small projects like yours. 3) Understandable, but writing exploitable code because you don't know a suitable alternative language very well is not a good long-term situation. Maybe you should do something about that. 4) Define "immature". It's not one of the world's most mature languages, but it is definitely mature enough to write production code for many contexts. In many ways C is the language that needs to grow up.

There are Rust libraries for all those things (including Rust bindings for FFTW itself), though I can't speak to their quality. I can confidently say that using Rust libraries in a new Rust project is a lot easier than using C libraries in a new C project, especially if you're not on Linux.

> Lots of people are using Rust in production. Rust isn't in the top 10 most popular languages, but it is in the top 100, and rising.

I've yet to come across anybody outside of the HN crowd that knows about or uses Rust. Not a single company that I looked at in the last year used Rust, that's 41 of them and I asked every one of them which programming languages are in use.

> Compilation speed is a problem for some projects, but not for small projects like yours

ECT cycle (edit, compile, test) is a pretty big factor during early stage development. Running a test in a second versus running a test in ten seconds would ruin my day. I'm not sure what the current speed of compilation is for Rust but the only time that I looked at it (very early on) it was so slow as to be unusable from my perspective. I'd hope that has substantially improved. Think of what I'm doing as explorative programming, I'm both trying to understand the problem and trying to solve it at once.

> Understandable, but writing exploitable code because you don't know a suitable alternative language very well is not a good long-term situation.

That may be true. At the same time, Rust may not be a good long term solution either, languages come and languages go, and before I invest a year or so into a new eco-system I'd like to see it has staying power. It is interesting that you recommended Rust and not say Java which has pretty good performance, is memory safe and is in production for well over a decade, for this particular use case I would choose that over Rust.

> Define "immature". It's not one of the world's most mature languages, but it is definitely mature enough to write production code for many contexts.

There isn't a month or we see an announcement of the next point release of Rust on HN. I don't have the luxury of tracking a moving target next to working a full time job and having a family, then doing this hobby project besides. If Rust wants to see mainstream adoption for stuff like this because you seriously believe that writing a new project in C is irresponsible (which smacks of FUD, and is one of the reasons why I think Rust is one of the more toxic language communities on the internet, I have never seen a Java proponent use that kind of language) then I hope you agree that getting Rust to some kind of long-term stable form in the very near future is a must. This whole 'the sky is falling' tactic is rather off-putting, at least, it is to me. The same happened to perl, which was supposed to be - and still is according to some - the best thing since sliced bread.

> There are Rust libraries for all those things (including Rust bindings for FFTW itself), though I can't speak to their quality.

That's good to hear.

> I can confidently say that using Rust libraries in a new Rust project is a lot easier than using C libraries in a new C project

For you, as a Rust user, yes. But you are forgetting that for me that is not at all easier, and that using C libraries in a new project is a lot easier than using Rust libraries for me because I happen to know how that works.

Vantage point is a bit of an issue here, I take it that you are fluent in both Rust and C and that you have decided to hitch your wagon to Rust. I'm fine with that and no doubt in the long run you will be proven right but to me it smacks of 'you should do as I do' rather than that it is the best for me.

Learning a new language just for some project is a very high degree of friction to add, it would slow me down tremendously and it might lead to the project being abandoned rather than progressing at a quite acceptable speed given my constraints in time.

> especially if you're not on Linux.

I wouldn't dream of developing software on anything else, but I totally respect other people's choices in their platforms.

> I've yet to come across anybody outside of the HN crowd that knows about or uses Rust.

Interesting. High school students and university students that my kids know are using Rust (in New Zealand, not some high-tech mecca).

> Think of what I'm doing as explorative programming, I'm both trying to understand the problem and trying to solve it at once.

OK. I might recommend Julia then.

> It is interesting that you recommended Rust and not say Java which has pretty good performance, is memory safe and is in production for well over a decade, for this particular use case I would choose that over Rust.

Sure, Java sounds like a fine choice. I didn't know much about your requirements when I suggested Rust. People often choose C because of strict performance or deployment constraints, which Java often can't meet, which makes Rust often a safer recommendation.

> There isn't a month or we see an announcement of the next point release of Rust on HN.

That's because they release every six weeks. That doesn't mean the language is unstable or you will keep having to make changes to your code. It means there's a steady flow of incremental improvements that preserve backwards compatibility.

> you seriously believe that writing a new project in C is irresponsible (which smacks of FUD, and is one of the reasons why I think Rust is one of the more toxic language communities on the internet, I have never seen a Java proponent use that kind of language)

In hindsight I shouldn't have mentioned Rust at all. I do sincerely believe that propagating C code is irresponsible and the software industry needs to recognize this. It sounds harsh, but I think that's partly because software developers have historically taken too lightly the consequences of their choices (even for hobby projects).

People like me who are zealous about the industry moving away from unsafe code tend to be big Rust fans, because Rust finally makes that possible for the systems/embedded domain where C/C++ were for such a long time the only viable option. I guess we have skewed the Rust community to some extent. Mea culpa.

> it smacks of 'you should do as I do' rather than that it is the best for me.

When we write code and distribute it, we have an effect on the world, and then I think it behoves us to consider more than just "what is the best for me".

For hobby projects where the code is never distributed, these issues are mostly moot ... though it's amazing how often such projects escape sooner or later.

> I do sincerely believe that propagating C code is irresponsible and the software industry needs to recognize this.

I believe that you are sincere in this. At the same time I ask you to recognize that the way you - and many other proponents of 'safe' (safe between quotes because computer programming will never be safe) languages approach this is combative and therefore ultimately un-productive.

The old proverb says that you will catch more flies with honey then with vinegar and headbutting with people and calling them irresponsible is not going to get you where you want to be. It will have the exact opposite effect, people will dig in and their resolve will strengthen rather than weaken. This is because people tend to be invested in their tools and their creations. Going for a full on frontal confrontation about this is counter productive, that's just human psychology, which is in cases like these as important - if not more important - than having a technological edge or being right.

Zealotry is the last thing you want to take with you in your toolbox if you want to make change.

That's a good point, but it assumes the only audience for this conversation is developers already emotionally attached to C, which I don't think is true.

Check the title.

> Rust finally makes that possible for the systems/embedded domain where C/C++ were for such a long time the only viable option

To be fair other languages where there first, they just lost due to UNIX uptake across the industry.

Had any of those language been more sucessful regarding adoption across mainstream OSes, and a language like Rust wouldn't be required.

Not clear what "other languages" you mean here.

GC is a problem for OS/embedded programming. And before Rust, safety required GC (or an unpalatably restrictive programming model like MISRA). Even if Symbolics or the C# Windows Vista work had been more successful, Rust would still be needed.

Rust or modern C++, although the abstractions on the latter are leaky

I love the (seeming) resurgence of C, Rust, and C++ articles on HN. Not sure if it's robotics, IoT, webdevs longing for simpler and stricter frameworks or what. But I love it.

For me, it’s embedded. So I use C, mainly because as a professional company releasing a real world product my only other choice is C++ and I haven’t found a “need” for it yet.

The best language is usually the one you know!

Just like the best camera is the one you have.

Can't tell if sarcastic. I'm not a professional photographer but for me the time to pick up a better camera takes a couple seconds... :)

I think we also choose our favorite programming languages based on our psychology, not only the technical features.

The ones who like C and C++ are like Toretto from the Fast and Furious franchise choosing a classic muscle car for a race. They are super fast, give you much more options, but because of that, they are not the safest.

A muscle car requires more skill to drive and win than a modern fast-shiny-and-safe car. But because you know they are more dangerous to drive, is likely that you will try to improve your skills to make it less likely to have an accident with it.

Thats one of the reasons why im still skeptic to jump into the Rust bandwagon, once you turn into a good muscle car driver, its hard to choose for safer but more limiting options, but you totally get it why someone without experience in fasters cars would choose for the safer version.