
Addendum to “Curl is C” - mirceasoaica
https://daniel.haxx.se/blog/2017/03/30/yes-c-is-unsafe-but/
======
spoiler
> These “you should switch language” remarks are strangely enough from the
> backseat drivers of the Internet. Those who can tell us with confidence how
> to run our project but who don’t actually show us any code.

This is an usual problem with people participating in discussion over the
Internet. I am sure those people mean well, but often they don't put enough
effort into assessing the situation and underestimate its complexity before
they decide to hit the keyboard. I've myself done it a number of times, but I
am working on not doing it.

Advice for the people who are making all these suggestions and: A good way to
see if you're talking out of your ass—unintentionally, of course—is to try to
do what you're saying someone should do. Just try and re-write some parts of
curl in Rust (you can go with a hip name like rurl). It's a good exercise to
learn about the project you're rewriting, the language you're writing it in,
and the problem domain. So, at the very least you'll get something out of it,
and if your project is successful: even better!

~~~
muraiki
I think that you express a fallacy. You're saying that nobody can provide
thoughtful criticism unless they take up the task themselves. So the next time
you criticize politics, are you going to run for office? The next time you
criticize a meal, are you going to become a chef? The next time you criticize
a car, are you going to become an engineer? Yes, it's one thing to make
thoughtless and uninformed criticism. But providing thoughtful and useful
criticism does not necessarily require actively creating something from
scratch. Otherwise, we would all only be starting new projects and never
collaborating!

~~~
jacquesm
No, he's spot on. The one thing that keeps happening over-and-over again is
that people who have never put together a system of any complexity will yell
from the sidelines how _others_ should build their stuff.

This goes for operating systems, application software and advanced rocketry
alike.

The reason we have so much C code powering the world is that (1) there wasn't
anything better when that code was written, (2) time has weeded out most of
the bad bugs to the point that the old codebase will be substantially more
stable than anything new no matter what language you would write it in.

If someone is willing to throw a few hundred million or so at re-building an
operating system from the ground up that is 100% safe and reliable and that
does not have more bugs than what is available right now then they are free to
do so. They're also free to donate their own time and to try to enlist their
buddies. But they're _not_ free to yell at others how those others should do
their jobs.

Show don't tell.

~~~
acqq
Exactly, show don't tell. And when I point to the fact that the Rust codebase
itself has a lot of "unsafe" places I get the explanation "yes, but it's an
old code and we haven't had the time to rewrite it to use the newer features
that would allow more safe code."

Think about it: the people who design Rust don't have the time to rewrite
their own Rust code to be safe.

When there's no time to rewrite the code of Rust to be demonstrably safe, why
should any other project have more time than that, where the programmers know
Rust much less or not at all?

Maintaining the successful project is hard and takes a lot of time, even
without switching to something new.

Second point: look at the Benchmark game, a fast Rust code example also
typically has an "unsafe" code. So it's still not even demonstrated that "you
can have it both fast and safe" holds for these examples. Fast as in "as fast
as C" and "safe" as in "provably safer than C."

