Python is one of the worst offenders here. I don't think Python's poor behaviour should excuse Lua's.
But I can also see why Python is making breaking changes - a lot of Python is so bad it really makes sense to clean it up. I dunno if Lua is in that situation.
Anyway I think I would look to other languages like Go, Rust, Java, C++ which do a much better job. I don't think Go or Rust have any backwards incompatibilities (at least very very few) and C++ has a small number but they're for stuff that is truly ancient or almost completely unused. It's totally possible if you care about it.
Yes but that tracks issues of all severities and with all of GitHub's services of which there are a great many. Also "days since incident" is a terrible metric because it doesn't capture how long the incidents last.
For example the latest incident is that copilot had degraded performance with Fable due to an Anthropic issue. It only last 18 minutes, only affected part of a part of their service, and it wasn't even their fault!
That's very different to "all of GitHub is down for 7 hours".
Ah yeah looks like the latest 19.1 release from June.
But it also seems to suggest it's only a UI change. Is is possible to do stacked MRs across forks? Does it not still suffer from the flaw GitHub has (or had, hopefully) - you create one MR, myfork:feature_0 -> upstream:master. That's fine, but then you want to create the second MR targeting the first MR, myfork:feature_1 -> ???:feature_0, only you can't. feature_0 doesn't exist in the upstream and there's no point creating an MR targeting your own fork.
Yes they do. I don't think it's totally unreasonable. Slow compile time is a big productivity drain. But it's not as bad as people often make out for Rust - in large part because compilation speed has at least doubled since Rust 1.0, but its reputation is still based on the 1.0 compile times.
And some specific projects do have substantially bad compile times. When your incremental compilation time is 20 seconds where in other languages it's instant... That's notably worse.
But I don't think it should be a deal breaker. C++ has dealt with similarly bad compile times for decades and people don't like it but it's never been enough for most of them to switch to another language.
I am now pursuing opportunities to return to paid work on the Rust compiler. Wish me luck!
Someone (Rust Foundation?) pay this man! Compilation speed is one of the few weaknesses of Rust and even though I think that in 95% of cases it's actually not that bad and people are just looking for an excuse to not use Rust, it would be great to remove that excuse. (And faster compilation is always nicer anyway!)
Ah I see. That definitely depends on what it is and who your target audience is. I would say you can be quite technically proficient in Windows without being very familiar with the command line because a) the Windows command line sucks (even Powershell is kind of awful), and b) there are so many great GUI tools available, you almost never need to resort to the command line.
So yeah, just depends where you want to draw the line and what it is that you're making.
Depends on the windows user. But I dunno why you wouldn't offer it for Windows. You kind of have to go out of your way these days to make supporting Windows difficult, e.g. using OCaml or Perl or Bash or something.
I've never seen a good answer to this question. Snapshot testing sucks. A 0.3% threshold can totally be too low for benign changes and too high to detect real bugs.
Manual testing is probably the best option if you can afford it, but it's time consuming and tedious.
I'm sure there are people working on AI for this. I wouldn't be too surprised if that's the best option but I haven't looked into any of that. Also you really want it to be deterministic and I'm not sure how you do that with AI easily.
This is cool. Back when I worked on Typescript the one type-aware lint you really needed was to prevent boolean coercion. I did get it working but the configuration effort required to get ESLint to have all the right plugins and settings was insane.
If you find yourself reaching for this feature it probably means your Bash script has reached the level of complexity where you should absolutely not be using Bash. Use a real programming language instead.
Indeed, but animating bulleted lists is like the most common thing people do in presentation. The fact that they didn't notice it... It's like if your compiler miscompiles printf.
Python is one of the worst offenders here. I don't think Python's poor behaviour should excuse Lua's.
But I can also see why Python is making breaking changes - a lot of Python is so bad it really makes sense to clean it up. I dunno if Lua is in that situation.
Anyway I think I would look to other languages like Go, Rust, Java, C++ which do a much better job. I don't think Go or Rust have any backwards incompatibilities (at least very very few) and C++ has a small number but they're for stuff that is truly ancient or almost completely unused. It's totally possible if you care about it.
Yes but that tracks issues of all severities and with all of GitHub's services of which there are a great many. Also "days since incident" is a terrible metric because it doesn't capture how long the incidents last.
For example the latest incident is that copilot had degraded performance with Fable due to an Anthropic issue. It only last 18 minutes, only affected part of a part of their service, and it wasn't even their fault!
That's very different to "all of GitHub is down for 7 hours".
So yes. I am not sure GitHub is worse.
Ah yeah looks like the latest 19.1 release from June.
But it also seems to suggest it's only a UI change. Is is possible to do stacked MRs across forks? Does it not still suffer from the flaw GitHub has (or had, hopefully) - you create one MR,
myfork:feature_0 -> upstream:master. That's fine, but then you want to create the second MR targeting the first MR,myfork:feature_1 -> ???:feature_0, only you can't.feature_0doesn't exist in the upstream and there's no point creating an MR targeting your own fork.I'm not sure it actually is. At best it is too early to tell.
I haven't used it yet but assuming they did it right, yes you can merge the PRs sequentially.
Do you mean GitHub? Last I checked Gitlab doesn't support stacked PRs.
Me too, but obviously there is a point at which I would say "this language isn't so great that I'm willing to tolerate these compile times".
Yes they do. I don't think it's totally unreasonable. Slow compile time is a big productivity drain. But it's not as bad as people often make out for Rust - in large part because compilation speed has at least doubled since Rust 1.0, but its reputation is still based on the 1.0 compile times.
And some specific projects do have substantially bad compile times. When your incremental compilation time is 20 seconds where in other languages it's instant... That's notably worse.
But I don't think it should be a deal breaker. C++ has dealt with similarly bad compile times for decades and people don't like it but it's never been enough for most of them to switch to another language.
What are you talking about? 500 applications is clearly way too many for them to be serious. You're basically spamming at that point.
500-600 applications!? Sounds like you are putting low effort into sending a lot of applications rather than high effort into a few.
Someone (Rust Foundation?) pay this man! Compilation speed is one of the few weaknesses of Rust and even though I think that in 95% of cases it's actually not that bad and people are just looking for an excuse to not use Rust, it would be great to remove that excuse. (And faster compilation is always nicer anyway!)
Vibe port the Zig compiler to Rust? 😄
Ah I see. That definitely depends on what it is and who your target audience is. I would say you can be quite technically proficient in Windows without being very familiar with the command line because a) the Windows command line sucks (even Powershell is kind of awful), and b) there are so many great GUI tools available, you almost never need to resort to the command line.
So yeah, just depends where you want to draw the line and what it is that you're making.
Excellent presentation skills! He's heard of the hero's tale.
Depends on the windows user. But I dunno why you wouldn't offer it for Windows. You kind of have to go out of your way these days to make supporting Windows difficult, e.g. using OCaml or Perl or Bash or something.
I've never seen a good answer to this question. Snapshot testing sucks. A 0.3% threshold can totally be too low for benign changes and too high to detect real bugs.
Manual testing is probably the best option if you can afford it, but it's time consuming and tedious.
I'm sure there are people working on AI for this. I wouldn't be too surprised if that's the best option but I haven't looked into any of that. Also you really want it to be deterministic and I'm not sure how you do that with AI easily.
I think your intent sounds reasonable. I expect other people have done this, they probably just didn't wrap it up in a nice crate.
Also no idea why I was downvoted. Maybe because I mentioned the forbidden word.
This is cool. Back when I worked on Typescript the one type-aware lint you really needed was to prevent boolean coercion. I did get it working but the configuration effort required to get ESLint to have all the right plugins and settings was insane.
If you find yourself reaching for this feature it probably means your Bash script has reached the level of complexity where you should absolutely not be using Bash. Use a real programming language instead.
Indeed, but animating bulleted lists is like the most common thing people do in presentation. The fact that they didn't notice it... It's like if your compiler miscompiles
printf.