You are right but I also kind of did mean it that way. I believe that Parasolid is at heart of Onshape, the true kernel. Then on top of that is a compatibility layer describing the set of low level operations available to featurescript. I'm sure that not everything in Parasolid is available to featurescript and perhaps there are some things added that are not in Parasolid. Featurescript also contains the selector/query logic for programatically picking geometry. Whether that comes from Parasolid I am not sure. I haven't worked with featurescript for a number of years now but when I did I was amazed. I managed to make an operation for taking any solid from the UI and generating customized interlocking ribbing. The idea was hollow surfboard design. It worked and I left it at that. Never built the surfboard!
However the downside with featurescript and I think a big mistake on their part was to use a custom language rather than python or javascript. Featurescript is almost javascript but with some syntax changes and magic DSL's. You are also forced to use the inbuilt editor which is horrible and if you have burned VIM keybinding into your nerve endings, going back to non modal editing is horrible.
Also the discovery of featurescript modules in the community has terrible UX. It's super weird that they have such a great system but finding useful extensions is horrible.
The fundamental tension between nouns and verbs and the attempts to unify them like events have made programming a long art form to study.
It's all use-case and priority-specific, and I think the more varied your experience and more tools you have in the tool belt, the better off you can be to bring the right solution to bear. Of course, then you think you have the right solution in mind (lets say using partitions in postgres for something) but you find the ORM your service is using doesn't support it, then what is "best" becomes not only problem-specific but also tool-specific. Finally, even if you have the best solution and your existing ecosystem supports it but the rest of the engineering staff you have is unfamiliar with it, it may again no longer be "best".
this ladder of problem-fit, ecosystem-fit, staffing-fit is something I have grappled with in my career.
LLMs are only so-so at any of the above (even when including the agent as "staff".)
It's really hard to get away from ssjs frameworks for front-end, so for my startup it's Axum + Seaorm for "the api" and a Svelte SSR "front end" / view layer.
I think rust programers are more likely to want flask/rack than Django/rails.
reply