5 ms·

Burntsushi is a serious power contributor to the Rust ecosystem. Obviously ripgrep and the regex crate are top tier. Big thank you from someone who uses your wo

by jjice 4y ago

Burntsushi is a serious power contributor to the Rust ecosystem. Obviously ripgrep and the regex crate are top tier. Big thank you from someone who uses your work regularly :) Also really cool to see more and more rust crates releasing their 1.0 versions. I feel like one of the big jumps for Rust (for me at least) will be when critical non-stdlib libraries are all 1.0 and there's less "which one do I choose". I understand competition is good in situations (more so opinionated frameworks) but I do love that I don't think about what regex library to choose since there's one obvious winner with tons of community support and resources.

m12k 4y ago
> I understand competition is good in situations But also, consolidation at a given layer of an ecosystem allows that layer to be treated as a foundation so the next layer on top of it can be where the competition happens instead
- bowsamic 4y ago
  I don't think always that's a good thing. Every ecosystem I've seen that happen in has just bred an army of lazy developers who rely on libraries for basically everything.
  - xxpor 4y ago
    That's not being lazy, it's being sane. Nothing's worse than screwing up something basic that should have been handled by a library. Leftpad might be on the too many libraries end, but that's an extreme example.
    - bowsamic 4y ago
      I don't agree with the assertion that programmers should defer programming to others whenever possible
      - vladvasiliu 4y ago
        I don't read it as "whenever possible", but rather "for non-trivial problems that have already been solved".
        bowsamic 4y ago
        To me there is not much difference between that and "whenever possible"
        xxpor 4y ago
        I'd agree with that. Of course, figuring out where the "non-trivial" line is is the hard part ;)
      - xxpor 4y ago
        As a programmer, your value prop/job/business isn't delivering code. It's solving business problems. If a library lets you do that faster, then it's a good idea. Flexing your ability to code has no place in the real world.
        bowsamic 4y ago
        Are you saying that there is no value in honing your skills as a programmer?
        orf 4y ago
        No. He’s saying that while another developer gets stuck in the weeds implementing their own byte-string library, he’ll be past that and shipping the feature that needs a byte-string implementation to the customer or end user. It’s the same reason you’re writing this using someone else’s web browser, on someone else’s kernel, on someone else’s hardware. And it’s not because you’re a bad/lazy programmer or because there’s no value in understanding how all of that works.
        bowsamic 4y ago
        I don't (and won't ever) get it, sorry
    - lesuorac 4y ago
      The moral of story of leftpad should not have been people use too many dependencies. It should have been don't arbitrarily grab code from the web for your production apps. If you had any form of caching where a validated library (i.e. leftpad) would be used for your builds instead of just reaching out everytime then your system wouldn't break. Nor would a random cryptominer get into your app. -- Libraries should be a good thing in that it's definitely easier to review a line of code for a bug than write that same line bug-free. Of course, people (companies) rarely review the libraries they use (sometimes they physically/legally can't) so there are some outs.
dhosek 4y ago
I’ve always been a bit puzzled by the reluctance to release 1.0 I can understand if you’re flailing around about what the API should be or if you don’t think your code actually works, but otherwise, why not start at 1.0? The first public release of finl_unicode was 1.0 (there ended up being 1.0.1 and 1.0.2 to fix some issues with docs.rs requirements that could not be anticipated), but the API was predetermined and I have good tests so I know my code is accurate so why not release as 1.0?
- pizza234 4y ago
  Following semantic versioning, libraries are essentially allowed to change very liberally on 0.x, so it makes sense to reach 1.0 only once the crate/API is stable.
  - burntsushi 4y ago
    Just to be super clear, while that is true of semver, Cargo implements something a little different. Namely, Cargo treats any difference in the leftmost non-zero digit of a version number as semver incompatible. So if you have 'foo = "0.1.2"' and then 'foo' 0.2.0 is published, Cargo will not automatically upgrade you when you run 'cargo update'. You'll have to explicitly opt into the new 0.2.0 version because it's treated as a potentially breaking release. In effect, this lets you get the benefits of semver (communication of breaking changes) without publishing 1.0. Thus, there is less pressure in the Rust crate ecosystem to publish 1.0.
- loudmax 4y ago
  I interpret a major version number release as a commitment that the API won't make breaking changes. So releasing a 1.0 version of a library is kind of like promising that you'll make some attempt not to drastically alter the behavior. If you're doing this as a hobby or side project you might not want to make that kind of commitment.
