271–280 of 996 posts
Earlier quoted context omitted.
Yes. C was invented in the '70s and only got standardized 20 years later. And Rust's ~20 years is young in systems lang terms (the alternatives, C and C++, are 50 and 40 years old). And nobody had TikTok back then.
> And Rust's ~20 years huh? It's only been about 9
In my experience, fundamentally when you're starting a software project, you need to make a strong up-front decision between two things: 1. I am using technology in order to build this thing. 2. I am building this thing in order to use this technology. Developers often fall in the (2) camp but don't admit it. There's an allure to using the new, sexy tech that will solve all their problems, whether that's Rust, Kubern…
> you need to make a strong up-front decision Can one always realistically do so? I suspect the underlying unspoken assumption is that one must be ideally informed about all the possible potential pitfalls and gotchas they may face when using any given technology. Aka having a very good (ideally, perfect) knowledge of the technology and its surrounding ecosystem. It wasn't just once or twice when I've picked some ver…
Exactly. You need to make some choices up front about program design despite rarely having enough information to make the correct decision, nor enough time to evaluate alternatives in detail. If we had known 15 years ago what we know now our then green field project wouldn't have been done this way - but we are still discovering things that the decisions we made 15 years ago are making hard to do today. That is on top of all the existing things we know are wrong that we often cannot feasibly correct.
You have to make choices. Some of those choices will be impossible to undo without starting over after a while. Some of the negatives will take a decade to figure out. There is no way anyone sane will give you enough time to figure out what those negatives are for each choice - even if the did you will be dead before you finish.
&str vs String. Oh boy.
https://raw.githubusercontent.com/lesterli/blockchain/master...
As much as I love Rust I sometimes wonder if I'd be more productive in a simpler language. If I wrote it every day I'm not sure that would be true, but as a hobbyist coming back to Rust sometimes takes me a bit to get back in the zone. Also, still not a fan of async, as it is woefully incomplete and fairly complicated in some use cases. That said, I just can't go back to Go with nil pointers and lack of decent enums/…
Maybe people will make fun of me, but I've been very happy with Kotlin and Dart. Null-safe, good ergonomics, very fast. I've tried Rust, sometimes play with C, D, Deno/TS, Nim, Java (actually I still write lots of it) and even some more cutting-edge stuff, like Unison. While they're cool, what I want is a language with really good tooling that gets out of my way without letting me write patently dumb code (like Java…
Earlier quoted context omitted.
I would love to make it possible to bypass the orphan rule in general , including for crates published on crates.io. This is an important issue for ecosystem scaling, in many different ways. It means that if you have a library A providing a trait and a library B providing a type, either A has to add optional support for B or B has to add optional support for A, or someone has to hack around that with a newtype wrappe…
Oh, 100%, I'd be happy with that too. Is the orphan rule a result of some technical limitation? Or just the idea that it's "unclean" to implement someone elses traits for someone elses types?
Haskell went through this as well. Orphans used to be allowed and I certainly saw their appeal.
The problem is that the compiler might see two different implementations of ToString for MyType in different source files. The compiler could probably make a check for that if it were compiling both files at once, but if you want to be able to compile source files separately and only recompile files which have changed, etc., I think it gets harder to spot.
> someone has to hack around that with a newtype wrapper
Don't think of it as hacking around it. It's the blessed approach. Newtype wrapping is giving a proper names to the behaviours, so that they don't get mixed up.
Earlier quoted context omitted.
> I'd expected some AAA title to be written in Rust by now. I'm disinclined to believe that any AAA game will be written in Rust (one is free to insert "because Rust's gamedev ecosystem is immature" or "because AAA game development is increasingly conservative and risk-averse" at their discretion), yet I'm curious what led you to believe this. C++ became available in 1985, and didn't become popular for gamedev until…
Exactly, it's all about the ecosystem and very little about the language features
1. What behavior do I want?
2. How am I implementing that behavior?
Experimenting with #1 is slowed down by the current end point of #2. Sometimes not at all, sometimes a lot, depending on luck and how #2 anticipated the class of experiment I am trying.
Rust adds:
3. How can the implementation code be organized so its stringent safety checks are validated?
Now experimenting with #1 is complicated by two dimensions of design history instead of one. And the latter dimension being two steps of abstraction/design-dependency away from concern #1, is going to be very brittle.
Never used Rust, but that sounds painful.
Honestly I have not read all the article. What language they are going to use instead of Rust?
Gaming is C++ first and foremost. All other languages suck, except when used to script game engines (C# in Unity, etc.). There's no practical reason to choose Rust or anything else. I don't think Rust is particularly bad or good here. There's decades of work to catch up on. I don't see Rust becoming a truly great language for games unless it's blessed by Epic or Unity.
> There's decades of work to catch up on First you gotta get OpenGL going, with its horrible stateful API, give up on it and go to DirectX9. Do a complete rewrite when DirectX10 comes out. Get your real-time lighting happening with shadow volumes, run into patent issues and get strong-armed into putting Creative sound into your game. Cycle between GLSL, HLSL, and Cg. End up switching to shadow mapping anyway. Drop Li…
Ironically, the main thing holding Bevy back is the bickering at the W3C. WebGPU is still not widely supported, so we have to support WebGL 2 (with reduced functionality in some cases), and that adds a lot of complexity.
Earlier quoted context omitted.
I think I just read about 10 versions of this comment on this page, and definitely not a single response to the criticism that could be described as incendiary. I don't think I even saw a single comment just now that fundamentally pushed back on the premise of this article, let alone in an incendiary way. It's early yet, and maybe this thread will look very different in a few hours though?
Perhaps because the article is about how Rust isn't the magic bullet to everything, and a few people have commented agreeing with the article, others feel more willing to comment their own Rust isn't perfect opinion as well. If you go into the comment section of a pro-Rust article, where the first few top-level comments are also pro-Rust, the responses to people expressing a negative attitude about Rust tend to (in m…