TL;DR: the article asks “how often does Rust change?” And the answer is “every six weeks”. Regardless of how big the changes are, you have to check every six weeks to see if something changed. Like someone said the other day on Lobsters, it’s like getting your pizza sliced into 42 slices versus 12. Sure it’s the same
amount of pizza but the cognitive load is higher.
The endless release posts with tons of stuff in them makes it feel like a lot is happening.
TFA seems to argue that yes, Rust changes a lot, but they aren’t “big” changes.
The problem is, big or not, I’m trying to learn the language and it feels like a moving target. As a neophyte I don’t know what’s important about the new version and what isn’t.
It’s also interesting to note the number of language changes in each release. Standard library changes are one thing, but language changes make things more difficult to learn.
For example, from the release of Python 3.5 (which introduced explicit async/await syntax, the last major syntax revision) in late 2015, there’s been around 40 Python releases across both Python 2.x and Python 3.x. If you only track Python 3, there were around 30 releases. The majority of these releases were bug fixes, with no or minimal standard library changes. There were of course some big standard library changes, but they were the exception.
In the same time frame, there were around 65 releases of Rust. These changes were not just bug fixes but all over the place.
My point is, with Rust I’d have to go through twice as many release notes and while the list of changes is generally small, it’s not always clear what’s a big change and what isn’t. With Python, it’s obvious that “fixed bug in how whatever works” is a bug fix. In Rust “this macro can now be applied to structures” doesn’t mean anything to a neophyte. Is that a big change? A small one? I don’t know.
Of course you can find counter examples in Python releases and bug fixes in Rust releases, but it just feels different. It feels impossible to keep up.
Compare to languages like C, where there were literally no changes between the last two standard revisions (C11 and C18), or Go which has had around 10 significant releases in five years and an explicit language standard that allows alternative implementations. (Go has had more than ten minor releases in that time, but anything where only the minor version changes are bug fixes).
I really like Rust. The type system is beautiful. The ownership model is gorgeous and innovative. The toolchain is fantastic. I just feel like using it would be on a treadmill, every six weeks poring over release notes to see what changed. Sure I can stick to Rust 2018, but by doing that I’ve run into third party code that used newer features that I didn’t know about. I’ve also run into trouble with distro-packaged Rust being “too old” to build something I find online. Sure I can use rustup, but I like having the OS packaged and supported tools.
(Again, of course, other languages have problems with the packaged version being too old but I’ve used Python for many years and not had that many problems and Rust for a couple of months and run into it twice).
I really, truly, think that Rust’s rapid release schedule is my and perhaps others’ primary barrier to adoption.
(Also, and this is a minor thing, but one of the major Rust contributors tweeted (or retweeted) a thing about how “COBOL was designed by women and just works and C was designed by men and it’s impossible to use securely.” Despite being inaccurate it also struck me as really unwelcoming. I was following that person’s Twitter feed specifically to start participating in the Rust community and that did not encourage me.)
Regardless of how big the changes are, you have to check every six weeks to see if something you rely on changed.
Or else what? If you only check every 12 weeks and read a pair of posts at a time, or only check once a year, what goes wrong? Your code will keep on working.
You miss out on anything new and nice, but only as much as if Rust was releasing less often.
If I want to use a third-party crate (which is almost a given because of the way Rust’s ecosystem is designed*), I need to audit that crate to make sure it’s secure and correct for my purposes. A rapidly-changing language makes it harder for me to read other people’s code regardless of how static my code is.
Among the changes Steve enumerated here, are there any that you feel would impact your ability to audit code without having known about the feature ahead of time?
I would think if you are auditing and encounter something unfamiliar like const fn or dyn Trait or some new standard library method, it’s easy enough to then learn about it via search and the Rust documentation.
For standard library methods, by far the main way people learn about them is not from release posts. They find them in documentation when searching for that functionality, or look it up when they see it in someone’s code. But in a safe language this works for the things classed as “language changes” as well. The feeling of being compelled to read the release notes isn’t well founded in my experience.
The ?, for example, was a problem for me getting started. I’d never seen it before and while I understand its purpose and it makes great sense, I then had to go say “okay this way of doing things that I’d already read about and started getting a handle on has two ways of expressing it.”
It’s not the end of the world, of course, or that difficult to understand, it just seems like there are a lot of little changes like that that increase cognitive load for me.
Again, this is just me and my opinion. Obviously Rust is very popular and this release strategy works for them. I’m just pointing out what has been a difficulty for me and, given the articles posted recently here, for some others too.
You now shifted from “changes every 6 weeks” is a problem to “this syntax change was a problem”. I believe you that ? Was confusing at first. However, the post shows that syntax changes are rare. If and when you do see it, you go look up what it is. No way that is happening every 6 weeks.
You now shifted from “changes every 6 weeks” is a problem to “this syntax change was a problem”.
You asked for an example from a limited set of possibilities, and I gave one. I didn’t imply my list was exhaustive. You then accuse me of changing my argument…because I gave you an example from one of the possibilities you asked and explained how I felt about it as a new user of the language.
I’ve said several times that this release schedule seems to work for Rust and a lot of people like it. I’ve also said that it seems to be a barrier to adoption for some people, myself included. I’m choosing to try to overcome because I think Rust is a fascinating and worthwhile language.
I don’t appreciate the implication that I’m somehow lying in my impression of a programming language or trying to “win” some debate here with gotcha tactics. That Rust changes often is a concern that a lot of people seem to have. As someone who has decided to learn the language, my impression is that I think this argument holds some water. I’ve presented my feelings in response to a topical post regarding the same issue.
I’m not denying that try/? change was an issue for you, but how could Rust avoid causing you that problem?
You’re saying that it should release less frequently, but I don’t see how that avoids the fact that it changed at all. If Rust didn’t change ? in 2016, it would change it in 2018. The result in both cases is the same: you — a Rust 2015 user — wouldn’t know the new syntax.
Nobody expects a language to be static. It’s like I said above, it’s easier to understand larger release notes twice a year than smaller release notes eight times a year, at least for me and obviously some other people.
There’s also the issue that, okay, it’s not Rust 2015….but it’s not Rust 2018 either. It’s something in between. I can’t say “oh yeah, that’s from Rust 2018,” I have to say “that’s from Rust 1.27.0” or whatever. There are many more versions of Rust to keep track of than just 2015 and 2018. I learn the ? syntax and that’s great…but that doesn’t teach me Rust 2018, it just teaches me part of one of eight or nine steps between the editions.
(And maybe I’m wrong but there doesn’t seem to be any concrete sum documentation for the Rust editions. The documentation at rust-lang seems to track stable and there doesn’t appear to be a “Rust 2015” snapshot of the documentation except in dead-tree form. Please correct me if I’m wrong. That means that as I’m studying the language, the documentation changes out from under me, not a lot but some.)
As I said above, a lot of people seem to like this sort of schedule with smaller changes more often. That’s great.
What I feel like some Rust advocates aren’t getting is that some people don’t like this schedule and the Edition mechanism doesn’t seem to totally fix the problems they have with it…and that’s okay. People are allowed to say “I like Rust but I’m having trouble with this part and it’s a major pain point.” Rather than try to “prove them wrong” about how they feel about the release schedule maybe acknowledge that it can be a problem for some people.
Why do you have to know from which version a thing is? I get that in C or C++ you have to know when each feature has been added, because there are different camps that settle on different past decades, but in Rust there’s no such thing. If you know a feature has been released, you can use it.
there doesn’t seem to be any concrete sum documentation for the Rust editions
But “Rust 2015” isn’t a version of Rust. It’s not a thing that can be targetted or snapshotted. It’s a parsing mode that changes interpretation of a few bits of syntax. It’s like "use strict" in JavaScript or Quirks Mode in HTML. “2015” parsing mode in latest Rust has all the new features of the latest Rust, except a couple that would conflict with some keywords/syntax in 2015.
The Rust team created a lot of confusion around this by marketing “cool new features we’ve released in the past year you may have missed” together with the “new parsing mode” switch, creating a false impression that “2015” and “2018” are different languages. They’re the same language with the same standard library, but “2015” mode can use async as a variable name.
Thanks for chiming in with this view. It makes a lot of sense.
However, I also feel that the Internet encourages this sort of firehose-style of releases. To many developers, a slow release cadence indicates project stagnation. And, to them, stagnation does not imply stability, but rather, a dead-end. I’m pretty sure the rust team puts releases frequently for other reasons that are more important, but there are virtues to signaling frequent project activity. IOW, I don’t think the Rust core team caters to the “always be committing” crowd, but they do try to stay on the collective radar.
FWIW I have been on both sides of the module change and I lost a few hours to trying to understand it. But that’s been about it so far. Haven’t ventured into asynchronous stuff yet.
Worth pointing out that Python has been around since the early 90s. How much did Python change at an equivalent point in its lifecycle? How would Python look if it had been locked in amber at that point?
People get hung up a lot on Python 2/3, but forget how much Python changed prior to that. During the Python 2.x series, the language gained:
The bool type
Opt-in unified type hierarchy and “new-style” classes with full operator overloading
Context managers/the with statement
Unified integral type
Integral versus “true” division
The set type
The logging module
The unittest and doctest modules
The modern import-hook system
Lazy iterables and the itertools module
Generator expressions
The functools module
Ternary conditional expressions
Absolute versus relative imports
Decorators
The format() method and formatting mini-language
The collections module
Abstract classes and methods
And on and on… sure, you could say that code written for Python 2.0 still worked on Python 2.7 (which wasn’t actually true – there were deprecations and removals in the 2.x series!), but idiomatic Python 2.7 contains so many things that would be unrecognizable to someone who knew only idiomatic 2.0 that it might as well be a completely different language.
No doubt, but early Rust was very different from modern Rust (there was a garbage collector at one point, major differences in the type system, etc).
I’m not saying Rust doesn’t deserve its youthful vigor and changes because of course it does. I also don’t think Python was as popular that early in its life as Rust is, relatively speaking (at least from my fuzzy memories of those ancient days where I worked mostly in Perl and C). Python didn’t really explode to be everywhere until after the 2.0 release, IIRC. Python 2.0 and Python 3.8 are of course pretty different, but there’s something like 20
years there versus ten for Rust with I would argue even greater changes.
Regardless of the relative age of the languages, I do think Rust’s change schedule is a barrier to adoption for a lot of people (with the anecdotal evidence of the couple of articles posted recently here talking about just that).
Again, that’s just me. I’m sure a lot of people like Rust’s release schedule and it seems to be working well given Rust’s rising popularity.
I wonder if he has decided that writing a better low level programming language might be a more significant undertaking than he thought, especially if he hopes to primarily program video games…
Who knows. In the episode, Jonathan Blow doesn’t appear to indicate that he sees Rust solving his specific problems. I appreciated all the lamentations and the insights and the ranting. After 20 years I feel every pain point they ranted on.
In contrast, in Rust, calling an async function does not do any scheduling in and of itself, which means that we can compose a complex nest of futures without incurring a per-future cost. As an end-user, though, the main thing you’ll notice is that futures feel “lazy”: they don’t do anything until you await them.
If I have 3 futures that I’d like to run in parallel, how do I actually “start” them running before I block on any of their results coming back?
For example:
a = async1()
b = async2()
c = async3()
// ideally a/b/c are all running "in the background" at this point
a.await
b.await
c.await
I think my favorite part is when they start off by complaining about all those new fangled features that Linux has, only to then sing the praises of filesystem level snapshots in ZFS.
Second place would be pointing to FreeBSD having one way of doing things (there aren’t enough FreeBSD developers left to maintain two ways) as great design, followed by being irritated that different Linux distributions have adopted one way of doing things via systemd.
Ultimately it feels like they are bewildered by the ability of the Linux world to maintain multiple distributions, each with different audiences and functionality. They prop up the argument that this somehow means a given user would need to be knowledgeable of and interacting with all distributions at any given time, rather than just picking one that has the qualities they need and following its conventions. Turns out when you have lots of users they come with lots of use cases, that’s where diversity across distributions really shines.
Also if I never saw another BSD Makefile again it’d be too soon.
The article isn’t very good, but neither is this counterargument. File system snapshots don’t break existing scripts or workflows. Replacing ‘ifconfig’ with ‘ip’, switching to systems, and so on does.
The article isn’t very good, but neither is this counterargument. File system snapshots don’t break existing scripts or workflows.
Of course they can. If your data sets are not fine-grained enough, then reverting to an older snapshot will result in a loss of data since the snapshot. If you use fine-grained snapshots, you can snapshot the system separate from data (e.g. /var). However, this can have other bad side-effects, e.g. a never version may update the format of an application’s data files, alter the database schema of an application that you are hosting etc. If you revert to an older snapshot, applications may stop working, because the data is incompatible with the older application.
Replacing ‘ifconfig’ with ‘ip’, switching to systems, and so on does.
That tired argument again. First of all, iproute2 (of which ip is part) has been around since 2001. It’s almost 20 years old! Secondly, most Linux systems still have net-tools (the package that contains ifconfig). E.g. on my machine:
Of course they can. If your data sets are not fine-grained enough, then reverting to an older snapshot will result in a loss of data since the snapshot
If my workflow doesn’t involve snapshots, how are they getting reverted? Are you implying that there’s something that’s automatically reverting things without a change in my behavior?
Sorry nickbp you seem to have read far more into my rant than I wrote. I’m not “bewildered by linux” as you put it, I’m just bored by wasting my time (and customer money) on needlessly fiddling with the carpet that we use to run our business on. I frequently work with small orgs who have their entire tech team being under ten people, and they simply don’t want to bother with “the stuff below the app”. zfs & jails are old tech, and even in 2016 for FreeBSD old tech. At that time, docker and containers outside the lxc world was evolving very very fast. The company had a choice between spending substantial time and effort keeping up to date with docker, or shipping valuable features to customers and the business. If you’re working for a company that has 200 people working on supporting devs, then that’s a totally different proposition.
TL;DR: the article asks “how often does Rust change?” And the answer is “every six weeks”. Regardless of how big the changes are, you have to check every six weeks to see if something changed. Like someone said the other day on Lobsters, it’s like getting your pizza sliced into 42 slices versus 12. Sure it’s the same amount of pizza but the cognitive load is higher.
TFA seems to argue that yes, Rust changes a lot, but they aren’t “big” changes.
The problem is, big or not, I’m trying to learn the language and it feels like a moving target. As a neophyte I don’t know what’s important about the new version and what isn’t.
It’s also interesting to note the number of language changes in each release. Standard library changes are one thing, but language changes make things more difficult to learn.
For example, from the release of Python 3.5 (which introduced explicit async/await syntax, the last major syntax revision) in late 2015, there’s been around 40 Python releases across both Python 2.x and Python 3.x. If you only track Python 3, there were around 30 releases. The majority of these releases were bug fixes, with no or minimal standard library changes. There were of course some big standard library changes, but they were the exception.
In the same time frame, there were around 65 releases of Rust. These changes were not just bug fixes but all over the place.
My point is, with Rust I’d have to go through twice as many release notes and while the list of changes is generally small, it’s not always clear what’s a big change and what isn’t. With Python, it’s obvious that “fixed bug in how whatever works” is a bug fix. In Rust “this macro can now be applied to structures” doesn’t mean anything to a neophyte. Is that a big change? A small one? I don’t know.
Of course you can find counter examples in Python releases and bug fixes in Rust releases, but it just feels different. It feels impossible to keep up.
Compare to languages like C, where there were literally no changes between the last two standard revisions (C11 and C18), or Go which has had around 10 significant releases in five years and an explicit language standard that allows alternative implementations. (Go has had more than ten minor releases in that time, but anything where only the minor version changes are bug fixes).
I really like Rust. The type system is beautiful. The ownership model is gorgeous and innovative. The toolchain is fantastic. I just feel like using it would be on a treadmill, every six weeks poring over release notes to see what changed. Sure I can stick to Rust 2018, but by doing that I’ve run into third party code that used newer features that I didn’t know about. I’ve also run into trouble with distro-packaged Rust being “too old” to build something I find online. Sure I can use rustup, but I like having the OS packaged and supported tools.
(Again, of course, other languages have problems with the packaged version being too old but I’ve used Python for many years and not had that many problems and Rust for a couple of months and run into it twice).
I really, truly, think that Rust’s rapid release schedule is my and perhaps others’ primary barrier to adoption.
(Also, and this is a minor thing, but one of the major Rust contributors tweeted (or retweeted) a thing about how “COBOL was designed by women and just works and C was designed by men and it’s impossible to use securely.” Despite being inaccurate it also struck me as really unwelcoming. I was following that person’s Twitter feed specifically to start participating in the Rust community and that did not encourage me.)
Or else what? If you only check every 12 weeks and read a pair of posts at a time, or only check once a year, what goes wrong? Your code will keep on working.
You miss out on anything new and nice, but only as much as if Rust was releasing less often.
Well partially because it’s not just my code.
If I want to use a third-party crate (which is almost a given because of the way Rust’s ecosystem is designed*), I need to audit that crate to make sure it’s secure and correct for my purposes. A rapidly-changing language makes it harder for me to read other people’s code regardless of how static my code is.
* this is not necessarily a negative thing
Among the changes Steve enumerated here, are there any that you feel would impact your ability to audit code without having known about the feature ahead of time?
I would think if you are auditing and encounter something unfamiliar like
const fnordyn Traitor some new standard library method, it’s easy enough to then learn about it via search and the Rust documentation.For standard library methods, by far the main way people learn about them is not from release posts. They find them in documentation when searching for that functionality, or look it up when they see it in someone’s code. But in a safe language this works for the things classed as “language changes” as well. The feeling of being compelled to read the release notes isn’t well founded in my experience.
The
?, for example, was a problem for me getting started. I’d never seen it before and while I understand its purpose and it makes great sense, I then had to go say “okay this way of doing things that I’d already read about and started getting a handle on has two ways of expressing it.”It’s not the end of the world, of course, or that difficult to understand, it just seems like there are a lot of little changes like that that increase cognitive load for me.
Again, this is just me and my opinion. Obviously Rust is very popular and this release strategy works for them. I’m just pointing out what has been a difficulty for me and, given the articles posted recently here, for some others too.
You now shifted from “changes every 6 weeks” is a problem to “this syntax change was a problem”. I believe you that ? Was confusing at first. However, the post shows that syntax changes are rare. If and when you do see it, you go look up what it is. No way that is happening every 6 weeks.
You asked for an example from a limited set of possibilities, and I gave one. I didn’t imply my list was exhaustive. You then accuse me of changing my argument…because I gave you an example from one of the possibilities you asked and explained how I felt about it as a new user of the language.
I’ve said several times that this release schedule seems to work for Rust and a lot of people like it. I’ve also said that it seems to be a barrier to adoption for some people, myself included. I’m choosing to try to overcome because I think Rust is a fascinating and worthwhile language.
I don’t appreciate the implication that I’m somehow lying in my impression of a programming language or trying to “win” some debate here with gotcha tactics. That Rust changes often is a concern that a lot of people seem to have. As someone who has decided to learn the language, my impression is that I think this argument holds some water. I’ve presented my feelings in response to a topical post regarding the same issue.
I’m not denying that
try/?change was an issue for you, but how could Rust avoid causing you that problem?You’re saying that it should release less frequently, but I don’t see how that avoids the fact that it changed at all. If Rust didn’t change
?in 2016, it would change it in 2018. The result in both cases is the same: you — a Rust 2015 user — wouldn’t know the new syntax.Nobody expects a language to be static. It’s like I said above, it’s easier to understand larger release notes twice a year than smaller release notes eight times a year, at least for me and obviously some other people.
There’s also the issue that, okay, it’s not Rust 2015….but it’s not Rust 2018 either. It’s something in between. I can’t say “oh yeah, that’s from Rust 2018,” I have to say “that’s from Rust 1.27.0” or whatever. There are many more versions of Rust to keep track of than just 2015 and 2018. I learn the
?syntax and that’s great…but that doesn’t teach me Rust 2018, it just teaches me part of one of eight or nine steps between the editions.(And maybe I’m wrong but there doesn’t seem to be any concrete sum documentation for the Rust editions. The documentation at rust-lang seems to track stable and there doesn’t appear to be a “Rust 2015” snapshot of the documentation except in dead-tree form. Please correct me if I’m wrong. That means that as I’m studying the language, the documentation changes out from under me, not a lot but some.)
As I said above, a lot of people seem to like this sort of schedule with smaller changes more often. That’s great.
What I feel like some Rust advocates aren’t getting is that some people don’t like this schedule and the Edition mechanism doesn’t seem to totally fix the problems they have with it…and that’s okay. People are allowed to say “I like Rust but I’m having trouble with this part and it’s a major pain point.” Rather than try to “prove them wrong” about how they feel about the release schedule maybe acknowledge that it can be a problem for some people.
Why do you have to know from which version a thing is? I get that in C or C++ you have to know when each feature has been added, because there are different camps that settle on different past decades, but in Rust there’s no such thing. If you know a feature has been released, you can use it.
There has been only one so far, and it’s here: https://doc.rust-lang.org/edition-guide/
Old docs are archived here: https://doc.rust-lang.org/1.30.0/
But “Rust 2015” isn’t a version of Rust. It’s not a thing that can be targetted or snapshotted. It’s a parsing mode that changes interpretation of a few bits of syntax. It’s like
"use strict"in JavaScript or Quirks Mode in HTML. “2015” parsing mode in latest Rust has all the new features of the latest Rust, except a couple that would conflict with some keywords/syntax in 2015.The Rust team created a lot of confusion around this by marketing “cool new features we’ve released in the past year you may have missed” together with the “new parsing mode” switch, creating a false impression that “2015” and “2018” are different languages. They’re the same language with the same standard library, but “2015” mode can use
asyncas a variable name.Thanks for chiming in with this view. It makes a lot of sense.
However, I also feel that the Internet encourages this sort of firehose-style of releases. To many developers, a slow release cadence indicates project stagnation. And, to them, stagnation does not imply stability, but rather, a dead-end. I’m pretty sure the rust team puts releases frequently for other reasons that are more important, but there are virtues to signaling frequent project activity. IOW, I don’t think the Rust core team caters to the “always be committing” crowd, but they do try to stay on the collective radar.
FWIW I have been on both sides of the module change and I lost a few hours to trying to understand it. But that’s been about it so far. Haven’t ventured into asynchronous stuff yet.
Worth pointing out that Python has been around since the early 90s. How much did Python change at an equivalent point in its lifecycle? How would Python look if it had been locked in amber at that point?
People get hung up a lot on Python 2/3, but forget how much Python changed prior to that. During the Python 2.x series, the language gained:
booltypewithstatementsettypeloggingmoduleunittestanddoctestmodulesitertoolsmodulefunctoolsmoduleformat()method and formatting mini-languagecollectionsmoduleAnd on and on… sure, you could say that code written for Python 2.0 still worked on Python 2.7 (which wasn’t actually true – there were deprecations and removals in the 2.x series!), but idiomatic Python 2.7 contains so many things that would be unrecognizable to someone who knew only idiomatic 2.0 that it might as well be a completely different language.
No doubt, but early Rust was very different from modern Rust (there was a garbage collector at one point, major differences in the type system, etc).
I’m not saying Rust doesn’t deserve its youthful vigor and changes because of course it does. I also don’t think Python was as popular that early in its life as Rust is, relatively speaking (at least from my fuzzy memories of those ancient days where I worked mostly in Perl and C). Python didn’t really explode to be everywhere until after the 2.0 release, IIRC. Python 2.0 and Python 3.8 are of course pretty different, but there’s something like 20 years there versus ten for Rust with I would argue even greater changes.
Regardless of the relative age of the languages, I do think Rust’s change schedule is a barrier to adoption for a lot of people (with the anecdotal evidence of the couple of articles posted recently here talking about just that).
Again, that’s just me. I’m sure a lot of people like Rust’s release schedule and it seems to be working well given Rust’s rising popularity.
Why would you compare that to Rust’s changes now and not to Rust’s pre-1.0 changes?
What’s the connection to Rust?
Jess and Bryan appear be be hedging their startup on Rust.
*edit: they talk about rust throughout the episode.
I wonder if he has decided that writing a better low level programming language might be a more significant undertaking than he thought, especially if he hopes to primarily program video games…
I don’t think so. You can find videos of him demonstrating the language in great detail on his YouTube page: https://www.youtube.com/user/jblow888/playlists
Who knows. In the episode, Jonathan Blow doesn’t appear to indicate that he sees Rust solving his specific problems. I appreciated all the lamentations and the insights and the ranting. After 20 years I feel every pain point they ranted on.
First mention I noted was somewhere around 1:31:14 (h:m:s) into the podcast or so.
If I have 3 futures that I’d like to run in parallel, how do I actually “start” them running before I block on any of their results coming back?
For example:
Or am I misreading what they’re saying there?
For this use case you can join multiple Futures into one, for more info: https://rust-lang.github.io/async-book/06_multiple_futures/02_join.html
That looks like exactly the solution for this. Thanks!
I’ve been meaning to get off of Cloudflare for the same reasons. I was planning on going to Fastly but will give BunnyCDN a look as well. Thanks!
I think my favorite part is when they start off by complaining about all those new fangled features that Linux has, only to then sing the praises of filesystem level snapshots in ZFS.
Second place would be pointing to FreeBSD having one way of doing things (there aren’t enough FreeBSD developers left to maintain two ways) as great design, followed by being irritated that different Linux distributions have adopted one way of doing things via systemd.
Ultimately it feels like they are bewildered by the ability of the Linux world to maintain multiple distributions, each with different audiences and functionality. They prop up the argument that this somehow means a given user would need to be knowledgeable of and interacting with all distributions at any given time, rather than just picking one that has the qualities they need and following its conventions. Turns out when you have lots of users they come with lots of use cases, that’s where diversity across distributions really shines.
Also if I never saw another BSD Makefile again it’d be too soon.
The article isn’t very good, but neither is this counterargument. File system snapshots don’t break existing scripts or workflows. Replacing ‘ifconfig’ with ‘ip’, switching to systems, and so on does.
The article isn’t very good, but neither is this counterargument. File system snapshots don’t break existing scripts or workflows.
Of course they can. If your data sets are not fine-grained enough, then reverting to an older snapshot will result in a loss of data since the snapshot. If you use fine-grained snapshots, you can snapshot the system separate from data (e.g.
/var). However, this can have other bad side-effects, e.g. a never version may update the format of an application’s data files, alter the database schema of an application that you are hosting etc. If you revert to an older snapshot, applications may stop working, because the data is incompatible with the older application.Replacing ‘ifconfig’ with ‘ip’, switching to systems, and so on does.
That tired argument again. First of all, iproute2 (of which
ipis part) has been around since 2001. It’s almost 20 years old! Secondly, most Linux systems still have net-tools (the package that containsifconfig). E.g. on my machine:If my workflow doesn’t involve snapshots, how are they getting reverted? Are you implying that there’s something that’s automatically reverting things without a change in my behavior?
Sorry nickbp you seem to have read far more into my rant than I wrote. I’m not “bewildered by linux” as you put it, I’m just bored by wasting my time (and customer money) on needlessly fiddling with the carpet that we use to run our business on. I frequently work with small orgs who have their entire tech team being under ten people, and they simply don’t want to bother with “the stuff below the app”. zfs & jails are old tech, and even in 2016 for FreeBSD old tech. At that time, docker and containers outside the lxc world was evolving very very fast. The company had a choice between spending substantial time and effort keeping up to date with docker, or shipping valuable features to customers and the business. If you’re working for a company that has 200 people working on supporting devs, then that’s a totally different proposition.