Lup Yuen Lee 李立源 @lupyuen@qoto.org

@morenonatural @lupyuen I think that we agree that inheritance is bad and not flexible. Multiple dispatch is one solution, but Rust's traits are another solution which, at least in comparison to Julia's multiple dispatch, seems to be much more robust to me.

I hope that it is clear that I am not against Julia. Quite the opposite, I teach and push Julia and will continue to do so. I just find some of its promises misleading and for some cases, Rust is a much better fit.

@morenonatural @lupyuen You are right about "Julia written in Julia" being powerful! I did mention it in the post and I find it much better than the approach of Python for example with its C code. Julia makes reading and contributing to code much easier than Python.

Thanks for sharing the talk about multiple dispatch. I am already familiar with it and yes, multiple dispatch is fascinating, but it has its disadvantages at least in Julia because of the missing interfaces as mentioned in the post.

@morenonatural @lupyuen About the first point with linters or static analyzers of a dynamically typed language and why they will never reach the correctness and reliability of Rust: I did add an appendix for JET.jl which is a static analysis tool for Julia. It is an example of what I mean:

https://mo8it.com/blog/rust-vs-julia/#jet-jl

If you mean the borrow checker with the "questionable model for memory handling", then please question it. If you have any doubts about it, please share it with the community :D

@morenonatural

My bias; towards statically typed languages.

There are arguments on both sides, and the good thing is we don't have to unite behind one language for everything.

Rust is trying to solve a problem that humans can't handle; understanding what could possibly go wrong in multi-threaded applications. I don't think it is doing a great job at that (compared to Ponylang), but it is a lot better than C++.

@lupyuen

@lupyuen "Tools like linters for dynamically typed languages will never reach the power and correctness of a static analysis built on a well typed language"

while the author has best intentions, it's very noticeable that they're trying to fit a square in the triangle hole with compilation and static analysis

this is (and has been for a long time) a very long, mostly religious and skewed to my taste, endless discussion. My belief is that you can achieve same code maintenance (if there would be a single way to measure it) with or without a static compiler

Julia is designed at the core to be hackable in the same language without having to pay either runtime performance or learning a separate language (with a now questionable model for memory handling)

Maybe we can say it's an outdated statement after all these years, but it does keep its promise. You can handle fixes/patches/forks for 3rd party code in and with the same setup for your original project. The interpreter has plenty of tools for this and it's properly documented

There are other details (like how the dispatch system is great for writing algorithms rather than implementations, see https://invidious.projectsegfau.lt/watch?v=kc9HwsxE1OY&local=true ), although I'm not good at writing long replies or blog posts... I'm open to discussion over tea

@lupyuen ☝🏽#julialang #julia

@lupyuen interesting point about AI cannibalism relevant to #SAGAFTRA and #wga...

"Content cannibalization is more of a risk to the future of AI itself; something that threatens to ruin the functionality of tools such as ChatGPT, which depend upon original human-made materials in order to learn and generate content."

https://www.techradar.com/computing/artificial-intelligence/chatgpt-use-declines-as-users-complain-about-dumber-answers-and-the-reason-might-be-ais-biggest-threat-for-the-future