22 ms·

> whiffed a few major decisions early on Anything particular in mind?

• patrick451 2y ago
  The always on jit was a big mistep (IMO, the opt-in torchscript model is much better). I tried a julia a few times and it was just too slow to be usable for anything remotely exploratory. Every year or so, I'd read "TTFP has been improved", so I'd try again and it was still slow as mollasas in siberia. I suspect a lot of people had that experience and will be hard pressed to give julia a real shot at this point, even it it does/has fix the problem.
• catgary 2y ago
  In general, I’d say there’s too much superficial flexibility but not enough control. - I wrote this elsewhere: I find their approach to memory management/mutable arrays really hits the worst of both worlds (manual memory management and garbage collection). You end up trying to preallocate memory but don’t actually have control over memory allocations. I find the dynamic type system exacerbates this. - It’s a very big language, even in the IR. So proper program transforms like mapping functions or autograd are quite difficult to implement. - Static compilation is really hard, which makes it a non-starter for a lot of domains where it could have made inroads (robotics, games, etc).
  • xgdgsc 2y ago
    Static compilation is already available in a commercial product: https://discourse.julialang.org/t/syslabcc-suzhou-tongyuans-proprietary-julia-aot-compiler-is-now-available-for-free-use-personal-educational-license-only/114633 https://discourse.julialang.org/t/syslabcc-suzhou-tongyuans-... . https://github.com/Suzhou-Tongyuan/syslab-deploy https://github.com/Suzhou-Tongyuan/syslab-deploy . EDIT: or 2 products: https://news.ycombinator.com/item?id=42962548 https://news.ycombinator.com/item?id=42962548