@joel If you need to test the grammar, then use Lightshow. https://github-lightshow.herokuapp.com/\|https://github-lightshow.herokuapp.com/

The conventional wisdom is to “use the best tool for the job”, so while I use Racket for just about everything these days, I thought Julia might be the right tool for the job for more math/stats-intensive programming. However, that puts me right in the middle of the problem Julia was designed to solve i.e. the “two language problem”, except instead of Python + C/C++, it’s Racket + Julia. Julia’s a decent language, but every time I code something in it, I miss Racket. I haven’t warmed to Typed Racket yet, but maybe I should give it a go to get the speedup for the math library.

Why would Typed Racket be a performance increase? My understanding (maybe wrong) is that it’s no different than adding type annotations to Python code: completely optional and is just there for safety. It’s not like the underlying bytecode or interpreter is any different or generating better code. It still performs all the runtime type checking, etc. It just gives you errors are compile time instead of runtime, right?

“Performance Warning: Indexing the elements of arrays created in untyped Racket is currently 25–50 times slower than doing the same in Typed Racket, due to the overhead of checking higher-order contracts. We are working on it.” from https://docs.racket-lang.org/math/array.html

I’m guessing there are other things possible also, such as avoiding boxing, and being able to compile down to unsafe versions.

It’s specific a problem with how arrays are represented.

I’m guessing, but I don’t think that has anything to do w/ Typed Racket specifically. As opposed to Typed Racket is able to generate Racket code that “does something better”.

For example, a Typed Racket array of flonums may be able to expand to using flvector instead of vector, which results in faster performance. But there’s nothing preventing you from just using flvectors in your generic Racket code either.

I have nothing against typed racket, and if it helps you in N ways absolutely go for it. But, it’s quite possible that with a little bit of specifics (and maybe a package like https://pkgs.racket-lang.org/package/sci wrapping CBLAS or similar), you might be just fine.

In the end, though, I highly doubt Racket is going to compete with Julia if your dataset is large enough. Julia has a JIT and lots of built-in parallel computing optimizations that Racket does not. But you might get “good enough” in Racket.

The comment is old - so it would be interesting to know whether the 25–50 factor is holds.

It would be interesting. That comment has been discouraging :)

It would also be nice to be able to turn off contracts for a production run, and only use them for testing.

For other parts of the math library, I expect the boundary crossing to have almost no slowdown.

Part of my problem is I have grandiose ideas in my head about how much math/stats I need, but in reality, it’s probably not that much :) I coded https://lojic.com/covid.html in Julia because I thought I was going to add a bunch of fancy analysis, but I never got around to that, so it would’ve been much easier to have done that in Racket. There’s always quite a bit of non-math/stats code, such as I/O, cleaning up data, etc., so maybe I should experiment with the interface between Racket & Julia, and only use the latter when it’s actually necessary :)

As someone who has periodically poked their head into the Julia world - but never stepped through the door - I’m curious why you think it would have been “much easier” in Racket. Just familiarity or were there things specific to Julia that made it very frustrating to work with (e.g., debug cycle)?

Good question. Much of it is probably familiarity - Racket matches up with the way I think much better. Racket also provides a better means for abstraction IMO. I also have a collection of utility functions I can make use of. In fact, that’s a huge benefit of sticking with one language. I’m probably easily influenced by code aesthetics, and I find Racket code really beautiful! Also, the “time to first plot” problem is pretty annoying with Julia at the moment, so despite Julia’s potential for super speed, in this case, it doesn’t materialize. Lots of loops involved, and looping is nicer in Racket :)

Matthias usually replies to this “do you remove your seat belt after your lessons?” (or something like that), but I don’t buy it. In most of cases, what I want is for my programs to go fast while being correct, and if it crashes (actually not correct), restart it with seat belts and see why it crashes and correct it. Often times our current seat belts are so heavy that it makes the whole point moot (and I’ll have to use another language).

I will say that Julia is high on my list of non-Racket languages though.

I enjoyed my time with OCaml and Haskell, and I appreciate the benefits of static typing, but I think I appreciate not being restricted even more :) I haven’t closed the door on Typed Racket, but over the decades, it seems I may just be a dynamic typing guy (at least with current type systems).

Oh, one more thing, most of what I do ends up on the web, and web programming with Racket is very enjoyable. I didn’t feel like digging into Julia web programming, so the link above is simply a single, static HTML file that I generate. It would be nicer to have it be an actual interactive web app.

Racket’s module system is much nicer also - less encapsulation w/ Julia.

Ok, last one :) Schemes nail lexical scoping! Julia, like most non-Schemes, has some quirky scoping issues.

Thanks for the breakdown :slightly_smiling_face:. Usually my “poke” into Julia stops when I go to do something like “parse JSON” and discover there are 5 different JSON parser libraries, none appear to be “blessed”, etc.

That appears to be a common pattern with many of the “common” libraries there

There are some pros. Speed is a stated priority, and Julia’s design helps in this regard. Infix can be handy for imperative, math/stats code. Macros aren’t bad for a non-Scheme/Racket. I think Julia has a slight chance of gaining on Python and/or R, but time will tell.

The counterpart problem in Racket is that when there’s a bug in a “blessed” library, it could take time to fix and release.

R is just a mess. I have no idea how people can work with that. (Note: I have to)

Critical mass of code :)

I kind of miss having the flexible attitude I had decades ago, where I’d just pick up whatever language I needed to at the time. Now I’m old and opinionated, and I don’t have the patience to use a language I don’t love :)

+1. Combine that with a feeling of “I just want to be productive, which means any tools I use have to just work.”