Finally, I believe that the language should simply implement a language-level
no-cost check for integer overflow, as the machine languages already have, and
not complain that there aren't some special mechanisms in CPUs to do it
differently. It's your language's failure if you can't use what already
exists. The CPUs already can do it, the high level languages don't provide the
high-level access to it. Which doesn't matter for C which is "unsafe" by
definition (and where it's natural to call some asm when needed) but it should
for Rust which goal is to produce a more provably "safe" code.

Writing unsafe Rust instead of unsafe C is not giving you any real advantage
for the existing projects, as long as the state is as it is.

Also, look how Rust uses TLS. Is safely rewriting a crypto library which is
useful in real project still a too big task to be taken?

I like the perspectives of what Rust could bring. But I'd like to see a real
life case of its success too.

~~~
staticassertion
> Writing unsafe Rust instead of unsafe C is not giving you any real advantage
> for the existing projects, as long as the state is as it is.

Your argument hinges pretty heavily on this. It's incorrect. The reality is
that unsafe code in rust is not like unsafe code in C. First, it's bounded to
a module. Second, you can grep for it (huge). Third, you still have less UB in
unsafe rust than in C.

I've never written code in rust that required unsafe, after many thousands of
lines.

> Is safely rewriting a crypto library which is useful in real project still a
> too big task to be taken?

[https://github.com/ctz/rustls](https://github.com/ctz/rustls)

?????????????

> But I'd like to see a real life case of its success too.

Ripgrep is a nice one to point to. There's redox too. Tons of rust code out
there.

~~~
acqq
> It's incorrect.

> I've never written code in rust that required unsafe, after many thousands
> of lines.

That illustrates the level of understanding of those who argue that curl
should be rewritten in rust. Bravo.

~~~
steveklabnik
Why, specifically?

~~~
acqq
It's self evident. One personal and very small example (many thousands is
obviously less than 10 thousand) doesn't prove anything.

curl has an order of 120000 non-empty lines in c and h files.

The person who made statement of "many thousand" probably made toy
applications, compared to something like curl.

More realistic would be to compare something that should have been made in
curl: like the "ring" library you mentioned as a Rust answer to "openssl."
Which is neither an openssl nor written in Rust.

It is far from providing the functionality of openssl. The author states that:

"ring exposes a Rust API and is written in a hybrid of Rust, C, and assembly
language."

"ring is focused on general-purpose cryptography. WebPKI X.509 certificate
validation is done in the webpki project, which is built on top of ring. Also,
multiple groups are working on implementations of cryptographic protocols like
TLS, SSH, and DNSSEC on top of ring."

Actually a wrapper, and actually much smaller than openssl.

Second, "ring" has just some 9000 lines in rs files but 13000 lines of C (as
it is defined by the author to be a wrapper, not surprising). So it is still
just a wrapper around the C, still orders of magnitude smaller than curl, and
still unable to be actually written in Rust.

On that level, I guess the Rust people would call curl the Rust application as
soon as a few .rs files would appear in curl code base. Or not.

It's simply has no sense, supporting Rust with misinformation instead of being
honest about its current limitations regarding what's actually implemented and
what actually doesn't use "unsafe."

It's obvious that those who suggest to others to rewrite the big projects in
Rust should first show that they managed to make some much smaller safe code.
Especially that they managed to make some meaningful full-Rust and safe
libraries.

~~~
steveklabnik
See, this is much better of a comment than the above, which was mostly an
insult, with no substance.

(I don't agree with much of this but that's not the point; my point was trying
to raise the level of discourse around here.)

------
DCKing
There are many reasons why curl uses C, and should continue to do so. Yes, C
allows a combination of portability, performance, and accessibility of your
source code by others that is not matched by any language. And yes, C was a
perfectly valid choice throughout the vast majority of its life and still is.
Switching is not a realistic option at all.

But I think Daniel's original attempt at explaining away C's security issues
has been debunked. And I think he owns it well by singing a slightly different
tune in this blogpost.

The lesson learnt here is that if you use C, don't try to explain away the
security issues you have just opened for yourself. _It will not hold up_.
Accept that the safety of C is a very serious issue, and that there are other
reasons you choose it. Choosing C over more secure options does not mean you
don't care about security, but it means that you had to make pragmatic
choices. Choosing C over more secure options and subsequently attempt to
minimize the security impact of this decision (not talking about Daniel here)
will lead you to not addressing those issues effectively.

~~~
generic_user
> Choosing C over more secure options and subsequently attempt to minimize the
> security impact of this decision (not talking about Daniel here) will lead
> you to not addressing those issues effectively.

When you start a new C/C++ project in 2017 you can effectively and confidently
address security and 'safety'. And it is done on a regular basis.

There is an entire infrastructure of tools and introspection refined over the
past 30+ years for C/C++ that is part of the project from the beginning.
Address sanitizes, Better compilers, Valgrind, Intel's tools etc.

All of the potential problems are known and there are tools to deal with them.
But the responsibility is put in the hands of the programmer like many other
things in C/C++.

~~~
DCKing
I do get a vibe of tone deafness coming from such a reply.

1) You're stating that automated tools are a solution in a thread in a
blogpost for a heavily scrutinized tool that has a zero tolerance policy for
Coverity problems, uses Valgrind and address sanitizers _and still owes more
than half of its CVE 's to various language and memory safety issues_.

2) "The responsibility is in the hands of the programmer" \- I think we have
argued enough that putting this responsibility in the hands of very imperfect
programmers _is precisely the problem_ and we should do the best we can to
stop it.

You're minimizing C's security issues again, please stop doing that.

~~~
generic_user
You could make the case that the reason why we have C/C++ and its still in use
is because of the tone deafness of academic language designers.

Language designers have been arguing (mostly with themselves) since the 1970's
that pointers are dangerous and memory management is bad and that programmers
should not have those things.

We can go on using C/C++ and language designers can go on creating there new
version of Pascal. We all know how that turned out.

> I think we have argued enough about that putting this responsibility in the
> hands of very imperfect programmers is precisely the problem and we should
> do the best we can to stop it.

System designers and those writing performance critical code program hardware.
Not an abstract machine that the language designer thinks is good enough for
lowly programmers.

Convince Intel and AMD, Nvidia etc, that they should make chips and
instruction sets that have no access to memory, cores, vectors and so forth
because 'we should do the best we can to stop it'. Lets see how many of there
clients want to buy useless blobs of silicone.

A computer is a tool for computation not an adult diaper designed to prevent
leaks.

~~~
DCKing
We've gone from arguing "the security issues for C are overrated" to now
arguing either "security issues don't have solutions I like" or "real
programmers should be able to deal with these things" (I'm not sure which).

In addition, you're arguing a strawman. Nobody says that direct memory access
should be taken away permanently. Many 'safe' languages allow you to directly
access memory when you need it.

> A computer is a tool for computation not an adult diaper designed to prevent
> leaks.