- burntsushi 4y ago
  OK, so unfortunately, this issue gets really tangled. I could give you a short answer, but that will invite a question. And then my answer to that question is likely to invite another. I've had this conversation many times and it always goes the same way. So I will try to anticipate those questions, but... it's subtle. > I’ve always been a bit puzzled I'll respond with my reasons, but I want to emphasize that I am be descriptive, not prescriptive. The main reason why I don't just start with 1.0 out of the gate is because I generally want 1.0 to indicate some level of maturity and stability. That is, once I publish 1.0, ideally, I won't publish a 2.0. Or if I do, that timeline will be measured in years. It takes a while to get that kind of confidence with a library's API. If I had started with bstr 1.0, then this blog post would be talking about bstr 3.0. Not 1.0. Empirically, bstr 1.0 would not have been the commitment to stability that I want 1.0 to mean. So, first question at this point is usually: well why not just increase x in x.0.0 as needed? It's okay to have 1.0 and 2.0 and 3.0. We have semver after all! What I say to that is, yes, absolutely, you can do that. But it's absolutely a preference with respect to how often you want to release breaking change releases. My preference is to do it very rarely. Or as rarely as I can manage. The main practical reason for it is that breaking change releases create churn, and they lead to transition periods where, in the best of cases, compilation times take a hit. For example, if I released regex 2.0, no code would break. At some point, people would start migrating to it. And for some period of time, it's likely that many projects would be building both regex 1.0 and regex 2.0 in their dependency trees. regex is not exactly lightweight, and so people are going to hunt down these issues in their trees and get everyone to migrate to regex 2.0. It's work. It's tedious. It's annoying. If I start putting out new breaking change releases of the regex crate frequently, then I'm going to annoy people in a way that is proportional to the frequency of releases. By committing to a policy that 1.0 means "I'm unlikely to publish a breaking change release for at least a few years," then that 1.0 is going to be a signal to folks that they are signing up for a dependency that is probably not going to cause them churn. It's also especially important for bstr, because folks want to use it as a public dependency. So if I'm releasing semver incompatible releases frequently, then that's going to cause a lot of painful churn for users of bstr. It no longer just becomes a matter of compilation times. But you'll need to get your entire dependency tree migrated over, or else you risk things not working if multiple crates try to interoperate via bstr's API. I suppose the next question at this point is, "but it's just a version number, why attach special significance to it that isn't in semver?" semver is useful for communicating breaking changes. And I think it's also useful to use the version number to communicate stability as well. But to be totally clear here: I am (EDIT) NOT trying to be an advocate here. I'm not saying this is what you or what everyone should do. There are trade offs here. I tend to build library crates that others build on, so my bias is to move slowly. But if I built crates (and I do) that are closer to the application (or even an application itself), then I'm generally much happier to just push out breaking change releases at a higher frequency. I think the last question is, "but anything goes in 0.x.y, so says semver, so now people never know if they're getting a breaking release or not." Indeed, that is what semver says, and if that were how Cargo implemented semver, I'd probably start with 1.0 releases. (Or at the very least, publish a 1.0 release much much sooner.) But Cargo does not implement semver that way. With Cargo, 0.x.y is semver incompatible with 0.(x+1).z. That is, incrementing the leftmost non-zero digit in a version creates a new semver incompatible release from Cargo's perspective. So I get all the benefits of semver when I use 0.x.y, without needing to publish 1.0.0. The main downside is that the 'minor' and 'patch' components of the version number get collapsed into one number. But I can live with that until I publish 1.0.

by jjice 4y ago

m12k 4y ago

> I understand competition is good in situations But also, consolidation at a given layer of an ecosystem allows that layer to be treated as a foundation so the next layer on top of it can be where the competition happens instead

bowsamic 4y ago
I don't think always that's a good thing. Every ecosystem I've seen that happen in has just bred an army of lazy developers who rely on libraries for basically everything.
- xxpor 4y ago
  That's not being lazy, it's being sane. Nothing's worse than screwing up something basic that should have been handled by a library. Leftpad might be on the too many libraries end, but that's an extreme example.
  - bowsamic 4y ago
    I don't agree with the assertion that programmers should defer programming to others whenever possible
    - vladvasiliu 4y ago
      I don't read it as "whenever possible", but rather "for non-trivial problems that have already been solved".
      - bowsamic 4y ago
        To me there is not much difference between that and "whenever possible"
      - xxpor 4y ago
        I'd agree with that. Of course, figuring out where the "non-trivial" line is is the hard part ;)
    - xxpor 4y ago
      As a programmer, your value prop/job/business isn't delivering code. It's solving business problems. If a library lets you do that faster, then it's a good idea. Flexing your ability to code has no place in the real world.
      - bowsamic 4y ago
        Are you saying that there is no value in honing your skills as a programmer?
        orf 4y ago
        No. He’s saying that while another developer gets stuck in the weeds implementing their own byte-string library, he’ll be past that and shipping the feature that needs a byte-string implementation to the customer or end user. It’s the same reason you’re writing this using someone else’s web browser, on someone else’s kernel, on someone else’s hardware. And it’s not because you’re a bad/lazy programmer or because there’s no value in understanding how all of that works.
        bowsamic 4y ago
        I don't (and won't ever) get it, sorry
  - lesuorac 4y ago
    The moral of story of leftpad should not have been people use too many dependencies. It should have been don't arbitrarily grab code from the web for your production apps. If you had any form of caching where a validated library (i.e. leftpad) would be used for your builds instead of just reaching out everytime then your system wouldn't break. Nor would a random cryptominer get into your app. -- Libraries should be a good thing in that it's definitely easier to review a line of code for a bug than write that same line bug-free. Of course, people (companies) rarely review the libraries they use (sometimes they physically/legally can't) so there are some outs.

