[scuff3d]

I'm not on the Rust bandwagon, but statements like this make absolutely no sense.

A lot of software was written in C and C++ because they were the only option for decades. If you couldn't afford garbage collection and needed direct control of the hardware there wasn't much of a choice. Had their been "safer" alternatives, it's possible those would have been used instead.

It's only been in the last few years we've seen languages emerge that could actually replace C/C++ with projects like Rust, Zig and Odin. I'm not saying they will, or they should, but just that we actually have alternatives now.

[pjmlp]

At least on PC world you could be using Delphi, for example, or Turbo Pascal before it.

Also I would refrain me to list all other alternatives.

[vbezhenar]

One could rewrite curl with Perl 30 years ago. Or with Java, Golang, Python, you name it. Yet it stays written with C even today.

[johncolanduoni]

If you’re trying to demonstrate something about Rust by pointing out that someone chose C over Perl, I have to wonder how much you know about the positive characteristics of C. Let alone Rust.

[avhception]

Your comment comes across disingenuous to me. Writing it in, for example, Java would have limited it to situations where you have the JVM available, which is a minuscule subset of the situations that curl is used in today, especially if we're not talking "curl, the CLI tool" but libcurl. I have a feeling you know that already and mostly want to troll people. And Golang is only 16 years old according to Wikipedia, by the way.

[vbezhenar]

Java might not be the most popular VM in Linux, but let's talk Perl or Python. It's installed by default almost everywhere, it's probably impossible to find a useful Linux installation without these runtimes. So writing curl with Python makes perfect sense, right? It's memory safe language, good for handling inherently unsafe Internet data. Its startup time is miniscule, compared to typical network response. Lots of advantages. Yet curl is still written with C.

I've never used libcurl and I don't know why is it useful, so let's focus on curl. Of course if you want C library, you gotta write it with C, that's kind of weird argument.

My point is, there were plenty of better options to replace C. Yet people chose to use C for their projects and continue to do so. Rust is not even good option for most projects, as it's too low level. It's a good option for Linux kernel, but for user space software? I'm not sure.

[avhception]

"[...] it's probably impossible to find a useful Linux installation without [Perl or Python]. [...]"

Oof. We seem to have very, very different definitions for both "Linux" and "useful". If all Linux installs w/o Perl or Python would cease to exist tomorrow, we'd probably enter a global crisis. Industrial processes failing left and right, collapse of wide swaths of internet and telecom infrastructure and god knows what else from ships to cars and smartphones.

Regarding libcurl: libcurl probably represents the vast majority of curl installations. curl the CLI tool is mostly porcelain on top of libcurl. libcurl is used in _a lot_ of places. For example, inside the PHP runtime. And god knows were else, there must be billions of installations as part of other projects. It's not a weird argument, libcurl is 95% of the raison d'être for curl. If you want a curl-like tool in Python or Perl, you gotta write it in Python or Perl. Somebody probably already did. So maybe just use one of these? Instead of demanding that curl be transformed into something which is incompatible with it's mission statement.

[scuff3d]

https://daniel.haxx.se/blog/2017/03/27/curl-is-c/

[i_am_a_peasant]

you took the ragebait bro :))

[lomase]

As everybody knows not a single programming language was released between C++ and Rust.

[scuff3d]

By the 90s/early 2000s C/C++ were the only widely used languages that met my criteria. Rust is the first "modern" language to meet that criteria while simultaneously offering memory safety.

If you could afford garbage collection you had plenty of options.