9 ms·
Codon: A high-performance Python-like compiler using LLVM
- harvie 4y agoUnfortunately stuff like this never makes it to the upstream. And i am afraid to ask why. We had pypy for years, but never got merged with python. That is why there are still minor incompatibilities between pypy and "The Python", so it's not that useful as it might have been if it got merged with cpython at some point.
- dr_zoidberg 4y agoI got a massive jump in performance when moving from Python 3.8 to 3.10 (over some function call optimizations I think, based on the project). And 3.11 got even better (up to 50% faster on special cases, and 10~15% on average) with respect to 3.10. Python 3.12 is already getting even more speedups and a there's a lot more down the road[0]. But Python core developers value keeping "not breaking anyones code" (Python 3 itself was a huge trip on that aspect and they're not making that mistake again), that's why things may seem slow on their end. But work is being done, and the results are there if you benchmark things. [0] See https://github.com/faster-cpython/ideas/blob/main/FasterCPythonDark.pdf https://github.com/faster-cpython/ideas/blob/main/FasterCPyt... however that's over a year old already and I'm sure I've read/heard more specifics
- pabs3 4y agoPython 3.11 broke a lot of stuff in Debian, as did earlier versions of Python 3: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=python3.9&tag=python3.10&tag=python3.11&users=debian-python@lists.debian.org https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=python3.9&...
- gjvc 4y agosame. for my work project, 3.11 was performance-equivalent to pypy 3.9
- amelius 4y agoInteresting. What is the status of the GIL these days?
- ris 4y agoExactly the same as it ever was, but if you're doing cpu-heavy stuff on python objects you're doing it wrong because they'll never be Fast.
- dr_zoidberg 4y agoI think 3.12 will get subinterpreters, which will allow you to have multiple interpreters, each on its own thread, sharing the process memory space. So kind of like a stopgap in between having real multithreading and pythons current situation. I'm not sure what to think of it so far, so until there's some beta or RC build to test, I don't think I'll be able to form an opinion.
- travisoliphant 4y agoThere is a branch of the 3.9 release that removed the GIL created by Sam Gross that you can read about here: https://gavincyi.github.io/2022-10-03-does-sam-gross-nogil-cpython-fork-perform-faster/ https://gavincyi.github.io/2022-10-03-does-sam-gross-nogil-c... There is some work to bring it up to 3.12 and some resistance to merge it into 3.X because of the impact on extension modules (they all have to be recompiled and in some cases changed a bit). If you are interested in it, reach out to Sam. He has done a pretty impressive piece of engineering work.
- LtWorf 4y agoI got performance regression going from 3.10 to 3.11 https://ltworf.github.io/typedload/performance.html https://ltworf.github.io/typedload/performance.html
- dr_zoidberg 4y agoWhile it was still on RC builds I tested it on a few projects I usually run and I got between 0 and 15% faster wrt 3.10, without any regression. But sure, every project is different and it looks like you've bumped into some with your project. If it's not too big, you might as well just leave things as they are and wait for 3.12 to see what changes then. Apparently the changes will be bigger, so it could be be much better than 3.11 (without being much worse, hopefully!).
- laerus 4y agoIt's not like you can just "merge" pypy into python, they are totally different implementations. CPython is written in C and PyPy is written in RPython which is a subset of the python language that gets compiled, into into an interpreter with JIT support. You can actually write an interpreter for any language using RPython and their toolset, for example Ruby https://github.com/topazproject/topaz https://github.com/topazproject/topaz
- williamstein 4y agoMorever, a wonderful aspect of standard CPython is that you can compile it from source on a huge range of architectures in less than 5 minutes. Building Pypy from source is more difficult, and Pypy is significantly less portable (e.g., there is no viable WebAssembly version of Pypy).
- camdenreslink 4y agoNo need to be afraid. The Python C extension API makes it very hard to make a JIT work well because of how it is implemented. C extensions are also part of why Python is so popular in the first place. If everybody wrote pure Python (like they write pure JavaScript), then the reference implementation would probably look like Pypy.
- danbmil99 4y agoThe number one question for me would be, is it interoperable with existing Python and libraries?
- poulpy123 4y agoafter reading it's not a python compiler but a compiled language based on the python syntax
- JonChesterfield 4y agoOne of the faq things refers in passing to integers being 64bit instead of arbitrary precision. That's a bit more fundamental than some cpython modules don't work. Haven't found a language reference yet. edit: it's statically typed ahead of time - that feels like something that needs a detailed description of what it's doing, given the baseline of like-python
- bogwog 4y agoI wonder if the differences will cause any real compatibility issues with existing Python libraries?
- williamstein 4y agoIt would cause major issues to libraries for mathematics (such as sympy or sagemath) that assume integers are arbitrary precision. Large integers are common in number theory and cryptography, where people also care very much about performance.
- tomas789 4y agoWhat is the difference between Codon and Pypy other than Codon not being targeted as a drop-in replacement for Cpython?
- arshajii 4y agoSome info on that at https://docs.exaloop.io/codon/general/faq#how-does-codon-compare-to https://docs.exaloop.io/codon/general/faq#how-does-codon-com......
- williamstein 4y agoTheir benchmarks (https://exaloop.io/benchmarks https://exaloop.io/benchmarks) show that Codon is much, much faster than pypy. I also just tried some microbenchmarks with their fib example (iterated many times with higher parameters) and got similar results. It's unfortunate for now that this isn't open source, but it's really valuable to demonstrate to us Python lovers what's possible using LLVM!
- cogman10 4y agoTheir benchmarks are not to be trusted (after reading the source). - They cheat, they rewrite code to use coden specific features to "win" (ie, parallelization and GPU optimizations) - They don't warm up. They are simply running their competition directly rather than allowing any sort of warmup. (In other words, they are measuring cold boot and startup time) Now, if they want to argue about startup time or whatever mattering for performance then fine. However, the representation of "20x faster!" is simply deception. TBF, they are upfront about cheating > Further, some of the benchmarks are identical in both Python and Codon, some are changed slightly to work with Codon's type system, and some use Codon-specific features like parallelism or GPU.
- williamstein 4y agoThanks for doing the work to point all of this out. "Benchmarketing".
- brrrrrm 4y agodoes this support any form of FFI? It'd be nice if users could shim in lightweight APIs that clone libraries like numpy/pytorch -- it'd immediately make some machine learning super portable!
- redleader55 4y agoFree for non-production use... it's a "no" for me.
- williamstein 4y agoWoah - also, their license automatically becomes open source (Apache) three years from now.
- kevincox 4y agoThe problem with these is always security updates. If you want to run on the old stuff you have to make your own security patches. Of course maybe that is exactly something that it makes sense to pay for.
- blahgeek 4y agoIt's also confusing... I mean, what does "non-production use" mean anyway? Does it mean "non-commercial use"? Or "testing/debug/staging environment"? Or "does not produce any valuable output"...?
- williamstein 4y agoAccording to this article https://perens.com/2017/02/14/bsl-1-1/ https://perens.com/2017/02/14/bsl-1-1/ about the Business Source License, the intention conveyed by the word "production" for that license is use "in any capacity that is meant to make money".
- williamstein 4y agoWhat I want to know is: "can I add Codon to a site like https://cocalc.com https://cocalc.com that I host as long as users of Codon explicitly agree to only use it in a way that is compatible with the license?" I have absolutely no idea if that would be allowed by the rules or not.
- 4y ago
- IceHegel 4y agowould love to see actual benchmarks
- arshajii 4y agoWe do have a benchmark suite at https://github.com/exaloop/codon/tree/develop/bench https://github.com/exaloop/codon/tree/develop/bench and results on a couple different architectures at https://exaloop.io/benchmarks https://exaloop.io/benchmarks
- _aavaa_ 4y agoWhy are do the C++ implementations perform so poorly?
- camel-cdr 4y agoMy guess for word_count and faq is that the C++ implementation uses std::unordered_map, which famously has quite poor performance. [0] [0] https://martin.ankerl.com/2019/04/01/hashmap-benchmarks-01-overview/ https://martin.ankerl.com/2019/04/01/hashmap-benchmarks-01-o...
- memco 4y agoDon't have anything significant, but giving this a quick test with some of my advent of code solutions I found it to be quite a bit slower: time python day_2.py ________________________________________________________ Executed in 57.25 millis fish external usr time 25.02 millis 52.00 micros 24.97 millis sys time 25.01 millis 601.00 micros 24.41 millis time codon run -release day_2.py ________________________________________________________ Executed in 955.58 millis fish external usr time 923.39 millis 62.00 micros 923.33 millis sys time 31.76 millis 685.00 micros 31.07 millis time codon run -release day_8.py ________________________________________________________ Executed in 854.23 millis fish external usr time 819.11 millis 78.00 micros 819.03 millis sys time 34.67 millis 712.00 micros 33.96 millis time python day_8.py ________________________________________________________ Executed in 55.30 millis fish external usr time 22.59 millis 54.00 micros 22.54 millis sys time 25.86 millis 642.00 micros 25.22 millis It wasn't a ton of work to get running, but I had to comment out some stuff that isn't available. Some notable pain points: I couldn't import code from another file in the same directory and I couldn't do zip(*my_list) because asterisk wasn't supported in that way. I would consider revisiting it if I needed a single-file program that needs to work on someone else's machine if the compilation works as easily as the examples.
- deleted 4y ago[deleted]
- LarsDu88 4y agoDo people not know about numba which unlike this project is FOSS and integrates with numpy???
- killingtime74 4y agoDoesn't it require you to annotate every function if you want to compile to a binary? That makes it more like Cython than this. https://numba.readthedocs.io/en/stable/user/pycc.html#overview https://numba.readthedocs.io/en/stable/user/pycc.html#overvi...
- bornfreddy 4y agoDoes it make sense to use Numba with Django / Flask / FastApi?
- LarsDu88 4y agoIf you're trying to do intense numerical computations on the backend...
- xapata 4y agoNumba doesn't market itself very well.
- nerdponx 4y agoAnd Numba is actually CPython, unlike this which is just "Python-like". There's also Nuitka as yet another alternative. Or you're going to use a "Python-like" compiled language, consider using Nim.
- ipsum2 4y agoFor context, Numba also uses the LLVM and it works with Python code via decorators.
- melenaboija 4y ago> "...typically on par with (and sometimes better than) that of C/C++" What makes it faster than C++? I see this in the documentation but I am not sure it helps me (not an expert): > C++? Codon often generates the same code as an equivalent C or C++ program. Codon can sometimes generate better code than C/C++ compilers for a variety of reasons, such as better container implementations, the fact that Codon does not use object files and inlines all library code, or Codon-specific compiler optimizations that are not performed with C or C++.
- __ryan__ 4y agoJIT.
- ot 4y agoJIT can be faster than a static compiler if it takes advantage of runtime feedback, but that's not the case here: > While Codon does offer a JIT decorator similar to Numba's, Codon is in general an ahead-of-time compiler that compiles end-to-end programs to native code.
- boomanaiden154 4y agoIt can be, but if you're using PGO, the performance gains from JIT are a lot less significant and you lose the compilation overhead at runtime that you have with JIT.
- xapata 4y agoUgly, confusing naming choices: ``@par`` instead of ``@parallel``.
- jlokier 4y agoHow do you feel about `def` instead of `define`?
- bombolo 4y agoand abs instead of absolute
- xapata 4y agoAbbreviations are good to the extent that they're commonly used. It's a bit of a chicken-and-egg problem. At the time Guido picked `def`, I might have argued with him. Now, it's the standard. If I were writing my own language, I might choose `let` instead of `def`. For example, `let x = 1`.
- ot 4y agoCan we change the title to say Python-like or something similar? Based on the comments so far, it seems that the detail that it compiles its own Python-inspired language, not actual Python, is lost on many. EDIT: A list of differences here: https://docs.exaloop.io/codon/general/differences https://docs.exaloop.io/codon/general/differences The summary minimizes with "many Python programs will work with few if any modifications", but it actually looks like a substantially different language.
- darawk 4y agoThat list actually seems genuinely pretty minimal. Reading your comment I was expecting a long major list of changes, but it's only 3 things, most of which seem relatively unlikely to impact most programs, with the possible exception of dictionary sort order.
- KerrAvon 4y agoRead the entire page. Those three bullet points aren't the extent of it. This is like the difference between Ruby and Crystal; the same syntax, similar culture, but they're fundamentally different languages.
- antoinealb 4y agoThe list of small things are for data structure. However, the language is a lot less dynamic than Python: > Since Codon performs static type checking ahead of time, a few of Python's dynamic features are disallowed. For example, monkey patching classes at runtime (although Codon supports a form of this at compile time) or adding objects of different types to a collection. While monkey patching is maybe not done so much in Python (outside of unit testing), adding objects of different to a collection is definitely a common operation!
- unsafecast 4y agoFrom what I understand, this will be possible in the future with implicit union types. Wouldn't work with _arbitrary_ types, but with a set of types that can be computed at compile time (my guess is that this is possible in most real-world cases).
- slt2021 4y agopower of Python is in ecosystem of libraries, not only Python syntax. Without the ecosystem of libraries, I am afraid use cases for Codon will be very very limited. Because Python developers (just like Node) got used to thinking: Need to do X? Lets see if I can pip install library that does it. Ultimately, python is like super flexible glue between ecosystem of libraries that lets anyone build and prototype high quality software very quickly
- victoryhb 4y agoIf Codon becomes similar enough to Python, it will be trivial to port Python libs to it, thus opening Codon to the vast Python ecosystem.
- slt2021 4y agoThe only trivial thing in software is hello world, anything more complicated or useful for end users is usually far from being trivial, in my experience.
- _frkl 4y agoWhat's the story with Python libraries that have c-modules/binary parts to it? Would those work? If not, then the previous comment stands, IMHO.
- dingdingdang 4y agoPerhaps the way forward for Codon in terms of wider adoption would be maintaining a list of libraries that are fully Codon compatible, thereby encouraging devs to aim for cross-compatibility (which would likely naturally exclude usage of a lot of the slower Python features in turn making the libraries faster for both Codon and regular Python users)
- weinzierl 4y agoI want the opposite. Is there a project that compiles to python (either source or bytecode)? Sort of a graalvm for python?
- odo1242 4y agoWebAssembly? Try compiling something to WebAssembly and running it in python?
- weinzierl 4y agoI haven't thought of that. It's a good idea. I know how to compile to WebAssembly but how do I run it in python? A quick search leads to pywasm and it is even native python. But is it usable? Any other options?
- syrusakbary 4y agoWasmer Python can be used if you want to run Wasm in Python. Hope this helps! https://github.com/wasmerio/wasmer-python https://github.com/wasmerio/wasmer-python
- grumpopotamus 4y agohttps://coconut-lang.org/ https://coconut-lang.org/
- poulpy123 4y agoI don't remember the name but there is a lisp that compile to python
- CyberDildonics 4y agoCodon is a high-performance Python compiler that compiles Python code to native machine code without any runtime overhead Further down: Codon is a Python-compatible language, and many Python programs will work with few if any modifications:
- pmontra 4y agoI googled 'codon and django' and unsurprisingly found a lot of bioinformatic stuff. I tried to add language and compiler to no avail. The only query that got results was codon python compiler. Overall I think it's a name that clashes with a lot of DNA/RNA research. While searching I found a paper from 2021 about Codon [1]. The author is not in the About page of Exaloop [2] but the supervisor of that thesis is there. From the "Future Work" section: > we plan to add union types and inheritance. On the IR side [Intermediate Representation], we hope to develop additional builtin transformations and analyses, all the while expanding the reach of existing passes. As far as library support, we plan to port existing high-performance Python libraries like NumPy [...] to Codon; this will allow Codon to become a drop-in replacement for Python in many domains. Maybe they already did. [1] Codon: A Framework for Pythonic Domain-Specific Languages by Gabriel L. Ramirez https://dspace.mit.edu/bitstream/handle/1721.1/139336/Ramirez-glram-meng-eecs-2021-thesis.pdf https://dspace.mit.edu/bitstream/handle/1721.1/139336/Ramire... [2] https://exaloop.io/about.html https://exaloop.io/about.html
- inetknght 4y agoHaving worked in the DNA analysis space and admittedly haven't read the article... my first thought was that Codon was some python library for DNA stuffs that gets compiled via LLVM for performance.
- sambeau 4y agoWho would create a language that only has ASCII strings in this day and age?
- naasking 4y agoSomeone who's just trying to get something up and running. Unicode is complicated.
- deleted 4y ago[deleted]
- tasty_freeze 4y agoHere is the quote of the thing you are referring to: > Codon currently uses ASCII strings unlike Python's unicode strings. Note the word "currently." Implementing this while also tracking the constantly evolving Python language through its various versions is a lot of work. They apparently prioritizing other things over this particular aspect.
- munificent 4y agoSince Codon performs static type checking ahead of time, a few of Python's dynamic features are disallowed. For example, monkey patching classes at runtime (although Codon supports a form of this at compile time) or adding objects of different types to a collection. This seems like a very different language from Python if it won't let you do: [1, 'a string']
- deleted 4y ago[deleted]
- didip 4y agoI welcome this change. I am willing to sacrifice a few Python features for the sake of speed.
- jnxx 4y agoI have been using Python since 25 years, and never needed that one.
- joshmaker 4y agoIn 25 years you’ve never once created a list with more than one type of object in it?
- gautamdivgi 4y agoI’ll second that. I’ve been doing python for a while and haven’t used the mixed type list. I’ve actively avoided doing something like that. The situation doesn’t come up often.
- cjohnson318 4y agoMaybe a list with ThingObject or None, but my lists are usually homogenous.
- mrfox321 4y agothats just homogenous Sequence[Optional[T]], though.
- victor82 4y agoSeems there is not bytearray implemented, can't test further :(
- ubj 4y agoVery interesting--Codon can generate standalone executables, object files, and LLVM IR [1]. It has strong typing for functions and argument return values [2]. Syntax looks more compact than Cython. Looking forward to giving Codon a try! [1]: https://docs.exaloop.io/codon/general/intro https://docs.exaloop.io/codon/general/intro [2]: https://docs.exaloop.io/codon/language/functions https://docs.exaloop.io/codon/language/functions
- maxloh 4y agoWhat's the difference with mypyc [0] ? It also compiles Python to native code. [0]: https://github.com/mypyc/mypyc https://github.com/mypyc/mypyc
- return_to_monke 4y agothe last commit to it's repo was 2 years ago.
- okso 4y ago> The mypyc implementation and documentation live in the mypyc subdirectory of the mypy repository. > Since mypyc uses mypy for type checking, it's convenient to use a single repository for both. > Note that the mypyc issue tracker lives in this repository! Please don't file mypyc issues in the mypy issue tracker. See https://github.com/mypyc/mypyc/blob/master/show_me_the_code.md https://github.com/mypyc/mypyc/blob/master/show_me_the_code....
- shadowofneptune 4y agoThis gives the same feeling as AssemblyScript: it says it is one language, up to the point it isn't. That may make it easier for some people, but feels so uncertain. Both have a very slim set of articles in place of a proper manual; they lean on their parent languages.
- grumpopotamus 4y agoAny benchmark comparisons to mypyc yet?
- yayr 4y agoCan it run PyTorch, TF etc?
- PaulHoule 4y agoHow does this relate to https://cython.org/ https://cython.org/ ? Would it be possible to write performance-sensitive parts of a Python system in Codon and link that to a CPython or PyPy runtime that supports more dynamic features?
- bastawhiz 4y agoCython takes python-ish code and compiles it to C for use as CPython C extensions. This compiles directly to machine code without the need for CPython, as far as I can tell.
- jnxx 4y agoJust out of curiosity: Why is it possible to compile Common Lisp Code (or Scheme, or Clojure) to high-performance native or jit-compiled code, but not Python? It is said that "Python is too dynamic", but is not everything in Lisp dynamic, too? And none of these languages is less powerful than Lisp, lack Unicode support, or whatever, so this can't be the reason.
- miohtama 4y agoIt’s because Python object attributes can change any time, as they are accessed dynamically. Nothing can be inlined easily. The object structure is pointer heavy. Here is some old 2014 post: http://jakevdp.github.io/blog/2014/05/09/why-python-is-slow/ http://jakevdp.github.io/blog/2014/05/09/why-python-is-slow/ As other commenters pointed out, some of these Python features, which are unused 99,99% time, could be sacrified for additional speedup by breaking backwards compatibility.
- hathawsh 4y agoThe demand for compiled Python hasn't been as high as the demand for other languages, so the number of people who have worked on it is much smaller than the number who have built JITs for ECMAScript and others. Python has long been fast enough for many things, and where it isn't, it's easy to call C code from CPython. Python does have lesser-used dynamic capabilities that probably don't exist in Common Lisp. Those capabilities make it difficult to optimize arbitrary valid Python code, but most people who need a Python compiler would be happy to make adjustments.
- 4y ago
- v3ss0n 4y agoWhy not contribution to PyPy and Why not MyPyC
- bastawhiz 4y agoPypy uses its own JIT. This project does AOT with LLVM. They're not compatible. MyPyC requires type annotations to work. This does not.
- qwefsdf 4y agoAnybody claiming it's almost Python is kidding themselves. This compiler needs to do static type checking. This is inherently impossible in Python. Not just because of some obscure corner cases that nobody uses. It's baked into the language itself. Reality-check: Why do you think type hints and type checkers like mypy and pyright take such a long time to get going and even they are not there yet? If this was all so easy with just ignoring some obscure rarely used features then mypy would work with essentially no type annotations, all just automatic inferences. Anybody who has tried to work with type annotations in Python knows how hard this is. So, those guys are quite obviously overselling their product. I can understand it, academic life is hard, and once you've completed your Ph.D., what can you do. You need to stand out. But these claims don't pass the smell test, sorry.
- LargoLasskhyfv 4y agoWhat about GraalVM? Are they overselling, too?
- mrbald 4y agoNo, their python support repository readme explicitly tells it’s highly experimental.
- UncleEntity 4y agoIf I can write (mostly) python code and get it to run on my GPU they can oversell this all they want. I have a couple of projects I’ve been wanting to tackle but put off because I like python but it wouldn’t be a very good fit due to performance reasons. Now I get a whole new herd of yaks to shave. Plus, extensible compiler? Who doesn’t want linq in python?
- yablak 4y agoLook at numba, which is not quite but sometimes good enough :)
- mk_stjames 4y agoJust tried: it hangs on a numpy import. Hell it hangs on an "import time" module. If I cannot reinterpret code that is already written, then I might as well just rewrite code in a language that is better suited. Saying I can 'compile' Python code like this does indeed look like an oversell and a half. I mean... if you had a 'compiler; for python that looked at my code at runtime- including imports- and all my current input and.... given the data types it sees and nothing more, do type-inference and recompilation down to LLVM and then to my machine code, while taking things that were already calling compiled modules (like numpy) and keeping them separate subroutines and thus only operating on the 'slow' parts of my code... with the speedups therein.. I'd be sold. Of course, I think I basically just described Julia.
- arshajii 4y agoThanks a lot for all the comments and feedback! Wanted to add a couple points/clarifications: - Codon is a completely standalone (from CPython) compiler that was started with the goal of statically compiling as much Python code as possible, particularly for scientific computing use cases. We're working on closing the gap further both in what we can statically compile, and by automatically falling back to CPython in cases we can't handle. Some of the examples brought up here are actually in the process of being supported via e.g. union types, which we just added (https://docs.exaloop.io/codon/general/releases https://docs.exaloop.io/codon/general/releases). - You can actually use any plain Python library in Codon (TensorFlow, matplotlib, etc.) — see https://docs.exaloop.io/codon/interoperability/python https://docs.exaloop.io/codon/interoperability/python. The library code will run through Python though, and won't be compiled by Codon. (We are working on a Codon-native NumPy implementation with NumPy-specific compiler optimizations, and might do the same for other popular libraries.) - We already use Codon and its compiler/DSL framework to build quite a few high-performance scientific DSLs. For example, Seq for bioinformatics (the original motivation for Codon), and others are coming out soon. Hope you're able to give Codon a try and looking forward to further feedback and suggestions!
- victoryhb 4y agoExcellent job. I can already see this being much more flexible than Numba and much more elegant/easy to use than Cython. Please keep it coming:)
- nhumrich 4y agoIm curious. If codon can compile a python script, why can it not compile a pure python library? What technical limitations does an import or 3rd party add that a script wouldn't have?
- LoganDark 4y agoNumPy, PyTorch, TensorFlow and many other widely known third-party libraries are actually native code that interact with CPython directly.
- taylorius 4y ago
- synergy20 4y agoLooks like what taichi(https://github.com/taichi-dev/taichi https://github.com/taichi-dev/taichi) is doing, does this support CUDA yet? additionally how does it compare to numba the compiler for python? looks like python's performance on ML and AI field will only get stronger.
- v3ss0n 4y agoPlease note, codon is not opensource. It is business source license.
- jarbus 4y agoThings like this are always going to be another point of failure when trying to get something to work. Now when your python code crashes, there's a new reason something could be going wrong, in addition to the countless other reasons.
- peter_d_sherman 4y ago>"Typical speedups over Python are on the order of 10-100x or more, on a single thread. Codon's performance is typically on par with (and sometimes better than) that of C/C++" Nice! A super-fast compiler LLVM compiler for Python! Well done! You know, if Python is one of the world's most popular languages, and it was originally implemented as a dynamic and interpreted language (but fast compilers can be written for it, as evinced by Codon!) -- then maybe it would make sense to take languages that were implemented as compilers -- and re-implement them as dynamic interpreted languages! Oh sure -- that would slow them down by 10x to 100x! But, even though that would be the case -- the dynamic interpreted versions of the previous compiled-only language -- might be a whole lot more beginner friendly! In other words, typically in dynamic interpreted languages -- a beginner can use a REPL loop or other device -- to make realtime changes to a program as it is running -- something that is usually impossible with a compiled language... The possibilities for easy logging, debugging, and introspection of a program -- are typically greater/easier -- in interpreted dynamic languages... Oh sure, someone can do all of those things in compiled languages too -- but typically the additional set-up to accomplish them is more involved and nuanced -- beginners typically can't do those things easily! So, I think when I think about programming languages from this point forward -- I'm going to think about them as having "two halves": One half which is a compiled version. And another half -- which is a dynamic interpreted version... Usually when a new programming language is created in world, it is created either as a compiled language or as a dynamic interpreted language -- but never both at the same time! Usually it takes the work of a third party to port a given language from one domain to the other, usually from dynamic interpreted to compiled, but sometimes (as is sometimes the case with scripting languages derived from compiled languages), sometimes in the reverse! Point is: There are benefits to be derived from each paradigm, both dynamic interpreted and compiled! So why do we currently look at/think about -- most computer languages -- as either one or the other? I'm going to be looking at all computer languages as potentially both, from this point forward... (Related: "Stop Writing Dead Programs" by Jack Rusher (Strange Loop 2022): https://www.youtube.com/watch?v=8Ab3ArE8W3s&t=1383s https://www.youtube.com/watch?v=8Ab3ArE8W3s&t=1383s)