This attitude is why we can't have nice things. It would be great if you cared
more about the security and safety of the things you make than whether you
look cool while making them.

~~~
generic_user
> We've gone from arguing "the security issues for C are overrated" to now
> arguing either "security issues don't have solutions I like" or "real
> programmers should be able to deal with these things" (I'm not sure which).

I don't think anyone was arguing any of those points. What was being explained
is that C/C++ is designed to be flexible and simple and it was know from its
inception that that flexibility lets the programmer 'shoot them selves in the
foot'. Building out tooling to address any error patters in usage and keeping
that basic simplicity and flexibility is desirable. More desirable then moving
to a more complicated less flexible language that may eliminate some possible
errors.

There are literally millions of C/C++ programmers and projects writing secure
reliable code. Picking out a few open source projects and turning there bug
reports into an internet drama is not going to convince anyone the sky is
falling.

> In addition, you're arguing a strawman. Nobody says that direct memory
> access should be taken away permanently.

I think its fairly clear that the sentiment was.

"putting this responsibility in the hands of very imperfect programmers is
precisely the problem and we should do the best we can to stop it."

This has been the justification for every misguided attempt to 'make things
better' for a very long time.

A short list of unnecessary things that needed to be stopped thought the
years. * Pointers * Manual memory management * Unconditional Jumps * direct
access to machine words ie bytes * assembly instructions. etc..

I am fairly skeptical of arguments that suggest 'the programmer does not need
that'.

~~~
DCKing
> There are literally millions of C/C++ programmers and projects writing
> secure reliable code.

I believe that there are millions of C/C++ programmers that _think_ they are
writing secure reliable code. But these there is an overwhelming amount of
evidence that they don't and (for C at least) can't. There is plenty of
evidence that at least C does not give you the proper tools to actually write
safe code outside of trivial programs in the first place. (I cannot speak for
C++)

You're still arguing a strawman. Nobody wants to take away your pointers,
manual memory management, unconditional jumps or assembly, and nobody is
suggesting that you don't need them. People just want to make it easier to use
them responsibly without making the mistakes everybody keeps on making all the
time.

~~~
generic_user
Those Millions of C/C++ programmers have certainly accomplished more and have
happier lives then the Tens of armchair safety experts groking internet drama.

In my experience the people who wring there fist at C/C++ are generally people
who at one point tried C/C++ and either got frustrated and quit or got told
they suck or turned down at job interviews. Or they are people trying to sell
you the new hotness and have some personal gain to accomplish. People I know
who did some C/C++ and now work with other languages could care less about
replacing C/C++. They just do there thing.

And honestly, academics and busybodies have been whining about safety and
memory and hating on C/C++ for decades. We need to get rid of it. It smells,
its bad for your teeth etc. Creating a never ending stream of total crap
programming languages that no one wants to use. That never actually do what
there creators propose that they do. And that never replace what the say they
want to replace.

Even some crusty C++ programmers still hate on C coders and how did that work
out for them :)

------
nallerooth
I wonder how much experience people yelling "OMG you're using C(++) - you have
to rewrite everything!" actually have. Some of them can motivate their claims
with good examples (at least to some extent) while others just show a serious
lack of understanding of project scope and/or the reason something is written
the way it is.

One of my favorite examples so far: [https://www.postgresql.org/message-
id/CAASwCXdQUiuUnhycdRvrU...](https://www.postgresql.org/message-
id/CAASwCXdQUiuUnhycdRvrUmHuzk5PsaGxr54U4t34teQjcjb%3DAQ%40mail.gmail.com)

~~~
buserror
Ahah nice example! "I can't code, but if I were, I would like to be productive
in something that doesn't require me to make any effort in understanding the
problem, please advise"

I don't know where all the C hate is all about. I love C, it's a great tool.
Can be quite sharp, be careful with your remaining fingers.

I spent the better part of last week studying rust and go, and my conclusion
was 'meh, I'll have another look in another few years" and kept on trucking.

~~~
nallerooth
I don't get all the C "hate" either. Sure, C is a source of many "interesting"
things - but it's also a natural part of control systems in avionics, space
craft and nuclear power plants. I don't want someone who just read that "Rust
is a great, safe language" to rewrite those. I really don't.

~~~
fiedzia
And I do. Planes crashed and people died because of buggy software. We have
lost Mars climate orbiter due to not using type-safe language. In the cases of
software that works fine, we are just relying on ridiculous amount of manual
verification, and this is both risky and expensive.

~~~
zuzun
> We have lost Mars climate orbiter due to not using type-safe language.

One company creates a closed-source component that produces a float, another
company creates a closed-source component that receives a float. Units differ.
Crash. No type-safe language will prevent that bug from happening. Let 100
programmers write these programs in your type-safe language of choice and all
will be vulnerable to this.