dhosek 4y ago

I’ve always been a bit puzzled by the reluctance to release 1.0 I can understand if you’re flailing around about what the API should be or if you don’t think your code actually works, but otherwise, why not start at 1.0? The first public release of finl_unicode was 1.0 (there ended up being 1.0.1 and 1.0.2 to fix some issues with docs.rs requirements that could not be anticipated), but the API was predetermined and I have good tests so I know my code is accurate so why not release as 1.0?

pizza234 4y ago
Following semantic versioning, libraries are essentially allowed to change very liberally on 0.x, so it makes sense to reach 1.0 only once the crate/API is stable.
- burntsushi 4y ago
  Just to be super clear, while that is true of semver, Cargo implements something a little different. Namely, Cargo treats any difference in the leftmost non-zero digit of a version number as semver incompatible. So if you have 'foo = "0.1.2"' and then 'foo' 0.2.0 is published, Cargo will not automatically upgrade you when you run 'cargo update'. You'll have to explicitly opt into the new 0.2.0 version because it's treated as a potentially breaking release. In effect, this lets you get the benefits of semver (communication of breaking changes) without publishing 1.0. Thus, there is less pressure in the Rust crate ecosystem to publish 1.0.
loudmax 4y ago
I interpret a major version number release as a commitment that the API won't make breaking changes. So releasing a 1.0 version of a library is kind of like promising that you'll make some attempt not to drastically alter the behavior. If you're doing this as a hobby or side project you might not want to make that kind of commitment.
burntsushi 4y ago
OK, so unfortunately, this issue gets really tangled. I could give you a short answer, but that will invite a question. And then my answer to that question is likely to invite another. I've had this conversation many times and it always goes the same way. So I will try to anticipate those questions, but... it's subtle. > I’ve always been a bit puzzled I'll respond with my reasons, but I want to emphasize that I am be descriptive, not prescriptive. The main reason why I don't just start with 1.0 out of the gate is because I generally want 1.0 to indicate some level of maturity and stability. That is, once I publish 1.0, ideally, I won't publish a 2.0. Or if I do, that timeline will be measured in years. It takes a while to get that kind of confidence with a library's API. If I had started with bstr 1.0, then this blog post would be talking about bstr 3.0. Not 1.0. Empirically, bstr 1.0 would not have been the commitment to stability that I want 1.0 to mean. So, first question at this point is usually: well why not just increase x in x.0.0 as needed? It's okay to have 1.0 and 2.0 and 3.0. We have semver after all! What I say to that is, yes, absolutely, you can do that. But it's absolutely a preference with respect to how often you want to release breaking change releases. My preference is to do it very rarely. Or as rarely as I can manage. The main practical reason for it is that breaking change releases create churn, and they lead to transition periods where, in the best of cases, compilation times take a hit. For example, if I released regex 2.0, no code would break. At some point, people would start migrating to it. And for some period of time, it's likely that many projects would be building both regex 1.0 and regex 2.0 in their dependency trees. regex is not exactly lightweight, and so people are going to hunt down these issues in their trees and get everyone to migrate to regex 2.0. It's work. It's tedious. It's annoying. If I start putting out new breaking change releases of the regex crate frequently, then I'm going to annoy people in a way that is proportional to the frequency of releases. By committing to a policy that 1.0 means "I'm unlikely to publish a breaking change release for at least a few years," then that 1.0 is going to be a signal to folks that they are signing up for a dependency that is probably not going to cause them churn. It's also especially important for bstr, because folks want to use it as a public dependency. So if I'm releasing semver incompatible releases frequently, then that's going to cause a lot of painful churn for users of bstr. It no longer just becomes a matter of compilation times. But you'll need to get your entire dependency tree migrated over, or else you risk things not working if multiple crates try to interoperate via bstr's API. I suppose the next question at this point is, "but it's just a version number, why attach special significance to it that isn't in semver?" semver is useful for communicating breaking changes. And I think it's also useful to use the version number to communicate stability as well. But to be totally clear here: I am (EDIT) NOT trying to be an advocate here. I'm not saying this is what you or what everyone should do. There are trade offs here. I tend to build library crates that others build on, so my bias is to move slowly. But if I built crates (and I do) that are closer to the application (or even an application itself), then I'm generally much happier to just push out breaking change releases at a higher frequency. I think the last question is, "but anything goes in 0.x.y, so says semver, so now people never know if they're getting a breaking release or not." Indeed, that is what semver says, and if that were how Cargo implemented semver, I'd probably start with 1.0 releases. (Or at the very least, publish a 1.0 release much much sooner.) But Cargo does not implement semver that way. With Cargo, 0.x.y is semver incompatible with 0.(x+1).z. That is, incrementing the leftmost non-zero digit in a version creates a new semver incompatible release from Cargo's perspective. So I get all the benefits of semver when I use 0.x.y, without needing to publish 1.0.0. The main downside is that the 'minor' and 'patch' components of the version number get collapsed into one number. But I can live with that until I publish 1.0.