I inquired and their price for any economic usage is $2400 per year. They left that out. This is not a suitable tool for ordinary developers.

Source: https://github.com/exaloop/codon

Docs: https://docs.exaloop.io/codon/

notice the "business source" license is limited to non-production use.

I don't even mind (although it bothers me that python doesn't have pipes ala R, or any sort of nice lambda syntax) but I wonder how much work has been put to take python-like dialect and hammer it over and over into being fast

NumPy giving a whole other set of verbs you have to memorize to just wrap around C, then JAX+etc which take that subset and make it faster, then the pypy+pyston to rewrite big parts, with numba to do individual functions if you really want for loops. I know it's an over simplification and it's all pretty amazing work, but it's exhausting to me how many companies and people have put work into taking a fast language and trying to make subsets fast

Yeah. Python is a great language for glue. Glue does not need to be fast, it's hopefully small in scope, and it has (hopefully) one or few jobs. Python can be a great frontend to faster C code, but sooner or later it starts being the bottleneck where it matters. These pseudo-Python compiler/interpreters are... cool, I guess, and might even solve that problem in some cases. The issue is half of them target the syntax of Python, rather than integrating with the runtime (really, CPython). The problem, I think, is that we have huge applications implemented from top to bottom in Python where the bottleneck is... everywhere and there is no good solution that isn't somehow writing a faster Python implementation (Pypy will get you far) or rewriting it all in a different language.

re "pipes" (or, chain operations) in Python, here's my personal approach that I use:

https://sr.ht/~tpapastylianou/chain-ops-python/

It's clean, works well, it's debuggable ... having a special operator might have been nice syntactic sugar, but isnt really necessary.

From the abstract:

  Here, we present Codon, a domain-extensible compiler and DSL framework for high-performance DSLs with Python’s syntax and semantics. Codon builds on previous work on ahead-of-time type checking and compilation of Python programs and leverages a novel intermediate representation to easily incorporate domain-specific optimizations and analyses.

Something about the "python syntax and semantics" claim seemed familiar. Lots of discussion here https://news.ycombinator.com/item?id=33908576.

Wasn't python back then, probably isn't now. Just something that looks similar.

Hard to trust anyone even wanting Python semantics, if I can be slightly elitist for a second.

Using language with 3rd order logic support lot easier than implementing 3rd order logic in langauge that does not natively support 3rd order logic.

Lot less haskell to switch between different levels of order logics.

Just depends on what/how using python (or any other language) for.

So, prefer unicorn semantics?[0]

[0] : https://en.wikipedia.org/wiki/Unicon_(programming_language)

I like Scheme's semantics the most of the "popular" languages. What makes Unicon notable? Nothing on the wiki page linked stands out.

Python does crazy things with scoping and is too keen on implementing modules in C, but could be worse.

Unicorn is the successor to Icon[0]. Unicorn language home page[1]

Paradigm is object oriented goal directed general purpose programming language. Technique revolves around the use of co-routines/generators.[2][3]

Short points per -- python semantics --:

More formal/mature semantics than python, less parentheses/more robust than ARC[4]

Language design has been around for multiple decades. Icon/Unicorn language features seem less 'ground breaking' today compared to 80's / 90's.

Modern day use as a nice high level language to use as framework/ide where end result gets compiled to java script / java.

[0] : https://www2.cs.arizona.edu/icon/

[1] : http://unicon.org/

[2] : https://yanniss.github.io/pepm04.pdf

[3] : https://www.dabeaz.com/generators/

[4] : https://en.wikipedia.org/wiki/Arc_(programming_language)

Ok, so which should be my next language. I mainly use it for one-off computing jobs. It should be

- pretty readable,

- not require compilation,

- have convenient data structures and a math library,

- and be performant out of the box.

That's the use case for Julia.

Anything performant will require compilation. Interpreters are inherently slower. But some languages do the compilation implicitly for you and that's usually close enough.

No explicit compilation often means no ahead of time error reporting though which is a really useful feature for run-once programs.

It depends on the nature of your compute. If it is dominated by IO, or if you are actually calling native libraries (like `numpy` does, or it is something that is handled by `arrow`), there is no reason to switch away from Python. If you are writing custom algorithms, I think https://julialang.org/ is a great option.

Now you mention it, I've seen Julia mentioned here before and it peaked my interest then as well. I'll give it a go. Thanks.

When I read this:

> low-level languages like C or C++

I stopped reading. I'm willing to bet the "high" in "high-performance" is relative to something very low.

How does this compare to Nuitka or Jax?