Indeed, that's a very important thing to foster! In fact, I published a post about this just two days ago: https://home.expurple.me/posts/non-profit-foss-solves-the-co...
302 karma · joined March 24, 2023
The article makes a point that permissively-licenced projects have the best survival characteristics, and that's why most (quality) software will eventually be permissively-licensed, while GPL will fade into obscurity and will be used only by enthusiasts why care about fairness more than they care about the actual quality of the software that they use.
No, it's the opposite. The premise of copyleft is forcing the dependents to contribute back to the community. If the corporations are writing proprietary replacements instead of contributing, copyleft has failed to deliver on its premise.
In practice, permissively-licensed projects get more contributions back and benefit the community more. Simple as that.
You're making a big stretch here. Sure, you can be left in the dust behind their proprietary fork, that's true: https://hypercritical.co/2013/04/12/code-hard-or-go-home
But your habitual workflow isn't "doomed". You can always fork and keep using the same open version of the project that you've always used. If the project is popular enough, there's usually a community that keeps maintaining that fork.
That's the deal that you get. Free software was never about "free upgrades forever". It's about the freedom to fork.
That's always been the deal. Open source is not a guarantee of free support forever! It's a guarantee that you can always fork and keep using the project (or even developing it further)
The article makes a case that this will eventually push GPL out of the mainstream. No one will use GPL because they "have to" (which is the whole premise of copyleft!). It will only be used by enthusiasts
1. In most areas, they eventually will!
2. If there is a permissively-licensed project in that area, at least there's a decent chance that the "reimplementation" will be a fork of that project. At that fork has a decent chance of staying open or even being merged back into the upstream. That benefits the community more than a proprietary from-scratch rewrite (which would follow from a GPL-only open-source scene)
You have gotten it across just fine.
We're trying to get across that no one is ever going to do "global" incompatible semantic changes in editions. That's been understood from the start. Exactly because of the problems that you describe.
Although, it's still possible to "sneak in" surprisingly useful semantic changes if they are local to the function body: https://doc.rust-lang.org/stable/edition-guide/rust-2024/tem...
I never said that. I said that it's more appropriate and productive.
> If it were really “preferable for writing such production software”, more people would be using it.
There are many valid reasons for not using it, even in new projects. Such as human preferences, lack of specific libraries, and simply not having time to learn yet another language for a non-10x benefit.
> the compiler does not carry the burden for you. It puts the burden of writing code in a way that satisfies the Rust lifetime management design on you, and that’s what you’ll be doing forever.
It carries a different burden for me. In exchange for the burden that you mention, I don't worry about mutable aliasing bugs (including data races), breaking the code by refactoring it, manually unit-testing basic properties that could be types, debugging non-obvious non-local effects (such as exceptions and null values invisibly propagating through the layers of the app), micro-optimizing the performance manually, and so on. The benefits are known. I've almost forgot how to use a debugger at this point.
It's a tradeoff. I find it more comfortable and less cognitively-taxing to work this way, once the initial learning curve is behind. Less unpredictable problems to distract you from solving the problem. The borrow checker problems largely go away as you get more comfortable with it. And it's a skill that's instantly transferrable between all Rust projects, unlike project-specific defensive practices in other languages (the "manual hardening" needed to get decent quality). It's a long-term investment that automates a small, but not insignificant part of your work.
> There zero proof that Rust software is higher quality than equivalent e.g. Swift or Java.
The Google's director of engineering gave a talk saying that their Rust teams are just as productive as their Go teams, while also enjoying "a decreased defect rate over time": https://www.reddit.com/r/rust/comments/1bpwmud/media_lars_be...
> The memory-safety trick only works against C and C++.
That's absolutely true, and that's an important thing to keep in mind when framing discussions about Rust.
You're correct that the possible changes in editions are very limited. But editions don't hinder interoperability in any way. They are designed not to. Today, there are no interoperability problems caused by editions specifically.
> compromises will be required, specially regarding possible incompatible semantic differences across editions.
That's just an assumption in your head. 4 editions later, it still hasn't manifested in any way.
...have already released a broken prototype that appears to be working for now.
I'm yet to see a case where manually "hardening" your software is faster than writing a "similarly-good" program in Rust. That's just anti-automation. Why repeat the same work in every project and bloat your codebase, when the compiler can carry that burden for you? In my experience, Rust makes you write production-grade software faster than when using other languages.
> But selling this approach as a general solution is disingenuous.
I agree! There are legitimate cases where releasing a broken prototype as quickly as possible is important. There's room for that.
But I agrue that it's not the case for most "serious" production software that would be maintained for any period of time. And that Rust is the preferable option for writing such production software.
Not sure what you're talking about. Any specific examples?
> Also it requires everything to be compiled with the same compiler, from source code.
It's not related to editions at all. It's related to not having an implicit stable ABI.
It's possible have a dynamic Rust library that exposes a repr(C) interface, compile it into an .so using one version of the compiler, and then compile the dependent "pure Rust" crates using another compiler that's just going to read the metadata ("headers") of that library and link the final binary together. Same as in C and C++. You just can't compile any Rust code into a stable dynamic library, by defalut. (You can still always compile into a dylib that needs a specific compiler version)
Python is absolutely not straighforward, it's a huge language with many moving parts and gotchas.
Although, I admit, both are very easy to start programming in and to start shipping broken projects that appear working at first. They are good for learning programming, but terrible for production.
> Rust didn’t really solve memory safety, it just pushed all the complexity into the type system.
Yes, that's what it did, and that's the right tradeoff in most cases. Where the compiler can't make a reasonable default choice, it should force the programmer to make a choice, and then sanity-check it.
> If one was struggling with memory errors in C++ that’s nice. If one was using Java, that still sucks.
It's nice for those struggling with uncaught exceptions, null pointer bugs, mutithreading bugs, and confusing stateful object graphs in Java.
I use Rust. From what I've read, Swift seems better than the others, with Typescript and Go following closely. All four happen to be widely praised in this thread.
To clarify, I don't have "professional experience" with every popular language, including Swift and Typescript too.
We have many popular high-level languages, but I disagree that they are good. Most of them are fragile piles of crap unsuitable for writing anything larger than a throwaway script.
(In my subjective and biased assessment, which is hovewer based on professional experience)
No, you can't. In the sense that the compiler doesn't have exhaustiveness checks and can't stop you from accessing the wrong variant of a union. An Option in C would be the same as manually written documentation that doesn't guarantee anything.
std::optional in C++ is the same too. Used operator* or operator-> on a null value? Too bad, instant UB for you. It's laughably bad, given that C++ has tools to express tagged unions in a more reliable way.
> And then, also Rust can not express everything in the type system. (And finally, there are things C can express but Rust can't).
That's true, but nobody claims otherwise. It's just that, in practice, checked tagged unions are a single simple feature that allows you to express most things that you care about. There's no excuse for not having those in a modern language.
And part of the problem is that tagged unions are very hard to retrofit into legacy languages that have null, exceptions, uninitialized memory, and so on. And wouldn't provide the full benefit even if they could be retrofitted without changing these things.