In case you're not just being sarcastic, stuff like Ivar.
364 karma · joined May 4, 2017
Sincerely, I wish them the best of luck!
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 :)
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?
https://build123d.readthedocs.io/en/latest/tutorial_constrai...
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!
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.
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.
[1] https://devblogs.microsoft.com/dotnet/dotnet-sts-releases-su...
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?
Discussed three years ago: https://news.ycombinator.com/item?id=35561203
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.
https://www.paulgraham.com/identity.html
Edit: if the connection isn't clear, I mean the aspect of it being difficult to argue rationally about opinions you've made part of your identity, since changing the opinion would be difficult.
This doesn't address the parent comment's concern:
> IIRC splitters only accept a single filter, and so you'd need many of them at each junction
I haven't played Factorio in years, but IIRC the splitter maintains state (direction for next item) per item type, so I guess it can be set up to filter as many types as you like? I remember you had to prime it for the desired item type, but I forgot the specifics of how it does the rest of the filtering "logic".
For a (much more) elaborate expansion on this, see the book Drive by Daniel H. Pink.
One critical thing that I couldn't find info about is what reliability to expect from the persistent storage for a Durable Object. Is it more or less a write to a single disk without redundancy? If there's redundancy, to what degree? Essentially, how much would you need to build on your own in terms of replication for a production scenario if using Durable Objects as primary storage?
I get that they can use other, separate storage if necessary, but either way it seems like an important consideration when designing a system on top of them.