4 ms·
Correct. It's the extremely rapid pace of development in the language combined with enthusiast devs using the latest and greatest that make it unsuitable for ge
by superkuh 6y ago
Correct. It's the extremely rapid pace of development in the language combined with enthusiast devs using the latest and greatest that make it unsuitable for general use. Part of this stems from Rust almost requiring installing with rust-up instead of from repos. This encourages the bad behavior.
Eventually the Rust dev community will grow enough to have non-language-specific-enthusiasts devs as a majority and it will slow down and begin to target actually stable releases. But as of now you have about 5 months functionality per "stable" release.
- darkwater 6y agoI understand your point and kind of agree but you should also keep in mind that Rust is a relatively young language. I would treat these as growing pains.
- rapsey 6y agoStrange how a language according to you is unsuitable for general use. Yet it is used by Google, Facebook, Apple, Amazon, Dropbox, Microsoft, Mozilla, Huawei, etc. You live by some principles. Most people don't care about the principles you seem to care very much about. Most just have problems that need solving and Rust is the best tool for solving them. If the tool works differently to how they are used to working, they adapt and get on with their lives.
- hu3 6y agoThis comparison doesn't make sense. Not everyone has Google or Facebook money and engineering. Just because they can doesn't mean you can. They solve Google problems. And they use Rust to solve specialized problems because at their scale it is worth squeezing every advantage. For mortals like you and me most problems should be faced with a completely different mindset.
- rapsey 6y agoWhat does money have to do with using rustup?
- hu3 6y agoWhere did you mention rustup? Perhaps you replied to the wrong message? I'm addressing your statement that says a language is of general use if used by the likes of Google and Facebook. They have infinite amounts of enginering and very special problems to solve. What makes sense for them often does not for smaller teams solving trivial problems. > Strange how a language according to you is unsuitable for general use. Yet it is used by Google, Facebook, Apple, Amazon, Dropbox, Microsoft, Mozilla, Huawei, etc.
- xxpor 6y agoEvery modern language works like this. rbenv, pyenv, nvm, gvm all exist for a reason. People don't want to wait for package managers. I go out of my way to avoid dependencies on them, because all they do is break things. Hard drive space is cheap, things should be self contained.
- josephg 6y agoI see rust as following the evergreen model - along with nodejs, chrome, Firefox and others. In this software model the authors make strong stability and backwards compatibility guarantees. For example, as I understand it the rust compiler team literally compiles every public crate with each version of the rust compiler to make sure they haven’t broken anything. The platform generally expects users to mostly keep up to date - as a web developer I can now use new features in chrome and FF within a month or so of the feature being released. Gone are the days of leaving behind large swathes of users because they’re still using FF 4.0 or IE 6. Nodejs has its own support table. I don’t care what version of nodejs Debian LTS has; when version 8 of nodejs stopped being officially supported and maintained, I immediately dropped support for it in my npm packages. The “minimum supported rust version” flag in cargo will help with this going forward. But more generally I think this model of software development makes sense and we’ll see it more and more going forward. There was a kernel bug a few months ago caused by a bug in an old version of gcc. The gcc bug was fixed years ago but the patch was never backported to ancient gcc versions. Some distros were compiling Linux using ancient gcc versions, and then got upset when they ran into problems. The answer here is for gcc to say the same thing nodejs does - “these versions are supported and get bug fixes. These versions do not. Use old versions at your peril - they have known bugs.” Explicit support periods is better than vague, ambiguous expectations that software will work forever. Microsoft has the same policy with windows patches. I think the era where it makes sense for apt to carry that burden by serving us ancient software packages is slowly coming to an end. As software packages take responsibility for evergreen stability, it also makes sense for users to get evergreen software. It would be nice if we could do that without needing app specific version managers like rustup and nvm.
- est31 6y agorustc is already exempt from Debian's policies to not update most software after a stable release. It's still not enough because Debian lags behind 2-3 releases. It has a high standard for supporting various niche targets and there are regressions every now and then, and often there is simply no volunteer time to package all the libraries.
- DougBTX 6y agoDebian has a policy for a packaging Rust crates: https://wiki.debian.org/Teams/RustPackaging/Policy https://wiki.debian.org/Teams/RustPackaging/Policy If you restrict yourself to packages in the repo, won’t that resolve the issue? The idea of a distro is that all the packages in the distribution should play nicely together, but if you go outside that then version compatibility won’t be handled for you.
- pornel 6y agoDebian's repackaging is not useful for Rust developers. It's a tiny tiny fraction of Rust packages (Rust has over 60,000 now), and it's not integrated with Rust tooling. It's not useful for anything other than the few binaries written in Rust that Debian ships. Debian's policies are simply incompatible with the Chrome-like "evergreen" release model that Rust uses. I feel sorry for anyone who tries to use Debian's Rust. It is an awful experience.
- nindalf 6y agoJust to summarise your position - you will only use an old compiler because that’s your preferred source of installing tools - you will only use the latest and greatest packages that require the newer compilers. And this is somehow the languages fault. The language needs to fix the problem of library authors using language features? Seems to me like it’d be easier for you to relax one of your two requirements. They’re fundamentally incompatible.
- est31 6y agoIn the C++ world there is no such problem. You can usually compile most projects using compilers found in stable distros. Maybe not all projects with LTS distros, but at least the ones which are released once or twice per year. In debian, the rust compiler is updated more often than other programs and it's still not enough.
- jacobolus 6y agoC++ is 35 years old or something, changes extremely slowly, has a mostly static programmer community, and has a wide range of compilers in current use. When new versions of the C++ spec show up it can take months for compilers to all catch up, but few C++ developers are in a rush to adopt new features.