> the pattern of allocating a vec as pseudo-RAM, using indices as pseudo-pointers, and never freeing anything till the container itself is unused
Are you talking about hand-rolled arena allocation? I don´t see how a GC language would have a different behaviour as long as you also use arena allocation and you keep a reachable reference.
> There's nothing wrong with those techniques per se, but the language tends to paint you into a bit of a corner if you're not very good and very careful, so leaks are a fact of life in basically every major Rust project I've seen not written by somebody like BurntSushi
If I take 3 random major Rust projects like Serde, Hyper, and Tracing, none of which are written by BurntSushi, your claim is that they all suffer from memory leaks?
I wouldn't be surprised if that style of leak were more prevalent than one would expect. It's pretty subtle. But that link is the only such instance I'm aware of it happening to such a degree in crates I maintain. Maybe there are other instances. This is why I try to use `Box<[T]>` when possible, because you know that can't have extra capacity.
I find the GP's overall argument specious. They lack concrete examples.
Curious why you would call that a memory leak? The memory is still accounted for in the Vec and will get released properly when it deallocates, right? This looks like optimizing memory usage to me, not plugging a leak.
If you sit down and really think about it, I think you'll find that a precise definition of a leak is actually somewhat difficult.
I am nowhere near the first person to make this observation.
I point this out to avoid a big long thread in which we just argue about what the word "leak" means. You could absolutely define "leak" in a way that my example is not a leak. But I prefer a definition in which "leak" does include my example.
I do not care to litigate the definition. If you want to recast my example as a "space" leak instead of a "memory" leak, then I don't object, and I don't think it changes the relevance of my example. (Which I think is absolutely consistent with the context of this thread.) In particular, I don't think "memory leak" in this thread is being used in a very precise manner.
Short of using a different data structure, I'm not sure how you would get out of that one. The claim was that some of these leaks ("leaks"?) could be avoided by using a language with a GC. As far as I know, most modern languages' equivalent of Vec will do exactly the same thing, GC or not.
What does "You will get your vaults locally" mean?
Is it possible to export as a file, take that with you on whatever medium (eg. USB key, CD-ROM, future isolinear chip), put it on a brand new PC you built from scratch and never connected to the internet, and open it in some kind of standalone viewer?
That’s how 1Password used to work. Not sure how much of that is still left in the system these days.
Originally it was an app with no remote component. The vault was yours to look after. Most people kept it in Dropbox to make it accessible anywhere. The vault itself actually had an html file in it that you could open in a pinch that was able to decrypt secrets (only for reading, from memory).
Actually, 1Password had local syncing where you synced the vaults between devices on a local connection (I think it was point to point WiFi, so your internet dropped off, Bluetooth was less common then). So it was bucket brigade syncing.
Dropbox came later and security minded folks were wary. Honestly, I trust 1Password sync more than an encrypted db on a general purpose cloud file sync, but maybe that’s naive.
After auth, it downloads a copy of your vaults to your device from their servers.
Super contrived, but you could probably just copy the sqlite dbs of your vault it creates locally to another PC along with the 1Password installer and it might let you sign in with just your master key.
IMO, rustc_codegen_gcc is much more reasonable in scope. It also stands a chance of actually keeping up with subsequent Rust releases. I would be surprised if gcc-rs ever achieved any traction. Not to say it's not a fun project, but I can't see it replicating rustc.
It doesn't has to match rustc on nightly, only the 3-yearly releases. That seems doable, considering Rust has slowed down a bit, compared to super fast pace of change in early years. Regardless, it is always good to have alternate implementations, C++ has only benefited from it.
By "3-year releases" you're probably meaning Editions, but Rust Editions aren't like the C++ Standard, where they're bundling together a bunch of new features† the Edition changes language syntax, usually in small ways. The features people care about are released every six weeks and aren't saved up for new Editions.
For example, 1.69 released last week, so now:
SocketAddr::new(IpAddr::V4(Ipv4Addr::new(127, 0, 0, 1)), 8080)
... is a constant, at compile time the data structure equivalent to 127.0.0.1:8080 is constructed and baked into your binary program.
If I write a Rust program which relies on this for a constant, it works fine, because it is constant, but if I try to compile it with Rust 1.68 (from earlier this year) it won't work. If an alternative compiler doesn't have the features of Rust 1.69, then code written for Rust 1.69 won't necessarily work with it. Sometimes such differences will be tiny, other times huge.
† And notice that just because say, Modules was a C++ 20 feature, did not mean that you woke up one day in 2020 and had working Modules, C++ 20 is just an ISO document, the features have to get implemented by vendors, and then tested, and then shipped, which can take weeks, or months, or years.
Bad example because that's a library feature and doesn't involve explicit compiler support - in general you're right though, backwards-compatible compiler features (say, GATs) are added regularly and are available for all editions, not just the newest one.
That sounds a bit like using the latest features in the C or C++ standard, and then be surprised that many compilers cannot compile your code.
When a language develops quickly it is a good if people use the latest version to test new features to get experience.
When a language become mainstream, change will be much slower. Rust compilers will be shipped with operating systems, and people will write code that can be compiled by those older compilers.
There is a lot of C code that targets C99. Because that's what you can rely on if it has to run everywhere.
> When a language become mainstream, change will be much slower
I wouldn't assume that. JavaScript is about as mainstream as it gets, and that's also on a 6-weekly release schedule.
> Rust compilers will be shipped with operating systems, and people will write code that can be compiled by those older compilers.
Rust compilers are already shipped with operating systems, but for the most part (a few really foundational crates aside), people are not writing code that can be compiled by those older compilers. They're telling people to install a newer version of Rust. Which is pretty reasonable given how easy it is to manage rustc versions with rustup.
This may change with the creation of certified compilers for things like the automotive industry. But then, they're probably pretty used to maintaining their own library ecosystem anyway.
> There is a lot of C code that targets C99. Because that's what you can rely on if it has to run everywhere.
Yes, but one of the best things about Rust is that you can target the latest compiler version, and it still runs everywhere! That's why people don't like the possibility that this might change with the introduction of gcc-rs. We shouldn't accept crappy C toolchains as the standard.
I think there are a lot of people who don't want a new compiler every few months. Obviously, the people who arrive first at a new language are people like the latest greatest.
Take for example reproducible builds. Obviously, you only get the same binary output if you use the same compiler version. In that context, it doesn't make sense to keep around every version ever released of the Rust compiler.
In particular, if operating systems are going to use Rust in their kernels or base systems, then it is very unlikely that they are just going to use rustup to get the latest compiler. They will carefully vet each compiler release to make sure that everything that worked in the past, still works.
Rust being a compiler means that for every processor architecture somebody has to create the back-end. This means that if the current LLVM-based rust compiler will remain the only usable Rust compiler, there will be a lot of places where Rust cannot be used (unless LLVM will be the only compiler back-end in the future).
For now, at least, Rust for Linux actually requires Nightly features, so it's even less stable than the requirements of many relatively fast moving but popular Rust crates in userspace.
As with Firefox, Linux (ab)uses the compiler's own environment hack to say "No, I want nightly features, I don't care that this invalidates my warranty" despite using a stable compiler.
The actual version used is, I think, currently 1.66 (so, about three months old).
There is nothing crappy about stability. One of the most annoying things about more modern languages is this assumption that in so much of the ecosystem that I will go install the latest version of cool-lang compiler. I really like being able to build software with the tool chain that comes with my distro. Maintaining endless versions of all these things is a hassle.
> If I write a Rust program which relies on this for a constant, it works fine, because it is constant, but if I try to compile it with Rust 1.68 (from earlier this year) it won't work.
How would it not work? If your program compiles and runs with 1.69, then surely that's because it never tries to modify the value. But if your program never tries to modify the value, how would it fail with 1.68?
In this case, the fn `std::net::SocketAddr::new` was made a const fn recently--but was a regular fn before.
>that's because it never tries to modify the value
That's something different. If you want variables that are read-only, you don't need any extra keyword. It's the normal case:
let x = 5;
If you want a mutable variable, you add a `mut` keyword.
let mut x = 5;
But if you want a compile-time constant, you use `const` instead.
const x: u32 = 5;
The latter will be evaluated by the compiler at compile time (so interpreted) and substituted BEFORE the user runs the program. This is new-ish stuff and is slowly worming its way into the standard library.
The GP is missing a small bit of context: because this construct is now const, it can be used in const contexts, like to initialize a static variable. Doing so didn't work in 1.68, but does now in 1.69.
I recommend just reading or closing the privacy policy -- it's a single screen (on my device) and is quite reasonable. Because "whatever that is" is a godbolt link... and godbolt is one of the absolutely most valuable and greatest tools available for software developers who work in compiled languages. It's definitely worth becoming familiar with.
Gosh, this website is becoming reddit more and more everyday. YOU don't have a wikipedia entry. Are you also now classified as "whatever that is"? Of course not.
I would implore you to open your mind up to resources that aren't popular social media because that's where the real gold/value is in development/engineering.
I'm not claiming to be "one of the absolutely most valuable and greatest tools available" though. (Well, maybe the "greatest tool" part ;-) And if someone else claimed that about me, I'd think that either there was something very wrong with them, or that one of my parents had started using alt accounts I didn't know about.
Considering some of the software tools that do have dedicated wikipedia pages and subreddits, and that I'd never heard of godbolt before, I don't think it's out of line to be skeptical of such a hyperbolic claim.
(For what it's worth, I suspect if you took a random poll of Hacker News commenters, at least 90% would know what godbolt is. In fact, until I saw this thread, I thought it was just something like the C language which _everyone_ knows exists - it certainly deserves to be - although of course every day there's a new lucky 10000.)
The C equivalent would be a bunch of `in_addr`/`sockaddr_in`/`sockaddr` handling where you can do something wrong at basically every step of the way. You can't mess up the types in Rust, there's only one way they fit together.
Of course if you just want to convert a string to a SocketAddr (returning an error at runtime if it's invalid), you just do `let addr = "127.0.0.1:8080".parse();`.
Rust has a small(ish) but high quality stdlib. It does not aim to be Python. Like with any language, you have to know the ecosystem in order to be productive.
That said, sure, having a full-featured stdlib can be convenient. It's a matter of trade-offs. Having more content outside of the stdlib allows the ecosystem to evolve organically (and iterate quicker) and select the best approach to a given problem (which... could definitely have been an advantage for Python).
Wars are rarely won by single battles. That said, it really depends what period of history you are interested in. If you want to stick to the XXth century, Anthony Beevor regularly produces very readable books on WWII or the period immediately before (mostly concerned with the European theater).
If you are interested in more ancient history, I can warmly recommend Keagan's Peloponnesian War (which mostly draws on Thucydides eponymous masterwork).
Pedantic observation in case you didn't know: the word you were looking for was not "treaty", it was "treatise". If you did know, or if you don't care, ignore me.
I have no sympathy for right-wing extremists, but EU countries still operate within the rule of law. You cannot deport people who are member of a legal organization, and I don't think there is enough evidence to declare it a terrorist organization.
I feel making a case that they are either a terrorist or just a criminal organisation would be the easiest way to get rid of them outside of turkey. Such cases are really subjective so it shouldn't be that difficult. Just last month a greek far right political party was judged to be a criminal organisation. Grey wolves could share their fate.
There are a lot of ideas here sparking with (at least) border-line racism (against racist, but it's racism nevertheless).
But what you say stands out, because there is an easy solution that's not tainted by racism: These people are threatening other people. They form an organization to promote this. We as a society have a tool against that: Law.
We certainly have law, but they are not applied. It is hard to pick people from the mob an put them on the stand. And these people hide in a large groups. Same as Nazis did. Alone they are afraid and harmless. We seem to forget the history here. If we don't suppress extremism early we will have much bigger problems.
My point is that they were attacking representatives of the state that has committed genocide against them (and hasn't undergone meaningful reformation since + denies it to this day), not random people that are ethnically Turks. That's a gigantic difference, one is targeting a state, the other is targeting an ethnic group.
Are you talking about hand-rolled arena allocation? I don´t see how a GC language would have a different behaviour as long as you also use arena allocation and you keep a reachable reference.
> There's nothing wrong with those techniques per se, but the language tends to paint you into a bit of a corner if you're not very good and very careful, so leaks are a fact of life in basically every major Rust project I've seen not written by somebody like BurntSushi
If I take 3 random major Rust projects like Serde, Hyper, and Tracing, none of which are written by BurntSushi, your claim is that they all suffer from memory leaks?