This is lack of impulse response data, usually broken by motor control paradigms. I reread Cybernetic by Norbert Weiner recently and this is one of the fundamental insights he had. Once we go from Position/Velocity/Torque to encoder ticks, resolver ADCs, and PWM we will have proprioception as you expect. This also requires several orders of magnitude cycle time improvement and variable rate controllers.
It is great to see this getting more attention. One of the best routines I started was morning yoga. But it is cold here in Boston, and I have mild seasonal affect disorder. So I got some 250W IR heat lamps and a UV light therapy box to try to simulate sunlight on gloomy days while I do morning yoga. I usually also have some mild eye trouble and dryness in the winter (probably a mix of cycling in the cold, and being indoors). The eye and mood symptoms have pretty much disappeared since using the lights.
This article confuses modern with high end. The ultra high end of cycles is just like the ultra high end of auto mobiles. There are bespoke tools and techniques required for maintenance. The average bike sold today is probably easier to maintain that those of the past. Disc brakes don't come out of alignment as bad, aluminum frames don't rust, rims are far stronger, etc...
This is one of the benefits of a capable JIT for numerical computing. Even including compile time, the overall execution time is way lower. Chris Elrod is an AVX2/512 whisperer.
I think even since 2014 there have been many niche technical computing companies supporting development quite successfully. Bigger players definitely would help, but I think most of that at this time is more public/private research money for scientific computing. Hence Julia has many academic contributors (grad students and post docs a likely majority), many of which are now becoming professors and industry leaders.
The post 1.0 world in Julia has been spectacular for development stability. In the early days it was somewhat tiring trying to develop basic foundational libraries, and keep pace with language changes. 1.0 has stabilized things quite a bit, and the forthcoming LTS (sometime this year maybe) I think will really start to button up some of the major issues people have with package load times and installation.
Generative design is almost always in SDF form. Things like point clouds, images, and 3DNN also dovetail nicely. SIMP in topology optimization is a good example also. I believe alot of SDF applications are still held back by mesh extraction. There is no silver bullet that can handle adaptive methods, sharp features, and generate a manifold.
SDF and mesh extraction are one of my favorite areas of research. I think it is very important for additive manufacturing in particular. The value will be hybrid SDF and spline methods for complex and highly integrated applications such as fluid and heat transfer or compliant mechanisms.
Modeling a box or cylinder with SDF isn't the right application IMO. Optimized topology for a given PDE is.
That's pretty cool. I see you are using marching cubes. How are you handling sharp geometry (I'm assuming previews use a finite difference for normals)?
Also I see you are at formlabs. I'm sure you know of Matt Keeter's libfive :)
There are a lot of backend data science applications using Julia. I was involved in a 3D printing startup and we developed a path planner beginning with Julia 0.3. You generally have to precompile your dependencies into the base library, but once this is all containerized things run great (pretty much as fast as C++ in our case with a little bit of JIT overhead in the cornercases), and you just have to create some sort of API for the service. For backend, long-running, services it is a great language now. The client-side application/static compilation story is massively improving and is fortunately mostly possible outside of the core languages development. E.g. the infrastructure is there in the core language for static compilation, but the interfaces are still developing.
JIT overhead/startup time is still comparably large. There is https://github.com/JuliaLang/PackageCompiler.jl that helps reduce this overhead in user libraries. The base library precompiles quite a few methods already, so the performance deficit relative to C and Python on Julia 1.2 is half that quoted in the article, and unchanged by statically compiling.
Personally, I do a lot of computational geometry in Julia and I really don't care so much about these kinds of small overheads since actual computation time is the dominant factor. I imagine if Julia was designed for scripting in Unix environments this would be a bigger deal, but I think most people in the Julia community care more about how to manage several gigabytes of data in RAM/cache and run some analysis quickly, e.g. composable multithreading in 1.3.