Rust and the Future of Systems Programming [video]

Re:Rust and the Future of Systems Programming [video] by qwertyuiop924 on Wednesday November 16, 2016 @02:35PM (#12970611)

I wouldn't hold your breath for C to die though. C sucks at many things, but it's pretty good in embedded, if you're not writing ASM.

[ Parent | on HN ]

Re:Rust and the Future of Systems Programming [video] by gcp on Wednesday November 16, 2016 @02:58PM (#12970873)

Actually, the only real advantage that C has over rust there is the availability of trimmed libcs.

[ Parent | on HN ]

Re:Rust and the Future of Systems Programming [video] by dbaupp on Wednesday November 16, 2016 @05:36PM (#12972263)

Rust has libcore, which is, in many ways, more featureful than libc despite also having zero dependencies. From my perspective, the main advantage of C is the way in which chip manufacturers only provide (poorly supported/bug-ridden) C compilers, but this is likely to become less important as ARM takes over more and more of the world: it is only getting easier and cheaper to throw a full ARM chip into a device, due to economies of scale.

[ Parent | on HN ]

Re:Rust and the Future of Systems Programming [video] by eggy on Wednesday November 16, 2016 @05:20PM (#12972134)

C seems to be going through yet another renaissance.

C is a smaller language to learn.

There is tons of legacy code even for embedded systems.

[ Parent | on HN ]

Re:Rust and the Future of Systems Programming [video] by gcp on Wednesday November 16, 2016 @05:52PM (#12972367)

C is a smaller language to learn.

There are engineers with 20 years of C programming experience that will still make security errors while handling basic strings. "Small" does not mean "good" and "learning" a language doesn't mean you'll write good code with it.

[ Parent | on HN ]

Re:Rust and the Future of Systems Programming [video] by qwertyuiop924 on Wednesday November 16, 2016 @06:55PM (#12972827)

No, small is good. But C isn't small. It's actually massive, and not terribly orthogonal. It's peppered with special cases, and things people think but aren't actually true (how would you check for an integer overflow in C?).

It's like comparing x86 to, say, m68k (or most things, really). One was designed. The other is an ungainly mess of hacks on top of hacks, which has a good, elegant design in there somewhere, desparately trying to get out. Guess which one is x86.

Now guess which one is C.

Worse really is better. Or at least, good enough.

C isn't a complete mess, and you can write good code in it if you're very careful, but it's not great.

[ Parent | on HN ]

Re:Rust and the Future of Systems Programming [video] by qwertyuiop924 on Wednesday November 16, 2016 @04:08PM (#12971538)

Why would you use libc embedded? Most of libc kind of expects an OS to be there.

[ Parent | on HN ]

Re:Rust and the Future of Systems Programming [video] by gcp on Wednesday November 16, 2016 @05:49PM (#12972346)

Uh? There are definitely trimmed libc's (not GNU libc!) that run on bare metal. Such as the one used by avr-gcc for example...

[ Parent | on HN ]

Re:Rust and the Future of Systems Programming [video] by qwertyuiop924 on Wednesday November 16, 2016 @06:43PM (#12972732)

Yeah, but why? I've never used a libc on embedded, and I'm kind of confused as to why you'd want to. Am I just Doing It Wrong™?

[ Parent | on HN ]

Re:Rust and the Future of Systems Programming [video] by saaadhu on Thursday November 17, 2016 @01:01AM (#12974773)

Atleast for avr-gcc, (part of) startup code and vector table layout come from avr-libc.

I'm kinda surprised you got by without libc - no strxxx, memxxx ,xxxprintf/no math.h functions ever?

[ Parent | on HN ]

Re:Rust and the Future of Systems Programming [video] by qwertyuiop924 on Thursday November 17, 2016 @09:37AM (#12977761)

No. But my embedded projects weren't particularly impressive. I can at least see the need now.

[ Parent | on HN ]

Re:Rust and the Future of Systems Programming [video] by collyw on Thursday November 17, 2016 @03:53AM (#12975642)

A load more developers as well?

[ Parent | on HN ]