Comment by devy | Hacker News Reader

Comment by devy | Hacker News Reader

The 7th point: "curl sits in the boat"

    In the curl project we’re deliberately conservative and 
    we stick to old standards, to remain a viable and reliable 
    library for everyone. Right now and for the foreseeable 
    future. Things that worked in curl 15 years ago still work 
    like that today. The same way. Users can rely on curl. We 
    stick around. We don’t knee-jerk react to modern trends. 
    We sit still in the boat. We don’t rock it.

I see a lot of inertia in there. While it's a great record to maintain 15-year consistency but in the era of every changing InfoSec outlook, it could be a legacy and baggage if the authors resist to change. One thing we know for sure is that human will make mistakes, no matter how skillful you are. In the context of writing a fundamental piece of software with an unsafe programming language, that means we are guarantee to have memory-safety induced CVE bugs in curl in the future.

Some of other points that the author raised are valid too. If there is a trade-off that we can have a safer piece of fundamental software by almost eliminating a whole category of memory safety related bugs, and with the downside of less compatibility with legacy systems, more dependencies etc., perhaps we should consider it? I believe the tradeoff is well worthy in the long run and option is ripe for explore.

How is the author resistant to change? He specifically said new code should be written in a language that meets the priorities for that code. He specifically said someone has or would write a competitor to curl in Rust or some other safer language and that a good one will take off. He welcomed that.

What he doesn't welcome is rewriting something that's had those bugs and the types of logic bugs not related to the language already worked out. There's a saying about a baby and bathwater.

Not everything is a dichotomy, and you shouldn't be reading the article as if the author is against newer languages. He specifically says that given a fresh start with the availability of these languages he might use something besides C. Carefully weighing options is wise. Throwing away years of actual progress for the appearance of quick progress is foolish.

> How is the author resistant to change?

I specially quoted the section head "curl sits in the boat" and the entire section ends with "We sit still in the boat. We don’t rock it". Now read it again, and then tell me if that's welcoming changes or resisting changes.

> He specifically said someone has or would write a competitor to curl in Rust or some other safer language and that a good one will take off. He welcomed that.

Sure there might already be some alternatives out there. But those are not curl, they are at most forks.

> He specifically says that given a fresh start with the availability of these languages he might use something besides C.

Nope, he used the word "Maybe. Maybe not." Might is a stronger word.

Having no plans to change curl within itself is not a resistance to change in general.

Not everything is a dichotomy. One doesn't have to be for all change or against all change. One can choose which things need to change.

I see "we don't rock the boat" as completely synonymous with "I am resistant to change".

(Note that I suspect you think that I or the original poster are suggesting that he's resistant to all change, not just change within curl. I don't believe he's resistant to all change, but I do believe he's resistant to change within curl, which is what we're talking about here.)

He's not resistant to change in the problem space. He's resistant to very particular types of change in one very particular codebase, and for very sound reasons.

He doesn't want to break the ecosystem around curl, which is huge, while getting back to feature parity and compatibility during a full rewrite. Something that comes along and replaces curl externally needn't be completely compatible and therefore is freer to leverage their new, fresh start much more fully. He welcomes a competitor, which means even a possible complete replacement. That's not a resistance to change. That's being very judicious about what one changes and why.

> He doesn't want to break the ecosystem around curl, which is huge, while getting back to feature parity and compatibility during a full rewrite

Very good point! However, rewrite doesn't have to break the existing ecosystem and it can happen in a parallel track right? (curl has had 1.5k contributors so far so the community should have enough support to maintain existing codebase while developing new version on a new programming language hypothetically speaking.)

In fact, I would argue that the "it works now and has been working for 15 years so we don't rock the boat" attitude is negatively impacting the curl ecosystem in the long run. I'm a python developer, a good example I can give you to support my view is the python 2.x to py3k transition (If the "better unicode support" is analogous to "memory safety bug avoidance").

[1]: https://github.com/curl/curl/blob/master/docs/THANKS

Python 2 to Python 3 was basically world-breaking for many projects. Most every non-trivial piece of code needed to be modified to work with 3. Many people maintain older code on 2 to this day even with newer code being written on 3 by the same people.

Is that what you're wanting for curl?

This presumes the boat is going nowhere...

> it could be a legacy and baggage if the authors resist to change

Could be. Or it could not be.

Somehow, Git has increased in popularity, despite its author's over-my-dead-body insistence on C.

> it could be a legacy and baggage if the authors resist to change.

Every few years there is a new batch of programming languages that come out and they all gain a small passionate community that tries to convince the internet how much better that language is.

They inevitably use the argument that code not written in the new language is 'legacy' and 'resistant to change'.

Neither of those assertions are accurate or enlightening unless you can provide a proposed replacement and prove the superiority of the new code.

Simply telling other programmers to rewrite there code in xyz language with such arguments is primarily a case of armchair development.

If you really think it could be done better then do it and prove it.

> If you really think it could be done better then do it and prove it.

What I said is my believe and opinion, obviously. I don't have the skill set neither have time to do/prove it, unfortunately. But that shouldn't prevent me from speaking out my opinion, should it? Just like a lot of people really think space travel could be done better but not all of them have the capability and resources to do it and prove it.

> I don't have the skill set neither have time to do/prove it, unfortunately. But that shouldn't prevent me from speaking out my opinion, should it?

Given the fact that programming language fanboy noise is a constant problem in language threads it would be nice to see less posts of higher quality then the same arguments that are always made. Its not really going to change anyone mind that has experience and the people who do argue are usually inexperienced with vapid counter arguments.

So I guess the answer is no. If you have an uninformed opinion then its better to not add noise and let the people who really know there topic enlighten us with a well argued not very noisy discussion.

I think the value of NH is very much quality over quantity.

I've a wild idea: add support for pledge, capsicum, etc to your codebase so these vulns are neutralized on every OS with a good security framework

Reply on news.ycombinator.com