"Oh no", I hear you say, "we'll give every unit its own type" and it still
won't stop your programmers from deserializing a 4 byte value in English units
into the metric value they think it is. "So we'll make all the IO typed as
well!" You don't need a type safe language to do that. And why would you do it
in the first place? If your API spec says you receive a float in metric units,
you write your program accordingly. When you're writing mission critical
software, would you really want to replace a

> read(sensor, &value, sizeof(float))

with 100k lines of even buggier code to prevent a bug from happening that
shouldn't happen in the first place?

~~~
fiedzia
> Let 100 programmers write these programs in your type-safe language of
> choice and all will be vulnerable to this.

Some will be, some will define inteface as float_meters and define automatic
conversion from yards, avoiding whole issue.

------
jasode
_> I think that’s missing the point I was trying to make._

I think Daniel Stenberg missed the point of some of the comments. (At least
the prominent ones I saw.)

 _> We use C for a whole range of reasons as I tried to lay out there in spite
of the security challenges the language brings._

The availability and practicality of old ecosystems are valid justifications
but it's _orthogonal_ to the "memory bugs caused by the language vs the
human".

There's nuance and you have to distinguish multiple conversations:

1) curl should have _been_ written in a memory safe language (past tense)

2) curl should _be_ rewritten in a memory safe language (future tense -- e.g.
maybe use Rust)

3) setting aside curl's 19 years of wide _deployment_ challenges, D.S. could
have been a better spokesman for the benefits memory safe languages

Daniel's response is mostly to #1. However, some of the criticism is really
conversation #3. Understandably, #3 is somewhat harder for D.S. to adopt
because it requires distancing himself from the 19 years of curl as a
successful utility and instead, consider how a language's design affect
programmers' bug count. Many felt that D.S. citing curl's bugs as "human logic
errors" instead of "language-induced errors" undermines his point when
conversation #3 is the framework.

So maybe some of the new nitpicking of counting CVE bugs is more about
conversations #2 & #3. The #2 may not be realistic for another 10 years... or
maybe never because of various deployment hurdles. However, we can still
discuss #3.

~~~
hsivonen
I think this is the disconnect. One can understand why curl is written in C,
not expect Daniel to write it in another language, appreciate that the overall
vulnerability count being impressively low considering how old the project is,
and still worry about the section about vulnerabilities in the original post
looking dismissive when it comes to vulnerabilities that are attributable to C
and perhaps getting trotted out in the future by others contemplating new
projects as an excuse not to use a safe language.

~~~
empath75
Yeah, I absolutely think that curl should stay a C project until the day it
dies. I also think someone should write a curl-alternative in rust. And at
some point, people may start using the Rust version instead of the c version.

------
sapphire_tomb
I wish people would get off Daniel's case about this. If you want to re-
implement curl in rust or whatever, no-one's stopping you!

------
spion
I don't think the reactions and comments were meant as an attack on curl, but
more as an attacks on C.

Most programmers who attack C have seen the consequences of a memory-unsafe,
type-unsafe language dominating systems programming throughout the years. I
remember the period during the early 2000s when "buffer overflow exploits"
were an entire industry. I also remember the strange allure of C and C++ in
beginner programmer circles. The logic goes something like this: "they are
powerful languages, all of the big and popular software projects are written
in them, so they must be the best". Their next step was to go on to start a
new generation of unsafe and vulnerable programs and libraries, and so on.

Now that we have the tools and technology to do better, we should really be
making some efforts to push for them. The goal isn't change _right now_ , but
starting the process early seems like a good idea.

~~~
wott
Most programmers who attack C at the moment are frontend web javascripter kids
and rust/functional language snobs, who both never used C and keep repeating
the same stuff.

You just have to witness the number of "OMG, you did that in C? Wow!" that are
posted every time someone posts a basic C program on a forum. There is a whole
crowd that thinks C is some arcane stuff only to be used by by magicians, and
if you're not a guru it's gonna kill you.

And then you have the Rust people who chime in and point a list of C problems
that are in fact C++ problems.

And then you get the "but anyway modern processors do not execute the code you
tell them to execute" guys. Sigh...

It goes every time the same way...

~~~
eeeficus
well it's 2017. maybe it's time we get rid of C? :)

~~~
endisukaj
Lisp is even older than C, should we get rid of that too?

------
TorKlingberg
Everyone will just have to accept that Daniel is not going to rewrite curl in
an other language. If you want curl in Rust, a Rust programmer will have to
step up and do it.

~~~
agumonkey
Let's call it Crust

------
kbenson
_curl is currently one of the most distributed and most widely used software
components in the universe, be it open or proprietary and there are easily way
over three billion instances of it running in appliances, servers, computers
and devices across the globe. Right now. In your phone. In your car. In your
TV. In your computer. Etc._

 _If we then have had 40, 50 or even 60 security problems because of us using
C, through-out our 19 years of history, it really isn’t a whole lot given the
scale and time we’re talking about here._

I think there's a disconnect here. Given something that's has a thousand
instances running and averages 20-30 security problems a year and something
else that has _over three billion_ instances running and averages 2-3 security
problems a year, which one do you think I care more about? I care about the
one running everywhere, and on devices which may never see updated code in the
rest of their lifetime.

