I like the pragmatic approach to backwards compatibility (accepting relatively rare breakage that's not too hard to fix) instead of requiring 100% compatibility without exceptions
The idea that it would suddenly not be done because the compiler upgraded sounds like a potentially limitless amount of future work. Why would I want to invest in something that promises that?
I mean I understand that this can happen, my point is that we should code things in a way where the huge majority your code will still work no matter if you have an old rhel box or the latest archlinux, just like today we can port doom to pretty much any platform without too much trouble.
It’s very amusing to me that rust is trying to achieve a safety critical certification. Whatever version of the compiler that gets the cert will be cemented for the next 20 years.
Safety critical work / security-sensitive work is completely orthogonal to the rust release cycle.
Not to mention the vast amount of professionals who don’t have root on their runners / build nodes. Putting a ticket in every 3-6 weeks for a new compiler version takes… 3-6 weeks. People give up after a while.
> Not to mention the vast amount of professionals who don’t have root on their runners / build nodes. Putting a ticket in every 3-6 weeks for a new compiler version takes… 3-6 weeks. People give up after a while.
When I talked with the people at AWS responsible for updating both the myriad Java compilers in use as well as Rust for every project in the company, they claimed that updating Rust was always painless and didn't even appear as a blip in their radars compared to other similarly wide reaching updates.
I agree with your sentiment, but at some point backwards compatibility has to break. Rust handles it better than basically anything out there. If it bothers you, you should never try any other language except maybe plain, no-framework JS.
Plus, LLMs have really made upgrading a codebase for a compiler or dependency update into a trivial chore, at least for the most part.
This isn't the only way a Rust stable update can break your compile. It can also happen simply because they add a symbol to the standard library, and that isn't even protected by language editions.
Oh not only to the stdlib but to any lib! I thought that was crazy when you mentioned it but after reading the post I agree it’s a pragmatic approach. By the way Java does the same! The problem can be avoided by avoiding “star imports” in both Java and Rust, and at least in Java star imports are very rarely used for this exact reason (I remember my horror when I couldn’t call a method of List that I knew existed and it turned out a “import java.awt.*;” was the reason, that was a pain to figure out before AI and convinced me to never use star imports again).
Star imports aren't the only way, traits are another. Say you impl two traits and they end up both adding a symbol with the same name. Or you bring in an extension trait impl for a standard library type, and now the standard library adds a symbol with the same name as one in the extension trait.
To avoid those problems, you'd have to proactively disambiguate any item with its trait name, which is so un-ergonomic that people genuinely prefer the possibility of occasional breakage.
Your software is done, so why do you need to recompile it with a new version of the compiler? After all it’s done. Pin compiler version and problem solved. No limitless amount of future work.
For the most part, software does not exist in a vacuum. If there is a serious bug, or much improved feature, in a library you depend on, what do you do? Most likely you'll try to upgrade the library. Same deal for the compiler, it's a huge dependency.
If your project is truly done, by all means ship it on a N64 cartridge. I can't say I don't have sympathy for that attitude. But don't expect this is how the world works today. And don't forget, N64 cartridges weren't built using massive amounts of dependency, so it was easier to confidently declare something "done".
Because software is rarely done. Also you will likely to write newer programs with the same but improved language that doesn't have the warts in the earlier versions. Isn't it worth paying a small price for the improvement you get in the future?
Everything is a trade-off. Would you never ever under any circumstances accept even trivial breakage, even if it fixes a horrible wart that costs thousands of lost hours?
It’s not actually true that your software gets done, that’s essentially impossible unless you’re doing some kind of performance art project targeting a defunct platform from decades ago. Operating systems and libraries change underneath you all the time, even if you’re just using Linux and glibc, and if you’re not keeping up eventually your software is the legacy code keeping people stuck on an insecure OS, like those businesses who have to keep one box running DOS because of some ancient device driver for their equipment.
It’s better to plan for this in advance and use a stack where upgrades are done gracefully, rather than sticking your head in the sand and pretending it doesn’t happen.
Like Python 2 vs 3? That's what Editions were created to fix. With backwards incompatibility you will get ecosystem breakage and looming threat of future compilers not compiling your code.
The problem is that assuring no breaks ever with inference means you can't ever improve the inference algorithm nor update the stdlib. This is what triggered the time 0.35 breakage. I have a still incomplete/unmerged rustc lint to avoid the situation that caused that (a useless .into() that didn't get flagged because the clippy lint has false positives so it is not on by default) which should minimize the likelihood of that happening again (once I get off my ass and finish it, it just requires some side-quests to add more accurate tracking of cfg'd out items). This might be able to be mitigated by editions, but in practice crater helps to not need that (yet?).
This is not the only kind of breakage a project can experience. Trying to bring up an older project on a new platform will be a compile error (like building a project from 2018 on an Mx Mac), and updating the appropriate dependency to an appropriate version might become a chore. I have no idea how to improve the situation there to make that less painful, beyond having a simple database of crate-version+platform+rustc-version so that the toolchain could provide better/actionable messaging beyond "shit's broken".
I agree if you one-shot something, but that hasn't been my experience at all (unless the initial prompt is so detailed that creating it took considerable time).
For me it's more like being a chef but having a cook to cut up things and start cooking them, but you decide when it's done, what spices to put, and how to serve it - arguably the most fun and creative part.
I think it captures it perfectly, and the question is what are tomatoes here. Is it being challenged intellectually and proud of solving a puzzle, or is it getting praised, valued or paid?
People didn't stop solving sudokus when sudoku solvers appeared.
> Further, there’s at least the possibility on the part of the developer to claim that such usage is a “parody,” with parody and satire protected at the highest levels of American law through the application of First Amendment freedom of speech rights. However, courts will often require actual commentary to be made in order to extend such protections. In that way, a store name like “I CAN’T A” (or something far more clever) has a greater chance of succeeding than simply using a play on the word “store” in Scandinavian.
It sounds like they mostly did something like that:
> The lawyers then tell the developer, “You can of course easily make a video game set in a furniture store that does not look like, or suggest, an IKEA store.” The presumed game development experts go on to explain, “You can easily make changes to your game to avoid these problems, especially since you do not plan to release the game until 2024.”
They did that, but I think the 10 day deadline is quite heavy-handed. Also, would it be too difficult to offer a review and critique of a revised design (draft) to make sure that the matter can be resolved without further escalation?
Was it important part of the game that the store looks just like IKEA?
If yes, that probably makes it more likely that it was a trademark infringement and that IKEA was justified.
If no, it shouldn't be a big deal to change the colors, just to avoid potential confusion.
"at all" -> I would like to believe a government tender to wield more power than just being at the mercy of commercial market offerings.
"similar price to closed source" -> Good argument. But what if the _lower price_ is only lower thanks to a vendor lock-in? Thus, over a long period of time, you don't get a better deal? Furthermore, here an expensive reverse-engineering project had to discover the backdoors? What was its cost? Why can't the government have this work done (new cameras) on a contract basis?
First step: "we want this and that, you may choose the hardware freely, but the project source code will be perpetually licensed to the government to use and extend upon." Second step: "we have this source code from the last contract, we want another 1000 of these traffic cameras with improved specs/features."
The belief, that the market will do anything right, perpetuates this system of outsourcing everything to the market. Though I don't think it can work any other way, because nobody among the government workers wants to bear responsibility and liability. It's much easier to give party B the money and then argue with them based on the paper trails. This is what they've been trained to do after all.
reply