81–90 of 194 posts
Earlier quoted context omitted.
I don’t see the relevance to this discussion then.
The discussion is about a project for securing legacy code by machine-translating it to Rust. Fil-C is an alternative way to secure legacy code using a different C implementation. I think that's highly relevant to the discussion.
Earlier quoted context omitted.
That changes the semantics. It won’t work for a graph for example.
Right. The comment you replied to said "Rc/Arc and some manual management" -- "some manual management" implying that you need to account for the change to semantics in the manner appropriate for your application.
Maybe I just need to spend more time with Rust and deal with it, but I'm sad the industry desires to rally around it. Despite the specific subset of protections it aims to provide, I have always had issues with how ugly the language is. To a lesser extent, I have a problem with the protections it doesn't provide and leads developers to think they're writing safe software that in specific cases, actually just promotes…
It’s wild that this is downvoted. Converting all C++ code to Rust while actually getting a safety improvement is not possible because Rust does not safely support all of the things folks do in C++ (complex cyclic object graphs with inscrutable logic deciding lifetimes, intentional races, etc). It’s easy to think that all of those “bad” things that C++ programmers do should somehow not have been done. It’s more likely…
Earlier quoted context omitted.
It's not usually the standard library or dependencies that create the issues I've seen. The teams I work with producing Go tools (across multiple companies) invariably require carefully orchestrated dev environments that are nigh-unreproducible. It's 50/50 on whether I can actually build a random project first try without reading the instructions if CGO is involved, which seems to be all of them. My experience with r…
Rust projects which depend on C libs have very similar issues.
Earlier quoted context omitted.
Examples?
My best example of a "real" and not more artificial example (like XYZ data structure) is Game development / game engines & UI. For reference: https://news.ycombinator.com/item?id=40172033
Earlier quoted context omitted.
It's not usually the standard library or dependencies that create the issues I've seen. The teams I work with producing Go tools (across multiple companies) invariably require carefully orchestrated dev environments that are nigh-unreproducible. It's 50/50 on whether I can actually build a random project first try without reading the instructions if CGO is involved, which seems to be all of them. My experience with r…
Again, I disagree. CGO is rarely needed for Go projects. And is actively discouraged by the community.
https://github.com/discord/lilliput/blob/master/cgo.go
far more commonly in corporate Go code than Rust.
Maybe I just need to spend more time with Rust and deal with it, but I'm sad the industry desires to rally around it. Despite the specific subset of protections it aims to provide, I have always had issues with how ugly the language is. To a lesser extent, I have a problem with the protections it doesn't provide and leads developers to think they're writing safe software that in specific cases, actually just promotes…
I once had a boss that used to really hate python. He would roll his eyes whenever it was brought up. He was CTO of the company and he would sneer at it. One day, in a one-to-one meeting, I asked him, "what is so bad about python?" I expected him to explain some core deficiencies: problems regarding the module system or multi-threading limitations, or some pathological case where latency spikes... and he said "I don'…
I've said it before, but C with proper tooling extremely safe.
Noobs need consensus and senior devs need something that works, supports everything, and runs on crap platforms that can't run a Mix dev shell (Windows)
One of, in my opinion, the largest problem with Rust is that they sought to solve two problems: 1. Memory / thread safety 2. They didn't like C/C++ And often times it feels like there is more focus on problem two than problem one. Quite a bit of idiomatic and safe (yes that does exist) C++ doesn't "translate" well to Rust without large amounts of rearchitecting. I'd focus more on converting C/C++ to languages nearing…
> They didn't like C/C++ Riiiight. You do realize they made syntax similar to C/C++ on purpose to ease Mozilla's C/C++ programmers into it. It's not that they didn't like it; it's that C/C++ is about as disinterested in memory/thread safety as you can get. It's been what, ten years since Rust became 1.0? And the safety needle of C++ hasn't budged a femtometer. > Quite a bit of idiomatic and safe (yes that does exist)…
That's not fair. C++ 26 gets from the uninitialized primitives by default being a massive footgun to only slightly worse than using Rust's unsafe core::mem::uninitialized function - which was deprecated in 2019.
Now, sure, in a good language this mistake shouldn't even compile, so C++ moved from "Reprehensibly awful, do not use" to "Very bad". But that's more than a femtometer.
I don’t think Rust syntax and patterns (no classes) are especially elegant for many tasks. I can’t express the behavior of a system as cleanly in Rust as TypeScript, C#, go or Python. I know that’s not what it was designed for, but a guy can dream. But what Rust has is the best tooling bar none(cargo, build system, compile time checks, ease of first use). The tooling is actually more important than the borrow checker…
zig is very comparable, and much faster at doing so. zig also comes with a build system, libc and can compile c programs. its a better c compiler and build system than most, lol.