> Here’s why we think that CRAP1 is a good anti-pattern to detect. Writing automated tests (e.g., using JUnit) for complex and convoluted code is particularly challenging, so crappy code usually comes with few, if any, automated tests.
This is so wrong.
The formula uses code coverage as a fundamental metric, when in reality, a lot of people write code "correct from construction", so coverage is not even applicable. Many times too, people only care the use cases they care about work perfectly.
There are also many other reasons code is not tested, not because it's complex, but because it's simple.
> If the code is simple, the tests aren't much extra work.
Disagree. Even if it isn't much work to write (which is debatable), it still carries costs: CI takes longer to run, and the tests have to be carried and maintained (and possibly updated if the code itself changes).
> High test coverage doesn't mean your code is good, but it at least reduces the rate at which you accidentally break stuff.
Sure, for the most part. But that doesn't mean "more test code" is always a good thing. Tests aren't free, even for simple code.
Exactly. But then text-to-CAD projects almost all have this over-reliance on the declarative nature of OpenSCAD.
Cynically it always feels to me like they are written by people who not only think end users shouldn't have to learn CAD principles, they themselves shouldn't have to either.
do you know the WASM bundle size of Python and CadQuery? OpenSCAD has a lot of cons in terms of concept and CAD approach, but there are things where it is good - it is embeddable and sandboxable and fast. It gets the job done in simple models and that is the reason why it is popular.
It reminds me a bit how everyone was bashing PHP because 'it is not a programming language' while wordpress ruled the world.
No, the comparison is not apt with PHP (which I use on the daily and have done for twenty years). It's a bit more like comparing CSS with a subset of JavaScript that can do the same tasks. OpenSCAD isn't, really, a proper CAD package. It's a CSG drawing library with a declarative syntax. It is like nested CSS for 3D things.
Code complexity and repetition balloons with part complexity. Your thing will not scale well because OpenSCAD does not scale well.
Small changes will lead to subtle flaws; changes will need to be respecified in minute detail because OpenSCAD doesn't support sketch constraints that would generate correct geometry, doesn't support edges and faces that can help make parametric designs flow.
OpenSCAD is fun for making small, trivial objects, it is a good way to learn the most basic CSG operations, and it really excels at 3D representations of mathematical formulae.
But it's entirely the wrong foundation for the more general CAD-replacement thing you are trying to do.
CadQuery is not at all as bad a foundation (I think it's quite neat, and I think it could work).
But IMO much of this article talks about "findings" that should have been obvious to you if you know enough about CAD to know what it is you are replacing.
If you are continuing in this non-bRep, fast calculation approach, have you looked at generating SDF instead?
Someone will have to explain the value proposition to me...
We have git.
jujutsu works with git.
git can do everything jujutsu can do (otherwise, jujutsu couldn't work with git).
Thus, jujutsu is a UX / new steering wheel.
ERSC is trying to be a GitHub competitor with what surplus value?
Don't get me wrong, GitHub has a slew of its own problems, but I have not seen any commentary on how ERSC addresses any of the downfalls GitHub has too. We're jumping from one frying pan into another, currently-cooler one?
What about SourceHut? Codeberg? They could offer the same steering wheels.
Edit: Thank you to everyone who replied. The enterprise/teams infrastructure angle makes sense.
We'll be saying more about this very soon, but the short version is this: we are not building a GitHub competitor in the way that SourceHut or Codeberg are. We are building infrastructure for enterprises, not a social coding site.
While jj works with git, it doesn't have to. jj has the ability to work with many backends. Git is the popular one in the open source world, but that doesn't mean that other ones are not possible. And that's the core tech we have built.
With the rise of agents, more and more companies are running into the limits of what Git can do. It was never designed for large monorepos, and so there are performance issues, but also features that it's missing, that are important once you start trying to scale things up to an entire organization. Companies like Meta and Google ran into these things well before the present moment, but you don't have to be a FAANG these days to be running into this sort of stuff.
We also understand that incremental adoption is really important, especially for something as fundamental as source control. So our tech also has a git ingress/egress that will work with the core functionality, but more advanced things that git simply can't do will end up requiring using a non-git protocol. jj is the bridge between those two worlds.
I hope that makes sense! We have been in psudeo-stealth for a while now, this is the start of us coming out of our shell a bit and actually talking about what we're doing.
All but one of my employers have used either Github or Gitlab, and at every one of them there were a litany of complaints about whichever one we were using. It's kind of surprising to me that someone might not immediately recognize that there's certainly potential there for something better suited to what companies are actually looking for. Obviously there's no guarantee of success, and maybe the problem is too hard to solve, but that's pretty much how any company starts out!
I think it’s partly about how many steps back you take. Take another step back and you might see a new option that will in ten years be added to your list of options lots of people use and have plenty of complaints about.
I’m not saying not to try or that there’s no value in turning the wheel once more. But I used to be excited about these kinds of things and now I’m not because I’ve seen the cycle a few times now.
Yeah, it's unrealistic to think that everyone will be happy and there will be no complaints, but the median view of most products I've used at workplaces has been close to neutral. The sentiment towards Github and Gitlab seems a lot more negative overall at everywhere I've worked relative to how much people like or don't like them for personal stuff, and at least to me that seems like a sign that there's still potential room for improvement in the enterprise offerings.
I’m very excited to see the great work ERSC has/will do. When thinking about where Git lags today, I’ve come up with three categories: UX features and custom data not natively understood by the Git CLI, a stock git-http-backend that doesn’t scale well to moderate monorepo size in server compute / storage, and a wire protocol that isn’t as flexible as it could be for special requests.
But there are so many hooks into the Git workflow today, and I’m struggling to find a “user story” that would not be met by custom Git tooling. UX could be added to Git objects à la Gerrit with custom CLIs, custom Gitoxide ODB and (eventually) ref storage backends can help the server scale, and things like promisor remotes and partial clones can keep things smaller on the client side.
I’m curious what ERSC is able to share publicly about where the scaling fails with the Git specification? Is it the wire format, or the relative speed of upstreaming new things to Git? Or is the side-channel approach for storing rich data in Git objects insufficient in some way?
P.S. I wrote a blog post[1] about this a bit ago. I’m sure I’m missing something. Since I wrote it, I’ve wondered if the lack of deferred conflicts in-tree would be a scaling limiter.
Yes, it's important to realize that git is multiple things: the on-disk repo format, the CLI, and the wire protocol. Each has their own challenges, just like any project, but they can be tackled independently. But at the end of the day, there just are fundamental limits to the way that git does things that make total sense in the context Linus developed git for, but just do not in other ones. Some of those are performance related, but some of those are things like how the kernel is an open source project, and so per-directory ACLs are something that git wouldn't ever bother supporting, but are valuable for companies. We'll be talking about these things in the future, so I'm just going to be hand-wavy about it right now. But we do think that git is a really great system that has served us all well for 20 years, but just like how git displaced systems before it due to significantly re-thinking the details, for some users, making meaningful improvements over git will also require a similar significant re-think. That's just the way of technological development.
As someone trying to compete in this space: will ERSC make the change/commit their unit of code review? It's one of the pet peeves I have with GitHub et al.
We plan on building everything as individual building blocks, that you can use or not use as you wish.
Initially we won't be offering our own CI directly, you'll bring your own. We use Buildkite internally, so we'll probably share that integration first, but fundamentally you can do whatever you'd like. We won't require you to use whatever first-party offering we end up with.
It's not so much that we will prevent individuals from using the product, we are just focusing feature development on the needs of companies and teams. Startups are hard, and you have to focus, and so that's where we are focusing first.
Will you prevent individuals from using the product by requiring a sales call for onboarding? (aka: decisions that have nothing to do with individuals at all, but merely rule them out by intrinsically not being something they can achieve)
As we initially roll out we will be doing that, yes. The reason is that our initial offering is enterprise shaped, and so won't have a self-service onboarding. Eventually we will not require the white gloves, but you have to start somewhere.
I think it's unlikely that individuals will need their product, unless you happen to have a 100 million line monorepo. (At least based on what it sounds like they're targeting.)
Normal Git/JJ is fine for most people, and most open source projects. It's just when you get to the scale of commercial software companies (100+ employees) you run into the classic monorepo/submodule problem.
Monorepos are currently the best solution - they make testing tractable, you can do cross-project changes, Git's support for them isn't buggy as hell. But they have obvious downsides - performance is the big one, but also integration with open source projects, permission control, etc.
So there's this big problem space that really only matters to companies where as far as I know there are currently no good open source or even commercial solutions. The only people that have (maybe) solved it are the mega-corps like Facebook and Google who have made their own private solutions. I don't know exactly what ERSC are going to offer but it's surely going to be in that space and also probably not going to be super relevant to private individuals.
This sounds glib, but I mean it sincerely: we will make money by charging money to use the product. A free tier on source control hosting is just not economically tenable nowadays. I have built a career on open source, and so that bums me out, but we have a business to run.
Our moat is that we are not trying to take git and scale it up, we are building a more scalable system from the beginning. And we will have features that nobody else has because of it.
It's always the case that businesses have competitors, that's just capitalism. We're not worried about that.
If the worst thing you can say about a git hosting provider is that the performance of their blog is worse than the performance of their git servers, I think they're probably doing an okay job.
While this is true, we do care about performance tremendously, and the animation not having good performance cuts against that, so I think it's a very fair criticism. Paying attention to details matters.
That's reasonable. I mostly just found the framing to be unfair rather than the criticism itself; it feels kind of disingenuous to try to draw a connection between performance of git and performance of a webpage IMO
I'd argue that you invented some sort of link between "performance of git" and "performance of websites" that is not at all a premise I accept either, so it's not that unreasonable for me to point out that I think it's silly.
Thanks, I'm a Windows user and use Chrome myself, and on my machine it works great, but it's a pretty beefy box. I mentioned this downthread to someone else, but I've filed a bug internally and we'll make sure that it's better optimized. Thank you for the report, it's truly helpful.
> git can do everything jujutsu can do (otherwise, jujutsu couldn't work with git).
FWIW I think it's a bit more nuanced than that. As a trivial counter example Git does not currently have a way to store conflicts inside commits[1], which is one of our major features. The way this works is that we basically store the sides of the conflicting trees in the Git object database (and another conflicted tree pointing to all of them), but the actual data structure representing the conflict as Jujutsu understands it is stored elsewhere. Git will be very confused looking at a conflicted tree object created by Jujutsu -- it shouldn't break but it doesn't understand what it's seeing. So, if a object can be stored in the database that is correct but Git can't really "view" it properly, does "git" (or capital-G Git) support it or not? Depends on who you ask, I guess. The storage layout being intimately tied to Git "as a thing", part of its identity, is one of the most interesting properties it has.
The way I see it is this. Jujutsu uses the Git storage layout on disk. But basically all of the algorithms and UX between the two are completely different. That is where most of the real differences are. To the extent we integrate with lots of fiddly Git details (eg tracking branches, remote integration etc) so that `git` commands work -- that's more necessity to make the UX nice. We could absolutely use the on disk Git format but in a way that was inscrutible to the `git` CLI, it just obviously would not be very nice.
As a disclosure I work at ERSC but I am also one of the maintainers of Jujutsu; this post is written with my maintainer hat on.
[1] At Git Merge last year, Elijah Newren prototyped and demo'd a really early and cool example of storing first class conflicts in Git, based on his work on ort-merge. So this might not be true forever :)
> As a trivial counter example Git does not currently have a way to store conflicts inside commits[1], which is one of our major features.
Yes, I like how jj does it!
Did a big `git rebase -i` yesterday and I felt stressed up, almost a bit angry, when there were some conflicts and I wasn't sure if I'd resolve all of them before it was time to leave, and work more later from a different laptop.
But with jj, no stress: I can just check in the conflicts, and later, on the other laptop: check out the conflicts and continue resolving.
(I just wish there was Git submodule support :- ))
"Can do" and "can do easily" or "can do with minimal friction" aren't the same.
I use JJ locally and for those that call it a "porcelain" or a "git UI" are missing a lot. Sure you can use it that way, but what I've found is that it facilitates (and perhaps encourages) a pretty different workflow than I'd use with just plain Git. I could pull off what I do in JJ in just plain Git... but it wouldn't at all feel natural and you can really see this when you start using a JJ driven repository with Git tools (including just the Git command line tools).
Personally, and as a mere version control user, I prefer the JJ model of version control much more than Git's. The mechanics of the UI was very easy to get under my fingers (the essentials in about a day), but getting the ideas and really getting an understanding/appreciation for the conceptual differences and their ramifications on workflow took a month or two of regular working and trying things. For me, it was worth the effort.
I might be mistaken, but I always figured the end goal for jujitsu was to use its own backend. Supporting git-colocation seems like a compatibility case to bring users over.
If I had to guess, then I would say ERSC is trying to build a `jj` forge based on this new hire and that would be amazing imo.
Absolutely everything in this industry is just a façade over the underlying ability to pass current between the source and the drain of transistors. "Just a better way to do ______" is the entire software sector.
If you ask "apart from better UX, what's the advantage of this thing?", you might as well ask "why would I buy an iPhone when my Nokia can do more things?".
While this is true and I agree with you, to be clear we do way more than just a nice UX. There is a lot of deep technical work going on here. If anything the UX isn’t the selling point, we are an infrastructure company at heart.
I don't know how experienced you are with jj, but one thing I can say for sure is jj offers significant ux improvements over git and they plan to have a backend eventually. we might see the first implementation from ersc. and from their website I see they are already taking things like agents into account from day one. so we might be in the verge of getting something that scales better with modern day workload?
I hope when people read this though they understand this is a communication style; they're clearly trying to strongly discourage people from thinking they are suddenly protected. Effective? Maybe at one time, where "macho dev energy" was a thing. Today, not so much. You can tell they mean well because the intro sentence is actually pretty cheeky!
and
> Here’s why we think that CRAP1 is a good anti-pattern to detect. Writing automated tests (e.g., using JUnit) for complex and convoluted code is particularly challenging, so crappy code usually comes with few, if any, automated tests.
This is so wrong.
The formula uses code coverage as a fundamental metric, when in reality, a lot of people write code "correct from construction", so coverage is not even applicable. Many times too, people only care the use cases they care about work perfectly.
There are also many other reasons code is not tested, not because it's complex, but because it's simple.
reply