Fellow Julia user. Quite excited about Mojo. Been following Chris from his MLIR days at Swift 4 TF and his course with Jeremy on fastai. I hope we can also derive some exciting learning from Mojo :)
As package developers we need to optimize our packages for 1.9. It's quite a task but I am excited what's ahead in Julia. Matlab(is not open-source, R is slow and not really a general purpose language, Python is great but same issue 2-lang problem...why should I implement CUDA in C++ or Numpy in C. I want to be able to modify lower back-end code but with Python it's not possible. Julia fixes all of these problems and I am quite happy I invested my time in Julia. Present/Future is bright :)
Thankfully my GPU programming is shadet related, thus I don't have to deal with all the compute issues, however a good decision of CUDA from early on was to have PTX.
GPGPU needs more languages that make it easier to do compute with feeling like doing Assembly.
Basically the productivity that can be understood by reading stuff about StarLisp and the connection machine.
but the whole point of using Julia is that you don't need C(relatively same speed). Why would you interface it a Scientific Computing library written in C. Also C doesn't really sound like a good language for Scientific Computing. People do SC in Python and which is why Julia i.e. to solve two language problems and mind boggling speeds like C with syntax like Python
C is an excellent language for scientific computing. A lot of low-level and high-level libraries for scientific computing are written in C. Toolchain support is excellent. It is maybe less good a putting some scripts together quickly.
what are some of these libraries that are written in C but don't have python bindings if I may ask. Genuine question the once I have seen have python binding and that's why they are super popular and widely used.
Did you mean to reply to me? Or perhaps another comment of mine? If not, I don't follow.
Edit:
It looks like abhimanyuaryan is blindly spamming suggestions to write tests in this thread (???). This is a case where I agree in principle but their comments are completely beside the point and not relevant to the context of the comment or the post.
sorry for confusion what just pointing to one of recommendations from the blog post that I thought you mind wanna re-consider to overcome "multiple dispatch correctness bugs" i.e. "I'd say that there is a huge combination of packages that can be used together providing the language with an enormous amount of possibilities. It is up to the programmer to verify the interaction before use and, preferably, add tests to one of the packages." Yuri's criticism of composability came from packages as Viral already mentioned
That cannot be stressed enough: no stock Android is a pain (at least if coming from there)
E.g. more or less bound to their camera app, my automatic sync with Google photos isn't working because they want me to use _their_ gallery. Only when I start Google's photo app does a sync start.
Repeating explicitly: that's preventing that pictures are automatically backuped to the cloud! -- too me, that's preventing the main selling point of paying a lot of money for a phone with a decent camera
And: why would I switch every service to the crappy Samsung equivalent?