Skip to content

Comment on My Experiences with Julia

Comments

It's interesting how hard this nut is to crack. I have hit all the same types of problems (R is obscene as a programming language, Python too slow and lacks multicore, C is too low level etc etc). I've ended up using Groovy (JVM) for a lot of my scientific work because it is the "least worst" language - dynamic when you want it to be, static when you want it to be, decent if not stellar set of scientific libraries and performant enough (mostly as fast as Java). I have hopes for Nim but it's still not quite there.

But why isn't there something else? Can we really never have our cake and eat it too in this domain?

I'm assuming "this domain" refers to scientific computing. My theory is that the typical scientist crunching data is just proficient enough to write specialized code for themselves but doesn't have time to develop a scalable, "professional" solution. Very large organizations tend to have capable internal systems but they may not make it into public view or they are too specific to their niche.

On the other hand you have premade, proprietary packages that can become quite popular (Matlab, JMP, etc.) for non-programmers, which dilutes the user base.

That leaves us with things like "R" (horrible, like you say) or Julia (eternally promising) or Python (stitch together low-level Fortran and C code). The latter solution is winning, it seems.

Well, there is https://scilua.org/ I'm not a numerics guy, so I've no idea if this fits. But I like LuaJIT and use it as my "scriptable C runtime".

I'm kinda the same, but chose Kotlin over Groovy. Especially with IDE hotkeys and smart refactoring a, I'm as fast as in Python Jupyter, if not faster.

I like Kotlin and would probably use it but I just couldn't get over the lack of list / map literals. Seems like they never could figure out how to get them to mesh with the static typing. It's just too useful to be able to write nested structures cleanly and simply inline for ad hoc / exploratory analysis.

I use listOf(), setOf() and mapOf(). Longer than literals, right, but not by much.

And for exploratory .filter{} and .map{} are much better than Python's awkward map(lambda x: ...) and filter(lambda x: ...).

yes, they are fine at top level, but they fall apart when you try to nest them unfortunately (lists of maps of lists etc ... ). In groovy / javascript / python these just look completely natural.

That's interesting. I had always considered Groovy as a good language for such tasks. Because fast JVM and many JVM-native libs to work with big data. And also because Groovy is perfect for building a Domain Specific Language.

If you're okay with JVM, I'm a big fan of Clojure. There are some great scientific libraries in the SciCloj community and you get the untyped but performant characteristics you're looking for.

Didn’t hear about much usage of Groovy outside gradle tasks, I am happy it is used for elsewhere as well!

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.