Hacker News Reader

Hacker News

Comment by tkinom | Hacker News Reader

Parent Full thread

tkinom

Does rust use getaddrinfo()?

grep -irn getaddrinfo .

./src/libstd/sys/common/net.rs:123: try!(cvt_gai(c::getaddrinfo(c_host.as_ptr(), ptr::null(), ptr::null(),

./src/libstd/sys/windows/c.rs:1235: pub fn getaddrinfo(node: const c_char, service: const c_char,

./src/libstd/sys/windows/net.rs:69:/// Provides the functionality of `cvt` for the return values of `getaddrinfo`

How many places doesn't rust source code use C structures or call C APIs?

In the rust source tree, run this:

grep -irn '[^a-zA-Z0-9]c::' . |wc

    615    3143   56000

grep -irn 'extern "C"' . |wc

    279    1719   23448

View on HN

You are missing the forest for the trees. Grandparent is saying "replace all C with Rust" and you replied with "but look, Rust programs rely on glibc! It's unsafe!"

Yes, Rust programs can be affected by this. But only because they call into C at a lower level, for the libc layer. If glibc was in Rust it would provide security to all application, including ssh or curl which aren't in Rust.

Also, extern "C" is for C FFI exports not calling C APIs. The world unanimously decided C FFI is the least common denominator, so its not like Rust can provide a different API with better safety hints.

Or perhaps he made a more subtle point: you can't replace all C with Rust. Even if you rewrite the libc (you'll need some assembly), even if you rewrite the kernel (you'll need a lot of assembly and "unsafe"), there will still be lots of closed-source C running on undocumented components of your computer as firmware. C is just representative of computers as they really are today, for a bunch of reasons (mostly pragmatism) unrelated to the fact that some people still like C.

Just as an ironic aside - C enthusiasts may even have switched to musl-libc already, and are not affected by bugs in glibc, while rust-loving people are vulnerable!

Also interesting, Go has for a long time supported using its own dns resolver instead of libc, but only recently in go 1.5 uses the go dns resolver by default on unix systems.

We also provide builds of a MUSL-enabled rustc, if that's your thing.

Agree.

"C" to OS, Kernel, Computer Language, applications is like oxygen is to life on earth.

Yes, O2 causes fire from time to time, but you can't live without it.

> "C" to OS

There's the solution! Replace C with "C", a garbage-collected version of C! The quotes mean it's safe!

I say we should write it in "Rust", as opposed to Rust.

The analogy is wrong because most all languages are Turing complete, and therefore equivalent despite paradigm and feature differences. The main reason seL4 was written in Haskell and again in C was to cross-verify behavior. C might be legacy ubiquitous, however it doesn't have to be the last word in shared library development by any means.

Any language which has a toolchain which produce flat binaries or use link scripts to specify sections can potentially be used for kernel and os dev. Bonus points for a toolchain which can compile itself.

There are kernels written entirely in Rust with some assembly glue. Others are writing production embedded domain-specific OSes in Haskell, OCaml, etc. for real, mission-critical systems right now and have been doing so for the last 5-10 years.

C inherently or inadvertently leads to giant codebases and subtle bugs when used too liberally, as opposed to higher-level, statically-compiled languages like Haskell and others.

The main issue with legacy code is how we choose to either keep investing effort in putting fingers into the levees or try something new in an incremental fashion.

PS: I would like to see Go get with it and support non-usermode, self-hosted and embedded development without including a giant, hard-to-port runtime in everything.

> The main reason seL4 was written in Haskell and again in C was to cross-verify behavior.

seL4 was modeled in Haskell, then written in C. Then they used tools to verify that the Haskell models matched the C code.

Do you know of a language called "C", as opposed to C?

musl isn't without resolver bugs either. http://www.openwall.com/lists/oss-security/2015/03/30/3

Are you arguing that since we can't replace everything with safe code, we shouldn't replace most of it? Security is not a binary state. Even taking firmware into account, if you compare the number of CVEs affecting "normal code" and firmware, the choice is trivial.

> Are you arguing that since we can't replace everything with safe code, we shouldn't replace most of it?

Well, yes, the effort to replace even a small part of current code base with something perceived as "safe code" is huge. The re-factoring effort is so great that there is no doubt a significant number of new seurity problems wouldn't be created.

They would of course be different kind of problems. Not indexing errors, perhaps, but something we don't even know about. And justifiying this very large cost is not so easy.

Good point, we shouldn't be dogmatic but pragmatic. But there's a fallacy conveyed by seeing C idioms as the only low level ones.

Do some low level Rust programming and then do some low level C programming. It's hardly any safer, because it can't be safe at such a low level without a performance penalty. In the capitalist reality we live in, that is a cost no one will pay.

You're talking about the forrest - while we're talking about how making trees from scratch is difficult and messed up no matter how you go about it.

At some point, you have to talk to the computer directly (aka "unsafely"). Things like bounds checking, garbage collection, and other runtime utilities sound like great ideas until they translate to significant monetary costs each month.

Not everything is as trivial as writing GUI glue code in a nice comfy language with a magical framework. Although, most of it is.

I'd really like to see a good write up on a project that's trying to tackle this problem on the levels below C. (Assembly or even hardware level.)

The x86 ISA already has bounds-checking opcodes which can be used to ensure array accesses don't go off the deep end.

  >  it can't be safe at that low level without a performance penalty.

Many of Rust's safety guarantees come from compile-time checks that then do not have any runtime penalty.

Yes, sometimes you still need unsafe, but even then, it's a superset, not a subset: a lot of safety checks still happen inside an unsafe block.

That said, I do think that building a libc in Rust would take a significant investment and I'm not sure who's going to even attempt it, if anyone.

>Many of Rust's safety guarantees come from compile-time checks that then do not have any runtime penalty.

But not bounds checks, which are unfortunately what you need with respect to buffer overflows.

Yes, absolutely.

But only if you use the `slice.unchecked_get`[1] method, otherwise you still get bounds checking in an unsafe block.

[1]: http://doc.rust-lang.org/std/primitive.slice.html#method.get...

> Do some low level Rust programming and then do some low level C programming. It's hardly any safer, because it can't be safe at such a low level without a performance penalty. In the capitalist reality we live in, that is a cost no one will pay.

I do a lot of low-level Rust programming and a lot of low-level C programming. I don't know what the performance penalty you're claiming exists comes from. Can you elaborate as to the specific Rust features that you claim are slow?

(Incidentally, the project I'm working on right now in Rust beats all of the existing C competitors in performance by a lot.) :)

A little defensive, maybe? I never claimed Rust was slower than C or that it had a performance penalty (because you should use unsafe). Actually, I pretty much said the opposite. I said they were the same.

I was trying to highlight the fact that unsafe Rust and C are not that different when you're doing bitwise operations on bare metal.

I was wanted to drive the point that additional abstractions are undesirable at that low level unless they can be enforced at compile time. I'm concerned by some of the magical thinking being espoused in this thread about what's actually reasonable in terms of the trade offs you can make.

In other words I was talking about safety, not speed.

I'm glad to hear Rust is out performing C though. I just wish I had a better IDE than atom... Didn't you once mention Xcode support for Rust?

pcwalton is talking about safe rust. Unsafe rust is not really any faster in a lot of cases, and even when it is the goal is to compartmentalize the unsafe code into very small, distinct, easily testable segments.

Again, I'm not talking about performance. I'm talking about low level safety and the difficulties in achieving that in any meaningful way. I wasn't talking about just Rust when I said abstractions cost you speed. It was a (perhaps unclear) general statement about programming. As an aside, unsafe rust is faster than safe rust for a lot of cases.

I re-read what I wrote and I fail to see where I attacked or even (God forbid) criticized Rust.

So far IME, the rust community is extremely defensive and antagonistic to anyone they perceive to have made the slightest criticism. It's immature and irritating. It's the only thing that really turns me off from fully embracing it.

I can't participate in a community that's fundamentally hostile to skepticism.

> Again, I'm not talking about performance.

But previously you said "because it can't be safe at such a low level without a performance penalty" which clearly implies performance is part of your argument. This is what I was talking about in my other reply, which mentioned "without narrowing the scope or clarifying your intent".

> I re-read what I wrote and I fail to see where I attacked or even (God forbid) criticized Rust.

This is more about backing up claims with concrete examples. pcwalton is a Rust developer, I'm sure he would be very happy to hear a specific shortcoming he wasn't aware of, or was undervaluing. That's how improvements are made.

> So far IME, the rust community is extremely defensive and antagonistic to anyone they perceive to have made the slightest criticism. It's immature and irritating. It's the only thing that really turns me off from fully embracing it.

There may be some of that, but I also see a lot of rust community members trying to explain where people's assumptions are wrong, and it being taken as being antagonistic. The fact that Rust has some compile time checking that could actually make some of the low-level code faster is what I think is being alluded to by pcwalton. Of course there will be things that rust won't catch, and will need to be done in both C and rust, and there's things that other languages may catch that rust doesn't and vice-versa.

> I can't participate in a community that's fundamentally hostile to skepticism.

That's an interesting way to put it. You've made assertions, and when asked for clarification or evidence, began your response by calling the other commentor's motives into question (is it a reasoned response, or was it overly emotional because they were "defensive"). Asking for evidence of assertions is skepticism, and to balk in face of requests to do so is actually what I would consider being defensive.

To be absolutely clear, I don't think you would have been downvoted if you didn't start your reply with "A little defensive, maybe?". I didn't downvote you, but my initial assumption was that the downvoting I saw was because of that.

I re-read this and I see where I went wrong. I thought I had made a general statement about the cost of memory safety abstractions in programming languages that was misinterpreted as a specific statement about Rust and safety in general. This was because I was not clear in my phrasing.

I guess I felt I was being attacked for a point that I wasn't even trying to make. That is, I was responding to you under the impression that I had clearly said something differently than what was interpreted. All without taking the time to read over my own post carefully. Then I got overly emotional which resulted in us talking past each other unproductively and rude remarks on my part.

So I'm sorry for being a melodramatic jerk yesterday. I am actively working on my self control and civility, but I definitely made a mistake here. Hope you have a good day.

Thanks, and sorry if the way I worded any replies contributed to that in any way, it wasn't my intention. I hope you have a good day too. :)

It's not defensive to ask for evidence of a claim. If your statements are too general to be backed up without narrowing the scope or clarifying your intent, it's hardly the other person's fault for requesting clarification or evidence.

Just Asking Questions is a technique that's often used to derail or humiliate a verbal opponent. Forgive me for being cautious.

Also, my statement was not that general or vague. Maybe it could have been clearer, but it appears to have also been misinterpreted by pcwalton.

> ...it can't be safe at such a low level without a performance penalty. In the capitalist reality we live in, that is a cost no one will pay.

A bit higher up:

It was clear when Hoare stated on his speech in 1980:

"Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to - they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."

- https://news.ycombinator.com/item?id=11110456

... which directly contradicts the "no one" part.

A sample size of one makes for a worse rule of thumb then a trend based on hard reality.

Speed is all that matters, I actually learned that from Graydon's blog:

http://graydon2.dreamwidth.org/233585.html#cutid1

Rust sacrificed the majority of its runtime and adopted C's memory model late in development so people wouldn't have to pay a performance cost or depend on confusing heap allocation semantics. That's why it has a really good chance at disrupting the embedded space.

The enterprise software world didn't leap off C++ and onto Java because it was faster. They did it because it didn't segfault all the time. They then leapt to Perl and Python and Ruby because they didn't segfault all the time and seemed a lot faster to develop in.

To the vast majority of people and organisations writing software, performance of the software, to within an order of magnitude, just isn't a big deal.

We aren't talking about enterprise software. It hasn't been mentioned once. You can't change the subject and then say I'm wrong. Obviously, higher level applications can and often should be implemented using garbage collected languages.

Reply on news.ycombinator.com