7 ms·
One of the biggest mistake, in my opinion. Especially with async which complicates lifetimes a lot.
by unsolved73 3y ago
One of the biggest mistake, in my opinion.
Especially with async which complicates lifetimes a lot.
- dystroy 3y agoRust noob here. Can you please explain how removing '~' and '@' by moving the GC to a library makes async harder ?
- baq 3y agoit's not the things that were removed, it's the things you have to add to the source now to make it work within the limits of the borrow checker. in the simplest case, you'd add Arc<..> everywhere @ used to be.
- arghwhat 3y agoRather than those operators and how GC is done, I think the key aspect is how much easier async is in other languages that have easy automatic memory manage without ownership through garbage collection. Go and JavaScript/Dart are good examples. But such models would also take away everything that makes Rust... Rust.
- yccs27 3y agoI suspect GP only read the title and not the article. A Java-style GC might make async code easier, but that never existed in Rust.
- BenoitP 3y agoLifetimes complicated. Having a proof of them at compile time is difficult. You can't prove everything for starters. A lot of patterns are just a no-go. Why not defer that to the runtime, and just observe which variables stick around (that's GC) IO complicated. The cycle of doing code then waiting for IO is wasteful (sequentially you waste millions of CPU cycles waiting for the network to answer back). To max out usage of your hardware resources you could just aggregate IO requests with your compiler. Switching back and forth between code that uses IO, as IO request come back (that's async) Problem is: switching back and forth between code that uses IO is recklessly hard wrt coming up with a proof of the lifetimes of the variables. And a language/runtime _needs_ to have the trifecta of compiler/GC-or-memory-management/memory-model coherent and within the runtime. compiler/GC-or-memory-management: the GC-or-memory-management needs to know who writes, who owns, who reads GC-or-memory-management/memory-model: you need to know when and how you can read your writes, what are the rules memory-model/compiler: you'll be managing memory barriers so that you can cram together sequences of writes that are compatible, for maximal performance This trifecta dependence is foundation to a language/runtime, and a change to one affects the others quite deeply. Changing the compiler (bringing async here) affects the other ends and you can't do that when GC-or-memory-management is all over the place (as a lib, or god forbid in user hands) I'm afraid async is just something unaffordable for a language that wants to be that close to the metal. And even then, async is just a bandaid for a costly threading IO model. ---- Come over to the dark side of Erlang, Go, and Java. We have small threads now. You can just block like there is no tomorrow, and the runtime will have a cheap back and forth. You can just forget about the lifetimes, as the GC will sweep after you (and concurrently, outside of the critical allocation path). Forget it all my friend. Java is love, Java is life.
- nu11ptr 3y agoThey wanted a systems language. A GC would be very appropriate for much of the code I write, but would not have been for an OS kernel. Green threads removed as well. I admit the GC version with green threads I would have preferred, but again, not appropriate for the domain they wanted. I still want my halfway between Go and Rust language.
- ynik 3y agoA GC-free systems language isn't just for OS kernels. Rust's main use case was to replace C++ components in firefox. This wouldn't have been possible with a language that brings along its own GC, as Firefox already has a JS GC. Multiple garbage collectors in the same process are a quick way to madness, especially if you have reference cycles stretching across multiple GC heaps. This also comes up when writing Python extension modules, base libraries that are meant to be usable across languages, etc... This is part of why Rust is so successful -- it's the first real alternative for this space since C++ came along. For most application development, it's better to use a garbage collected language. But in the application space there is a much bigger choice of languages already available, Rust wouldn't have been a big deal over there.
- tikkabhuna 3y agoI do wonder why there hasn't been more exploration in a series of languages that have a very similar style and toolchain but have different audiences. It would be great to have Rust, Rust with a GC, and then some sort of interpreted language that has a similar syntax. When jumping between languages I feel like half the battle is overcoming muscle memory.
- 0cf8612b2e1e 3y agoThis is my dream. An interpreted language, implemented in Rust which essentially boxes all data and can do message passing to the host language. This would then give a somewhat plausible upgrade path to port the interpreted code into Rust bit by bit as required. The interpreted language even be slower than Python, so long as the escape hatch to Rust was simple and safe enough to implement the interfaces.
- nercury 3y agoWith GC rust would have been just another slightly different language.
- Shorel 3y agoThen you can use D lang.
- api 3y agoRust is a language for writing the GC, runtime, OS kernel, etc.
- pjmlp 3y agoAnd? Plenty of GC enabled system programming languages have achieved similar feats, with bigger outcome than Rust has managed to on the desktop space, e.g. Xerox Workstations, across Smalltalk, Intelisp-D and Mesa/Cedar. Redox is still not as feature rich as Mesa/Cedar was on the Dorado in 1981. https://www.youtube.com/watch?v=z_dt7NG38V4 https://www.youtube.com/watch?v=z_dt7NG38V4 By the way Go, D, Eiffel, Nim, Common Lisp, Scheme, some JVM implementations are bootstrapped, meta-circular, with their own GC implemented on them.
- qalmakka 3y agoA GC would have made Rust yet another Dlang, which is pointless because Dlang has existed for a way longer time.
- silon42 3y agoOr more realistically, another JVM language. I actually wouldn't mind a subset of Rust that targets the JVM.
- raverbashing 3y agoSo why Dlang has not gotten as popular as rust or go?
- nickpp 3y agoLack of a big corporate backer is my best guess.
- qalmakka 3y agoa. it never had a real corporate backer, until it was too late (and Rust already stole all of its mindshare) b. It had a garbage collector, which meant that realistically it could not replace C++. Or rather, it could but you basically had two different Dlangs - one with GC and classes, and one without. It was arguably not necessary, because people already had GC languages that were fast enough and worked for their needs, and those who needed speed were better served by C++, which arguably isn't that bad of a language if you know how to use it. Rust is arguably the first real contender to C++'s reign because it really brings to the table features you'd be a fool to pass on. D was nice, but it was not worth the switch. Eliminating whole classes of bugs instead is.
- eftychis 3y agoI (also like sibling comments) respectfully disagree. Rust is aimed and focused as a safe C or a sane C++ substitute, and is meant to intermingle with both. It is not an application "high" level language. You can use it as such, which is great. For anything you would use C or C++ you can use Rust instead. As a cryptographer I find that great. Regardless of all the lack of latency or other control -- beyond fine tuning -- a garbage collected language makes critical memory choices we want to make instead. There are times we want to swap or use our own memory allocator, never mind having to add a garbage collector in the mix. (There is a good number of languages that scratch that itch, and you can likely link and use your C/Rust code with them.) As far as async: also respectfully disagree. Async is sugar for here is a Future<..>. If you want to poll it locally you can. You can scope it also. If you want to use a cross thread work stealing algorithm you can. But you need like memory management to consciously make these design decisions. This is similarly why a lot of things are not built in in C.
- j1elo 3y agoI heard this brilliant summary in a video from ThePrimeagen: In Rust, lifetimes color your types, like async colors your functions. It is a great condensed summary of what makes lifetimes a great difficulty of async Rust. It's a language that has the function coloring that is typically introduced by async (likewise in JavaScript), and on top of that the typesystem itself gets colored by lifetime annotations. You can have a well written and working program... then due to some new need or refactoring, wanting to add a 'static somewhere will cause it all to break down. It's part of the language, nothing bad with that. But it is an extra layer of difficulty that needs to be mastered. To me it shows that Rust might only be the initial step towards future programming languages where this kind of issue doesn't lean so much on developer knowledge.
- rcarr 3y agoCan you post a link to this video? Sounds interesting
- justincredible 3y ago[dead]