So nobody knew about Groovy being the Python for the JVM ecosystem? I believe Groovy has a lot of potential in AI and data science.

@@silverdemon101why not kotlin? For that matter any jvm language designed like a scripting language

Groovy has already existed since 2004 way longer than Kotlin and has improved quite a lot in terms of tooling. Go look at Paul King's presentation and you'll understand more.

Do you have any documentation that i can refer to learn ai with java

Thank you, Rick! 🧡💙

Valhalla is taking a long time, but it's also a deeply invasive change and I think we can agree that siphoning some of the effort into more short-term gains (~> Amber) is a good compromise. Panama finalized the FFM API (in JDK 22) and the vector API is ready for use in production if it's important enough for you that you're willing to rewrite some code. You'Re right on Babylon, but it's just a month old, so... Honestly, I don't think Python is gathering momentum. I think it _has_ momentum but looking over the list of PEPs, I don't see anything groundbreaking (then again, I don't know the ecosystem, so I may very well be missing something) - what's there that compares to the efforts made in Valhalla, Panama, _or_ Babylon, let alone all of OpenJDK combined?

@@nipafx The strength of Python is interoperability and interactive development. Calling a C DLL from Java is still a miserable experience and jShell is a joke compared to the Python REPL. For academics, AI researchers, and data scientists, it's a lot easier to develop AI models in Python and build up from there. The deployment in production than follows that: why rewrite something that already works? Java is more focused on top down design/development, which is not very suited to experimental research. Once your classes and hierarchies are finalised, it's difficult to change them. The dynamic nature of Python is so much better for this. To be clear: Java is a very good language. But I think it's too deep into the "Enterprise development" model to breach into experimental stuff. It's like the early days of the web: Perl, Ruby, Python, PHP were the kings. Only when the field consolidated a bit, Java and the others gained a substantial foothold. EDIT: One final remark: Valhalla and Panama are the 2 feature sets that would have allowed me to use Java for our new 6G testbed. Now it's all C++ and Python, because those 2 JEPs are late.

@@nipafx Python is slow and a Valhalla is not even on their radar. But, even in college they today teach Numpy and many use PyTorch and other libraries that don't exist for Java. Startups that do ML/AI today use Python from the get go, including for the training portion, and they don't need to wait for projects that are not yet available or maybe never will.

I hope the video delivers. 😊

You're right - see 4:51.

what's wrong with writing like this?

@@badpotato It's a lot harder to read

I don't think Amber is the right project for that - it is focused on improving the language to "right-size ceremony", not to provide a better library, let alone JavaFX. I also think it makes sense to focus on where Java is strongest in the AI space and that's definitely AI feature/product development, not model development. Maybe some resources free up in the future and issues like visualization get tackled, but I don't think that'll happen any time soon.

ML/AI and data science in general is very heavy on arithmetic and doing that with method calls instead of operators is no fun.

@farkarf Do you have experience working on linear algebra using Java versus any other language with operator overloading? I for one have moved away from Java for this reason. My code with operator overloading looks close to what I write on paper, making it less obfuscated in Python.

@@SourabhBhat yes, (linear algebra in java). Our team then transitioned to Scala. I think operator overloading is fine for DSLs and such, but more often than not, it obfuscates logic (especially if your team is in the habit of wanton operator overload). Once a language supports a feature, it gets hard to tell others to eschew it. That was circa 2013. Java hardly had any functional support.. what made Scala so attractive to us back then. Re operator overloading and verbosity: most of the interesting stuff happens at higher levels of abstraction.. matrix operations for eg don't need operator representations. Just because we use super-script T to write the transpose of a matrix doesn't mean it should be represented that way in code, imo. If you ask me, Python is convenient, but also, you keep having to look at the mess under its hood, cuz it super obfuscated.

There's a long way from "a feature has downsides under certain circumstances" to "there'll be a feature flag", so I wouldn't hold my breath on that one. Then again, it's not _just_ beginners that struggle with it, so maybe something will get done. Personally, I think the better solution would be variadic generics (at least for exception types), so functional APIs can work better with checked exceptions.

There are also great benefits to checked exceptions, especially when security and stability is important.

You forgot two "maybe"s there. 😉There were some Ask the Architect sessions at past conferences (somewhere in this list: kzfaq.info/sun/PL_-IO8LOLuNrVRv3eEVGk8LhH8PiEirnp ) where Brian mentioned that once value types and universal generics are done, this could be looked into. But that's very speculative and AFAIK not written down anywhere.

@@nipafx no no Brian can't talk about ideas without writing them down! 😛 (NB: the link doesn't seem to work for me, it just takes me to a generic KZfaq page)

@@quintesse 😂 (KZfaq included the closing parentheses in the URL. Fixed now.)

Come on, that's not fair. Babylon is just a year old and Panama already delivered FFM and (basically) the vector API. But, yeah, Valhalla is taking its time.

@@nipafx Valhalla was a bit too ambitious, I guess.

@@VuLinhAssassin It's definitely ambitious, but I don't think _too_ ambitious. Work on it is progressing and I'm convinced we'll see results eventually.

Java can return multiple return values in records.

An SQL database is a separate service that is set up for remote communication - an AI engine isn't. You can build such a service around it but why go through the trouble if you don't have to? With AI engines in Java you get better observability and debugging, seamless integration, uniform resource management, etc.

Why wouldnt Java be good for SQL db’s? Wierdest take i’ve heard.