Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Getting Past C

blog.ntpsec.org

Post reply on HN
Print view View original

311–320 of 504 posts

Re: Getting Past C

#311

Post by BHSPitMonkey »

asveikau wrote: post #300
BHSPitMonkey wrote: post #231

Earlier quoted context omitted.

Considering that a change in language completely solves the problem, it's hard to get on board with your thesis.

A change in language does not completely solve the problem. Heartbleed was caused by buffer re-use without zeroing in between uses. A high performance network application could very easily do the same in another language. See: http://www.tedunangst.com/flak/post/heartbleed-in-rust

That's a different "problem", not to mention a flaw in the application code's design rather than an example of one of the language's building blocks being fundamentally able to allow the entire execution path to be subverted.

Re: Getting Past C

#312

Post by [deleted] »

mden wrote: post #287
thesmallestcat wrote: post #195

Earlier quoted context omitted.

This is how I feel. You cut the code to 27%. Great. You C99'd the code. Grand. Now you're going to rewrite the whole danged thing in a new language. Wonderful. This is the sort of stuff I cared about so much as a junior dev. But a user asks, are we there yet?

But adding functionality grows in effort as more code is added. At some point it makes sense to improve a code base so you improve the rate at which you are getting "there". In fact there are a lot of code bases, perhaps most, which simply cannot get there in any sane way and fall short of achieving their goal. You might not care how goals are achieved as a user but as an engineer it's worth exploring and discussing…

[deleted]

Re: Getting Past C

#313

Post by pekk »

wmf wrote: post #99
lacampbell wrote: post #88

Earlier quoted context omitted.

I just keep hearing about how rust handles safe bounds checked arrays with (and I quote) "Zero-cost abstractions", which to me implied it would be faster than C, since C pays some performance penalty by branching. Hope you feel better soon.

"Zero-cost abstraction" really means zero additional cost beyond what is required. So Rust still pays a cost for bounds checking, but it's the same cost as if you optimally hand-coded the bounds check in C.

Adding the cost of bounds checking is not actually "zero cost" relative to a C default of not bounds checking. There's really no reason to speak in this misleading way except marketing.

Of course, bounds checking is worth paying a cost! As are many other common foot-guns like remembering to free memory. Which starts to raise the issue of when it would actually be necessary to reach for Rust instead of (arbitrary example) Java. Because a language with enforced bounds checking is not really the same kind of thing as C, and we've already had languages that are safer than C for decades.

Re: Getting Past C

#314

Post by LukeShu »

ericfrederich wrote: post #309

I like go, I'd love to write libraries in it but as far as I can tell you can't really create a C compatible shared library from it. That it still the common denominator if you want to call into it from other languages. I'd love to write Python programs with performance critical stuff in Go

    as far as I can tell you can't really create a C
    compatible shared library from [Go].
Sure you can! (as of Go 1.5, iirc)

Change your build command to use the c-shared build mode:

    go build -buildmode=c-shared
Then, to change the linkage of the functions you want to export, use the magical comment "//export" directive:

    //export MyFunction
    func MyFunction(arg1, arg2 int, arg3 string) int64 {
        ...

Re: Getting Past C

#315

Post by thesmallestcat »

mden wrote: post #287
thesmallestcat wrote: post #195

Earlier quoted context omitted.

This is how I feel. You cut the code to 27%. Great. You C99'd the code. Grand. Now you're going to rewrite the whole danged thing in a new language. Wonderful. This is the sort of stuff I cared about so much as a junior dev. But a user asks, are we there yet?

But adding functionality grows in effort as more code is added. At some point it makes sense to improve a code base so you improve the rate at which you are getting "there". In fact there are a lot of code bases, perhaps most, which simply cannot get there in any sane way and fall short of achieving their goal. You might not care how goals are achieved as a user but as an engineer it's worth exploring and discussing…

I had no idea!

Re: Getting Past C

#316

Post by steveklabnik »

LukeShu wrote: post #314
ericfrederich wrote: post #309

I like go, I'd love to write libraries in it but as far as I can tell you can't really create a C compatible shared library from it. That it still the common denominator if you want to call into it from other languages. I'd love to write Python programs with performance critical stuff in Go

as far as I can tell you can't really create a C compatible shared library from [Go]. Sure you can! (as of Go 1.5, iirc) Change your build command to use the c-shared build mode: go build -buildmode=c-shared Then, to change the linkage of the functions you want to export, use the magical comment "//export" directive: //export MyFunction func MyFunction(arg1, arg2 int, arg3 string) int64 { ...

This still doesn't get over the inherent overhead in calling between the two languages though, right?

(And you're bringing that whole runtime with you. Which might be okay! As always, it depends.)

Re: Getting Past C

#317

Post by zem »

kazinator wrote: post #305
zem wrote: post #280

Earlier quoted context omitted.

I think it's a massive programming ecosystem blind spot that "depending on c" is seen as less of a burden than depending on rust

How many chip and SoC vendors provide a Rust toolchain? In the case of C, the answer is basically "about as many as provide a toolchain".

sure, use c if that's all you can use, but if rust does target your system it adds no more overhead than c does.

tangentially, ats has had some success in that area since it compiles via c. but I agree that c is less work to get set up with.

Re: Getting Past C

#318

Post by rustmemcpy »

steveklabnik wrote: post #272
sirclueless wrote: post #243

Earlier quoted context omitted.

> Neither C nor C++ knows, at the language level, the size of an array, unless that size is fixed. Neither does Rust. > The subscript checking variants of C and C++ have to use "fat pointers" which carry along size information. So do Rust's Slices. > The overhead for this is large and nobody uses that. People use std::vector all the time for this purpose in C++. It has about the performance you'd expect, with very li…

One thing that I've heard might be a difference, but haven't confirmed yet: Rust's lack of move constructors. So you have a vector, it's full, you push one more. It has to reallocate. How do you copy all of the elements over to the new allocation? In Rust, it's a straight memcpy of T * n bytes. But due to move constructors in C++, IIRC they must be moved one at a time. Again, I haven't actually dug into this; maybe s…

How would a self-referential object work in Rust in that case? The move or copy constructor could not be a simple memcpy.

The self-reference would point to the old object. See this for an example: http://ideone.com/sEFtbN

Re: Getting Past C

#319

Post by AgentME »

rafinha wrote: post #251

I didn't understand why rust and go are natural alternatives to C. Wouldn't C++ be a more natural option? (Despite the fact that both go and rust are developed by third party companies)

None of the safety issues brought up about C there are solved by C++. C++ is (nearly) a superset of C, so it inherits all of those issues.

Re: Getting Past C

#320

Post by pekk »

burntsushi wrote: post #284
userbinator wrote: post #275

Earlier quoted context omitted.

Why allow programmers to make mistakes? For a philosophical counterpoint: Why allow anyone to do anything that might possibly be incorrect, harmful, or otherwise perceived by some to be negative? I've looked at a lot of the talk surrounding "safe/secure languages", "safe/secure programming", etc., and yet every time I've heard people preach about the benefits, I feel like I just vehemently disagree. At a very deep an…

That's a great quote, and it's one that Rust---as a a memory safe language---completely embraces. You have the freedom to do anything you want. Some of those things simply require you to type "unsafe."

Forgive me for being cheeky, but just as Rust requires you to type "unsafe," C also requires you to opt in by typing "cc".

My serious point is that in practice, the example of C shows that if it is available and people understand that it is "performant" then you will see it all the time, including in libraries you are forced to use.

Post reply on HN