If curl were some unused project this wouldn't be a conversation. At the point
where your code is on all those devices, you will get scrutiny. Expect it.
Your choices may have some impact on a significant portion of the Earth's
current population.

At the same time, it's not fair to expect curl to rewrite their project in
some other language. Some other project can start with the goal of providing
the same API as curl (or not) that attempts to mitigate security problems
though a different code architecture or language, and maybe curl devs will
contribute. But expecting curl devs to start over from scratch is not
feasible.

------
mbrock
The phrase "worse is better" was coined precisely to explain the success of C,
and I consider that paper required reading for entering this discussion.

~~~
milesrout
"Worse is better" has nothing to do with it. Stop saying it every time
anything you think is bad comes up. It's incredibly arrogant, the way people
basically spam "worse is better" like they're in Twitch chat every time C,
Unix, HTTP, or anything else that they perceive as imperfect comes up.

~~~
mbrock
But I do consider that article a good explanation of the tremendous success of
C and Unix, and I think its perspective should be part of these discussions.

------
kazinator
The best feature of Curl is that you can use it as a child process, driving it
through the command line interface of its principal executable. Quite a lot of
the API-level bells and whistles are covered.

A few years ago I looked at the API and internals and went, "gack!" No way am
I integrating this dung heap at that level; let the users just wrap the
process with a _curl_ function that returns a process pipe stream if they want
to use this.

