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

Translating All C to Rust (TRACTOR)

darpa.mil

Post reply on HN
Print view View original

391–400 of 403 posts

Re: Translating All C to Rust (TRACTOR)

#391

Post by constantcrying »

dtx1 wrote: post #383
constantcrying wrote: post #376

Earlier quoted context omitted.

Many of the most widely used languages have obvious major design flaws. (JavaScript is one obvious candidate, python is another. How did a language which has no built-in floating point type become the number one language for numerical analysis?) The real question is what tradeoffs you are making and what you are gaining. Rust makes certain memory safety guarantees about the program at compile time, but at the same ti…

> JavaScript is one obvious candidate I don't see anyone defending JavaScript. In fact a whole lot of people are using typescript now because JavaScript is just so bad. As for python, that's a good point. I guess it's just because it's easy to use and all the numerical stuff is done with c-bindings anyway? But the C++ Situation is genuinely different. There's a reason governments are now calling upon developers to ju…

>I guess it's just because it's easy to use and all the numerical stuff is done with c-bindings anyway?

No, it's horrible, because now you have both python types and numpy types, which don't really interact well with one another. If you are using a language made for numerical analysis (e.g. Julia), a lot of headaches disappear instantly.

Python is 100% just a case of a language being used because it is being used. It has, by itself, few merits to many of the tasks it is actually being for.

>design flaw

It is a tradeoff though. Rust is paying that tradeoff by being very restrictive about certain patterns and being in general quite complex to learn.

Re: Translating All C to Rust (TRACTOR)

#392

Post by gosub100 »

constantcrying wrote: post #386
gosub100 wrote: post #385

Earlier quoted context omitted.

> Because it isn't magic. So graphics drivers are magic? They weren't designed in a determinate way, with a known interface and specifications?

No, AI isn't magic. LLMs are bad at exactly those things which you need to make a GPU driver. Extremely high accuracy over long distances. AI totally falls apart when trying to write a novel, how could it write a GPU driver?

They are excellent at stealing artists' content. I don't think it will be long for them to steal content from authors.

Re: Translating All C to Rust (TRACTOR)

#394

Post by constantcrying »

gosub100 wrote: post #392
constantcrying wrote: post #386

Earlier quoted context omitted.

No, AI isn't magic. LLMs are bad at exactly those things which you need to make a GPU driver. Extremely high accuracy over long distances. AI totally falls apart when trying to write a novel, how could it write a GPU driver?

They are excellent at stealing artists' content. I don't think it will be long for them to steal content from authors.

They just are terrible at producing long coherent segments of text.

>They are excellent at stealing artists' content.

AI doesn't "steal" anything. It is matrix multiplication. AI companies are exercising fair use to create derived works using matrix multiplication. Not only is it obviously fair use, it is also what every other artist does.

>I don't think it will be long for them to steal content from authors.

Most authors who have digitally available works have almost certainly have had their works used as training data.

Re: Translating All C to Rust (TRACTOR)

#395

Post by ksp-atlas »

dtx1 wrote: post #364
poikroequ wrote: post #353

> Those involved with the oversight of C and C++ have pushed back, arguing that proper adherence to ISO standards and diligent application of testing tools can achieve comparable results without reinventing everything in Rust. If you stick to extremely stringent coding practices and incorporate third party static verification tools that require riddling your code with proprietary situations, then sure, you can achiev…

It's quite hilarious to see the push back rust gets by the c/c++ community. Obviously their decades of hard work and experience to work with those languages are overriding their reasoning circuits. Who in their right mind would defend a language that has such major and obvious design flaws if a genuine alternative is there.

Honestly, it feels too limiting, I know about unsafe and stuff but there's just something about managing memory manually, Zig is a good middle ground imo

Re: Translating All C to Rust (TRACTOR)

#396

Post by Gibbon1 »

TZubiri wrote: post #375

If you translate the code from C to Rust automatically. Isn't C still the source code? Just transpiled to Rust as an intermediate before asm?

Yeah. I'm not sure how transpiling to rust is that much different than using the various standard analysis tools. And back porting things like the counted by attribute.

Also the lowest hanging fruit in C would be adding the ability to box and unbox fat pointers to objects.

Re: Translating All C to Rust (TRACTOR)

#397

Post by geor9e »

TZubiri wrote: post #375

If you translate the code from C to Rust automatically. Isn't C still the source code? Just transpiled to Rust as an intermediate before asm?

There's no direct translation back and forth between unsafe C to safe Rust tho, and theres infinite memory safe interpretations possible. If you're only interested in a black box executable, where certain tests pass, then I suppose you could just save the C and delete the Rust. But, the Rust has more information (that can't be deduced deterministically from the C). C would first get transpiled to unsafe Rust. Then some intelligence (A.I. or human) would get rid of all the unsafe keywords by making new design decisions that affect how the executable works inside. Each intelligence will do it differently. New edge case tests might give different outputs depending when you transpiled the C. It'd be better to save the Rust and make future changes without worrying if the latest A.I. will make the same design decisions at the prior A.I. each time you compile.

Re: Translating All C to Rust (TRACTOR)

#398

Post by gosub100 »

constantcrying wrote: post #394
gosub100 wrote: post #392

Earlier quoted context omitted.

They are excellent at stealing artists' content. I don't think it will be long for them to steal content from authors.

They just are terrible at producing long coherent segments of text. >They are excellent at stealing artists' content. AI doesn't "steal" anything. It is matrix multiplication. AI companies are exercising fair use to create derived works using matrix multiplication. Not only is it obviously fair use, it is also what every other artist does. >I don't think it will be long for them to steal content from authors. Most au…

there's literally no such thing as theft. only bring an object to one location from another, all 3d planes are relative to earth/sun/galaxy's orbit. there is no such thing as location.

Re: Translating All C to Rust (TRACTOR)

#399

Post by poikroequ »

ksp-atlas wrote: post #395
dtx1 wrote: post #364

Earlier quoted context omitted.

It's quite hilarious to see the push back rust gets by the c/c++ community. Obviously their decades of hard work and experience to work with those languages are overriding their reasoning circuits. Who in their right mind would defend a language that has such major and obvious design flaws if a genuine alternative is there.

Honestly, it feels too limiting, I know about unsafe and stuff but there's just something about managing memory manually, Zig is a good middle ground imo

I think it depends on the domain. You don't need Rusts memory safety guarantees everywhere for everything. But if you're writing some sensitive piece of code where security is crucial, it seems crazy to not use a language like Rust.

Re: Translating All C to Rust (TRACTOR)

#400

Post by constantcrying »

gosub100 wrote: post #398
constantcrying wrote: post #394

Earlier quoted context omitted.

They just are terrible at producing long coherent segments of text. >They are excellent at stealing artists' content. AI doesn't "steal" anything. It is matrix multiplication. AI companies are exercising fair use to create derived works using matrix multiplication. Not only is it obviously fair use, it is also what every other artist does. >I don't think it will be long for them to steal content from authors. Most au…

there's literally no such thing as theft. only bring an object to one location from another, all 3d planes are relative to earth/sun/galaxy's orbit. there is no such thing as location.

AI is just doing the exact same thing all artists are doing.

By your logic every artist who has ever viewed another artists image are thieves.

Also intellectual property isn't real. Copy right needs to be abolished. Most artists are terrible and should be replaced by AI.

Post reply on HN