It looks really interesting from a technical standpoint. I really hope they manage to make meaningful progress. At the same time, it looks really challenging; not just because of technical implementation but collaboration. It's a pretty involved plan to begin with, and they are competing with behemoths who don't mind getting many bits of information about a user (with simpler implementations). Who will help Mozilla succeed here?
I got a second hand Prusa Mk3s about a year ago as my first printer, around 300 € perhaps. I'm still enjoying it a lot, even though I'm now eyeing one of their upcoming (more expensive) models.
I think it depends mostly on how you expect to use it. There may be alternatives that give you perfect prints with minimal fuzz. But for me it was great to have a machine I dare play around with. Like getting a tractor before a race car :)
Do you have an image of the reversing portion? Any examples of pitfalls?
On the face of it, it seems like you'd define paths and sweep profiles for the material to remove. Is the difficulty in defining the path of the reversing portion, where it's not a helix?
As the sibling comment mentioned, the classic problem of chamfer/fillet. Inconvenient in OpenSCAD, trivial in build123d.
There are various features I've missed: polylines with rounded corners, extruding along a path, and more I can't recall.
As you mention: code organization. I didn't have the need early on, but over time I often wanted to do add custom things, for example my own hack of an implementation for extruding along a path. And passing data around is just painful and ugly... since you can't read any of your input shapes, you have to pass around all data explicitly -- alongside or instead of shapes -- and then only actually render them in the latest stage. Generally I found it hard to make reusable code, and generally it has to make many assumptions about the calling code.
The OpenSCAD editor is one big IDE, and it's not a great one. My workflow was to keep VSCodium on one side and OpenSCAD on the other, just to use a better editor. I actually thought to myself that a good project direction would be to make it more modular and focus on the unique parts rather than the IDE. And that's indeed how build123d does it: primary repo only handles the rendering, and then suggest compatible viewers, with one shipped as a VS Code extension being the primary suggestion.
Speaking of workflow, a huge difference is local coordinate systems: lacked in OpenSCAD and encouraged in build123d. It fits my brain really well. I just made a shape, now I want to make some holes in it. Previously I've often had to think about what global coordinates to put some volume, but now I'll just select that face and work with those local 2D coordinates.
And another workflow annoyance before is when I'm designing something to be printed in separate parts. First, meticulously fit things together in the global coordinate system so that I can see them in the assembled state. Then to allow printing, also conditionally move all parts to manually specified other coordinates. With build123d one can define the parts separately, place joints in desired locations, and have them automatically snap together for the assembled view. It looks useful for integrating third-party parts as well.
Minor thing, but I'm always slightly annoyed by the fact that a rectangle is called a square and a slab/box called a cube in OpenSCAD...
Oh, and it's often useful to use polar coordinates. More passing around custom data and manually calling your custom conversion function whenever passing to OpenSCAD. build123d has first-party suitable objects for it.
OpenSCAD development seems fairly dormant as well. Latest stable release was five (!) years ago, but by reading around you see that you're supposed to use the nightly version because it's superior. Not very friendly for newcomers. By contrast, build123d seems very active.
I should stop now, because this already got pretty long. As you can see, I had some bottled up though -- thanks for letting me vent!
Despite being aware of its existence, I stuck with OpenSCAD out of habit. Only last week did I read through the documentation, and feel strongly that I've been missing out… it seems to solve all of my gripes with OpenSCAD. I'm excited to try it out!
This is only the language for describing the volumes. That's not heavy, rather the importance is that you can express the ideas you want. The heavy lifting of rendering and computing how volumes interact etc is already implemented in native code.
That sounds like a nice improvement, just like many other aspects of jj!
Tools should adapt to us and not the other way around, but if you are stuck with git, there's a slightly different workflow that supports your use case: detached head. Whenever I check out branches that I don't intend on committing to directly, I checkout e.g. origin/main. This can be checked out in many worktrees. I actually find it more ergonomic and did this before using worktrees: there are no extra steps in keeping a local main pointer up to date.
Fair enough. We use Dapper for a handful of performance-critical queries. But I wouldn't want to use it for the 99% where EF works well. Just like I wouldn't want to hand-roll assembly more than where it's really needed.
And it's not just about performance. LINQ plays well with the same static analysis tools as the rest of C#. You know, type checking, refactoring & co.
Especially with the recent extension of STS release support from 18 to 24 months [1]. Previously, upgrading from an LTS version to the next major (STS) version meant the support window decreased by half a year, while now it would stay the same.
Are you referring to the change tracker? FYI you can have it skip tracking as the default (or per query), but when you actually want to make changes you better opt in with `.AsTracking()`.
Anyway, I've used EF at work for about a decade and I'm happy with it. I surely have blind spots since I haven't used other ORMs in that time, but some things I like are:
- Convenient definition of schema.
- Nice handling of migrations.
- LINQ integration
- Decent and improving support for interceptors, type converters and other things to tailor it to our use cases.
What ORM do you prefer, and how does it differ by being stateless? How does saving look like, for example?
Me too! It was funny how little love it got given how well it worked.
The only issues I came across were artificial blocks. Some programs would check the OS version and give an error just because. Even the MSN Messenger (also by Microsoft) refused to install by default; I had to patch the msi somehow to install it anyway. And then it ran without issues, once installed.
Sincerely, I wish them the best of luck!