------
AndyKelley
I wouldn't advocate for the curl project to experiment with rewriting some
code in [Zig]([http://ziglang.org/](http://ziglang.org/)) yet, due to lack of
maturity, but it is exactly in the target niche of the project. That is, near-
seamless integration with a large pre-existing C codebase.

So you could, for example, take a 400 line C file, convert it to Zig, and have
it import the .h files that the previous C file was including, and export an
.h file for the rest of the codebase to look at. The compiler can turn this
Zig file a .o file that integrates with the rest of the build. The part of the
codebase written in Zig could benefit from the safety features, generics, and
error handling features of the language while presenting the same interface to
the rest of the codebase.

Now of course, if you already have a codebase written in 1 language, it's more
complicated to introduce another. This is where the Zig build system comes
into play. I'm working on this now, and it's a competitor to autotools, scons,
cmake, make, and all those players. It's the Zig programming language with a
declarative build system API built into the standard library with some basic
tooling around it, and it ships with the compiler.

So if the Zig build system gets to the point where it is high quality enough
to attract users and ubiquity in package managers, then a project which
already uses Zig for its build system can start using it for its actual code
without the penalty of adding a dependency.

In conclusion, once Zig has reached a stable enough state, I would challenge
the libcurl devs to consider, perhaps it could make sense to slowly,
carefully, methodically transition to a newer language, if that language was
friendly enough to the process.

~~~
stirner
What does Zig have to offer over Rust's FFI[1]?

Also, it might be useful to know that HN's comment syntax isn't Markdown,
though it shares a few features like indenting for code blocks and asterisks
for italics. Markdown-style links are not supported.

[1] [https://doc.rust-lang.org/book/ffi.html](https://doc.rust-
lang.org/book/ffi.html)

~~~
syrrim
Of course, not only are markdown style links unsupported, nothing but raw urls
are supported as links. For whatever reason, the majority of people here
choose to relate links to locations in text using a particular footnote style.
Since this format is no more blessed than the common markdown style, they
could have easily chosen that instead. Presumably, they didn't because it
breaks flow when using long links. For short links, like the one in the GP,
inline links work just as well as footnote based ones, and provide the extra
benefit of not requiring scrolling to follow them.

~~~
stirner
If there's no need to tell a parser where the link text begins and ends, then
putting the URL in parentheses after the relevant text (without square
brackets) would be less fussy.

The "HN style" of citation/linking is basically the IEEE citation style. You
could call it "blessed".

[http://www.ijssst.info/info/IEEE-Citation-
StyleGuide.pdf](http://www.ijssst.info/info/IEEE-Citation-StyleGuide.pdf)

[https://www.ieee.org/documents/ieeecitationref.pdf](https://www.ieee.org/documents/ieeecitationref.pdf)

------
legulere
He writes "way over three billion instances", I read "way over three billion
vulnerable instances" which is a security disaster.

------
simias
I think most of the points he made in his original post are very valid ones,
it's just the fatalist "devs are going to create bugs, such is life" approach
to errors that I _think_ I glimpsed in the original post that prompted my
response in the previous thread. I'm tempted to call it the "C Stockholm
syndrome".

The reason I say that is that I could actually have written something like
that a few years ago myself. I think it's a pretty common mindset amongst the
"low level" C crowd. And there's a good reason for that, we've been burned
before.

People have been advertising "safe" alternatives to C since forever. Use Perl!
Use Java! Use Lisp! Use Haskel! Use Python! Use Go!

But none of these languages can replace C in all of its use cases. You have
big runtimes, garbage collection, interpreters, you name it. You can't just
bootstrap a stack pointer in 3 lines of ASM and call into them like you can
with C. And even if we don't say it out loud there's a bit of snobbism to
writing low level "unsafe" code. "Safe languages are for noobs and webdevs,
real coders debug with oscilloscopes".

And so I had this mindset that you couldn't have your cake and eat it too: you
could be safe or you could be low level. Segfaults and NULL pointers were just
a normal part of dealing with low level "unmanaged" environments and we'd just
have to deal with it. People who complain about it are just not worthy.

In my opinion the biggest success of Rust so far is in proving that you could
be safe without needing a GC, a big runtime or complex abstractions. You could
design a better C without having to compromise. Even if Rust fails in the long
run, it would still be a very important "proof of concept". It showed that C
was unnecessarily unsafe, that you could achieve the same feature set without
throwing safety completely out of the window.

That being said if there really are folks bugging devs by asking them to
consider switching to language X or Y then I think it's fair to say that these
people are idiots. Might as well ask JK Rowling to rewrite Harry Potter in
Esperanto because "it's totally the future!".

I mean, let's face it, at this point Curl probably has a much bigger userbase
than Rust itself by at least an order of magnitude. Which one is more likely
to be irrelevant in 10 years? Rust or Curl (and by extension, C)? If you
answered the latter you should read less hacker news.

And even if Rust ends up being successful it's not like C will go away any
time soon, or even in our lifetimes. Curl (as a C library) will probably still
be useful and relevant for decades to come no matter what.

~~~
fiedzia
[https://www.reddit.com/r/languagelearning/comments/1yv1i2/ha...](https://www.reddit.com/r/languagelearning/comments/1yv1i2/harry_potter_book_one_in_esperanto/)

------
mirekrusin
As a meta-comment - it's interesting to see how religiously-intense this
discussion has became. Why are we - programmers - need to hold such a strong
opinions about languages? Especially considering a fact that the playground is
completely open.

My personal opinion is that if he was wrong - we wouldn't even be reading his
argument - it wouldn't make it to the top of HN - everybody would be using
Xurl library instead (written in X-lang, where X is not C).

At the same time Rust is shaping to be fantastic language and I personally
hope that soon we'll see Rurl cargo together with kernel and what not in Rust.
Unless in this decade something better will appear, who knows?

------
jeffdavis
The problem is that the author listed specific reasons, which opened him up to
specific challenges.

He should have just said: "curl is an established project. New languages are
not being seriously considered for curl."

If you want to close down a conversation, it's counterproductive to make new
dubious claims like "C is not the primary reason for our past
vulnerabilities".

Note that closing down a conversation isn't bad. Sometimes they are annoying
or distracting. I love rust but here was my comment when someone wanted to
rewrite postgres in rust:

[https://news.ycombinator.com/item?id=13354768](https://news.ycombinator.com/item?id=13354768)

------
nathan_f77
Are there any automated tools that you can help you convert a C codebase into
Rust? And is there any reason why Rust couldn't be as portable as the C code
that makes up curl?

Is it very difficult to transpile C into Rust?

As an aside, I not like the curl style guidelines [1]. Especially "'else' on
the following line", and "No space before parentheses". That doesn't look nice
at all.

[1] [https://curl.haxx.se/dev/code-style.html](https://curl.haxx.se/dev/code-
style.html)

~~~
thristian
For automated tools that can convert a C codebase to Rust, you're looking for
is Corrode:
[https://github.com/jameysharp/corrode](https://github.com/jameysharp/corrode)

Last I heard, Corrode can convert many C syntactic structures into their Rust
equivalents, they usually compile and sometimes they even work. Even when the
conversion works flawlessly, the resulting Rust does exactly what the original
C code did—there's no safety benefit (but you can begin refactoring to clean
things up).

------
jeffdavis
The original post said:

"C is not the primary reason for our past vulnerabilities"

So it's entirely reasonable for critics of C to challenge that claim.

------
fiedzia
Note: I am discussing using safe languages in general and reasoning for doing
or not doing that. If you believe rewrite requests are unreasonable no matter
what, don't bother reading that. Or perhaps consider this to be addressed to
people deciding how to choose libraries to depend on, not to specific library
authors.

> curl is currently one of the most distributed and most widely used software
> components in the universe, be it open or proprietary and there are easily
> way over three billion instances of it running in appliances, servers,
> computers and devices across the globe. Right now. In your phone. In your
> car. In your TV. In your computer.

Congratulations. So how many of those have unpatched vulnerabilities right now
that were caused by using unsafe language? In my phone? In my computer? In my
car? How many accidents of data or money theft it caused? Not to mention
common non-security related bugs.

> If we then have had 40, 50 or even 60 security problems because of us using
> C, through-out our 19 years of history, it really isn’t a whole lot given
> the scale and time we’re talking about here.

Curl had multiple unpatched security problems for several years before they
were discovered. As the author admits, it most likely still has many. dpkg -l
| grep '^ii lib'|wc -l lists over 2000 libraries I have installed, lot of them
written in C. An estimate of 2000 multiplied by 60 is ... scarily to many.
Large amount of them avoidable by using safer languages.

> Using another language would’ve caused at least some problems due to that
> language

If it solves more problems than it creates, it is worth doing.

> none of the memory safe languages anyone would suggest we should switch to
> have been around for 19 years.

Neither have been mobile phones (at least as we know them), but they are
useful, so I am using one.

> We will continue to work hard on minimizing risks, detecting problems early
> by ourselves and work closely together with everyone who reports suspected
> problems to us.

I prefer to work smart, not hard.

~~~
yjftsjthsd-h
If you believe that you can rewrite any of those libraries or tools in a nice
modern language with no security issues and all the portability that they had
(including operating systems and embedded systems), please do grace us with
your work.

In the meantime, it appears rather difficult to replace the last 40 years of
work overnight in a novel, untested language, with support for a tiny fraction
of the targets that C has been supporting all that time, while maintaining
reasonable performance.

Or in short: It's easy to work smart when you're not working hard in your arm
chair.

~~~
fiedzia
> If you believe that you can rewrite any of those libraries or tools in a
> nice modern language with no security issues and all the portability that
> they had (including operating systems and embedded systems), please do grace
> us with your work.

I can point you to numerous examples of people writing and rewriting software,
there is no reason for it to be my work to prove its doable and often worth
the effort. And all languages that generate C code are as portable as C is. I
can also point you to countless examples where people replaced their
dependencies with something written in another language. Also please go back
to first line of my comment and read it again.

> In the meantime, it appears rather difficult to replace the last 40 years of
> work overnight in a novel, untested language, with support for a tiny
> fraction of the targets that C has been supporting all that time, while
> maintaining reasonable performance.

Who suggest it can be done overnight? Why not use something that compiles to C
if you need this compatibility? There is no need to replace all of it at once
- you can pick particularly sensitive parts first, one file or one library at
a time. There are many ways to introduce safer languages if you want to do it.
Also difficult or not, all code will be replaced eventually.

As for performance - its irrelevant in large amount of networking code. I'd
have no issue whatsoever with adding few cpu instructions for bounds checking,
when you wait several milliseconds for IO operation, which is the case with
curl.

~~~
lossolo
> there is no reason for it to be my work to prove its doable and often worth
> the effort.

Why? You don't have expertise needed to do that yourself? It seems you think
you have enough to lecture others and write how easy it is (just generate some
C code).

> I can point you to numerous examples of people writing and rewriting
> software

Ok, point me to this software that was rewritten from unsafe C code and was
replaced with memory safe language. I don't want any hobby projects, real
software used by millions. Give me 10 examples.

~~~
sigjuice
I too am curious to know of large and prominent C projects rewritten in
another language successfully. One recent atypical example that I can think of
is the Go compiler.

~~~
generic_user
Good point. A project with the full financial support of Google with a team
including Rob Pike, Ken Thompson, Russ Cox and others, in a language that they
designed. And it still took a few years and was a huge and stressful process.

~~~
sigjuice
When I said "atypical", I was thinking more along the lines of that it is not
unusual for compilers to eventually be self-hosting.

~~~
generic_user
Pretty much all of OS development, low level libraries, device drivers etc,
are atypical. So are compilers assemblers linkers. Programs that need to
allocate and release tens of gigabytes at a time, high performance parallel
code etc.

Any language that wants to present themselves as a replacement for C/C++ hast
to have at least a reference implementation of all those things so people can
start to evaluate (the system).

No one is going to invest the time or the resources into a language to replace
what we have if its not an actually up to the task. No one needs another
programming language sitting on top of C/C++ that kind of makes things a
little better for one class of bugs but will never really replace C/C++ and
our our system interfaces.

There is a long list of languages that have made that claim and most of it has
turned out to be hot air and marketing.

~~~
sigjuice
I am neck deep in C, pretty much all the time, from actual bare metal (i.e. no
OS) all the way up to application code, so none of what you mentioned is
atypical use of C to me :p

I do not mean to trivialize compilers, linkers and assemblers, but
fundamentally they are programs that just read and write files. They don't
really have to be in C, IMHO.

I am still waiting for someone to chime in with credible examples of
successful C -> non-C transition.

~~~
generic_user
Everyone who has has tried that approach soon after decided to leave the
company so they could spend more time with their families...

And your right that compilers etc, do not absolutely need to be written in
C/C++. But all of this is taking place in the context of the market. Open
source operates in that same market.

If you have two teams working on compilers in different languages and one is
using C/C++ its probably going to be much faster with fewer dependencies. 90%
of the business is going to go that way and the other team is going under. And
so it goes all the way up the stack.

On the other hand what about the kernel and the system libraries? Even if you
replaced the whole tool chain with another language but still have a C/C++
kernel and system interface everybody is going to want to use the native
interfaces and therefore work in C/C++. So whats the point of adding another
layer.

Given what we have now and what peoples expectations are I just don't see 'a
replacement for C/C++' ever happening until You can wipe your drive and
install a new OS with a kernel and system libraries in a totally different
language and never have to touch C/C++ again for the projects developed for
that OS.

~~~
sigjuice
I do not disagree with you even a little, and not just because C is my bread
and butter. At this point, I am merely curious about examples of large
projects doing a successful switch from language A to language B.

I just remembered reading about MirageOS recently. Almost everything is done
in OCaml. I am sure it contains a bunch of low-level C code. It seemed
interesting, but I don't think such projects will ever replace systems written
in C.

~~~
generic_user
Sorry, I can't think of any off of the top of my head. The only thing that
comes close is once in a while you see a C project switch to C++ but that's
not really an example of what your looking for. Like when GCC switched over to
C++.

------
wojt_eu
Curl should be split into micro-services.

------
najati83
The reason curl is everywhere is that it's written in C. So obviously the
author is not going to rewrite it in any other language.

------
zeveb
> curl is currently one of the most distributed and most widely used software
> components in the universe, be it open or proprietary and there are easily
> way over three billion instances of it running in appliances, servers,
> computers and devices across the globe. Right now. In your phone. In your
> car. In your TV. In your computer. Etc.

And every one of those three billion devices is vulnerable, due to the use of
C.

> I feel a need to underscore the fact that none of the memory safe languages
> anyone would suggest we should switch to have been around for 19 years

False: Common Lisp has been around since 1994 (23 years), and in substantially
the same shape for longer still. Standard ML has been around since 1990 (27
years). OCaml has been around since 1996 (21 years). Smalltalk has been around
since 1984 (33 years). Each of those languages is more memory-safe than C and
has facilities which help prevent other C-like errors. Each is capable of
speeds approaching that of C, esp. for a problem like URl fetching (e.g. I
just tried fetching [http://www.google.com/](http://www.google.com/) with both
curl & DRAKMA — a Common Lisp package for URL fetching: curl reliably ran in
about .065 seconds & DRAKMA reliably ran in about .14 seconds; I have no
reason to believe that DRAKMA is particularly well-optimised; no doubt it
could get even faster if desired).

I think this really is a textbook example of the Blub Paradox: someone using C
thinks that for the most part it's a reasonable choice in order to achieve
certain goals, while someone used to a better language is able to see that C
is simply unfit for purpose: programs written in it will inevitably have
security flaws which will inevitably cause harm — particularly when three
billion devices, many unpatched, are running them.

~~~
kazinator
Another thing: Drakma also isn't anywhere near 150,000 LOC:

    
    
      $ time git clone https://github.com/edicl/drakma.git
      Cloning into 'drakma'...
      remote: Counting objects: 991, done.
      remote: Total 991 (delta 0), reused 0 (delta 0), pack-reused 991
      Receiving objects: 100% (991/991), 343.00 KiB | 0 bytes/s,  done.
      Resolving deltas: 100% (610/610), done.
      Checking connectivity... done.
    
      real	0m1.476s
      user	0m0.148s
      sys	0m0.060s
    
      $ cd drakma
      drakma $ find . -name '*.lisp' -o -name '*.asd' | xargs wc -l
         868 ./request.lisp
         107 ./encoding.lisp
         122 ./read.lisp
         281 ./specials.lisp
          75 ./packages.lisp
         123 ./test/drakma-test.lisp
         333 ./cookies.lisp
          63 ./drakma.asd
         109 ./conditions.lisp
          37 ./drakma-test.asd
         357 ./util.lisp
        2475 total

------
hzhou321
Not to rewrite is a very sensible decision due to the fact that the current
way of programming is _un-rewritable_. For example, people don't write FORTRAN
in every language. The choice of programming language often fundamentally
change the way we approach programming. Switching language not only involves
addition or reduction of language constructs, it fundamentally alters
programmer's highest level thinking process. That is not a merit.

What we need is a meta-layer programming interface that isolates our higher
thinking from lower language concerns to some degree. If you can keep the
higher level understanding, then rewriting become less of a barrier. We need
write _pseudocode_ in every language.

I have been exclusively programming with a meta layer, MyDef, for quite a
while, and I routinely re-write my Perl program to C, not without effort, but
always a worthwhile effort trading for the goal of rewriting (speed in this
case). I am a researcher, and I rarely write production code. But for
production code, I think most software should consider rewriting in Rust.

Prototype in Perl/Python, develop in C, and produce in Rust -- makes good
sense. It makes good sense in our current non-software industry, where
researchers, developers, and producers are people with different focus and use
different material and tools. This is not true for our software industry,
where people who are not interested in researching or developing are forced to
research and develop, and people who are only interested in research are
forced to develop and people who only interested in developing are forced to
research and produce.

My example:
[http://hz2.org/blog/send_more_money.html](http://hz2.org/blog/send_more_money.html)

