Performance and transitioning from Python

[highfestiva]

Hi BDFL,

This can become a great language given some time and clear+correct goals! Python is the most popular language since a couple of years, and it's vital to understand that simplicity took it there. Reading a Piece of Python is a breeze compared to C, Java, C++, Rust and C#, which are the next-most popular languages. The reason Python overtook all these languages is threefold: fewer characters to read to absorb any piece of code, simpler syntax for simple things and not putting any restraints on how shitty code you can write.

Those three lead to broad adoption for scripting, matplotlib for vector math, scientific community started using it and the rest is history.

Python has one obvious drawback: performance. Because of this, there is the need to drop out into C to get things done with some performance.

If this language is going to go anywhere, it needs to compete and win over Zig, Nim, V... and Python. My hopes and recommendation is therefore to relax the async requirements for all three reasons Python became the world's most popular language. Everyone likes nice code, but it shouldn't be a requirement. The idea of strict mode or something along those lines is your friend. If Acton can get closer to Python's syntax, with preformant SIMD support and all the rest built-in, it will be much closer to a drop-in Python replacement instead of trying to transpile to Zig.

This doesn't mean that you need drop the drop the async ideas, but to be truthful I think fibers and light-weight threading is going through a resurgence. For enterprise software, where Java today is the main player, this is a big deal for two reasons. Firstly, it removes the need for futures, which are cumbersome, error-prone, difficult to reason about and expensive. And secondly, it moves is Enterprise software back into sequential coding, which is much better in these regards with the added bonus of speed of bringing in junior developers and quality of reviews + architecture.

If this however is not done, you fall into three traps. Acton is always going to be more cumbersome than Python for simple things. And you're never going to reach the development momentum required to catch up with for example Zig's performance. The third thing is you'll never get enough collaborators to increase the development pace, for the previous two reasons.

If you one the other hand would choose to go down the "performant Python" path, you could easily assemble a legion of skillful developers willing to help out.

Either way, wish you all the best,
Jonas

[plajjan]

Hi, thanks for chiming in :)

I'm not sure if you are suggesting we should be 100% compatible with Python or if you are saying we just have to skip async to stay as simple as Python?

Programming languages are usually about tradeoffs, so while we might need to beat Zig, Nim and Python, I think we will beat them in different areas or perhaps as being a more well rounded language given certain aspects deemed important. We're a high level GCed language, so we really can't beat Zig / C in performance, but surely Acton can beat C in terms of type safety (like you can't get a segfault in Acton). Measured against Python, I think Acton can be faster, but it might mean fighting a few more type errors along the way. There is one area in particular I want Acton to shine and that is for writing large distributed applications, both tightly coupled and more loosely coupled. I want it to feel like writing a single application for a single computer but where it just runs on many machines. That's not possible in Python today, so we somehow need to elevate ourselves beyond that.

It's very hard to just make a faster Python and stay compatible with all Pythons quirks and weirdness. The "problem" with Python (as if there is one ;)) is that the language design itself makes it slow. If we want C-speed, then we need things like inlined code and unboxed integers, which requires types known at compile time, in turn introducing dependencies on the code. We think we can do this through modern compiler techniques while largely maintaining the ease of use of Python... but it won't be Python, Acton code is not compatible with Python, it just looks quite Pythonic. It often is compatible, but not always and not by definition. I have built a lot of benchmarks by copying Python code verbatim into an Acton program, but often a few minor changes are necessary to make it work.

Python has been my go-to language for over a decade now so I definitely feel for where you are coming from and I've carried this with me in the design process of Acton. The core design of Acton was pretty much done by the time I got involved (at least on a detail level) but throughout my involvement I have constantly asked "should we be 100% python compatible". The answer I've landed is... no, Acton is not Python compatible / interoperable, i.e. we cannot just run any piece of Python code. This is by design, because staying 100% compatible means we cannot improve on Python. We would be held back by all of Pythons design choices and we don't want that.

Further, Python encourages many bad programming practice. Everything is public and mutable, no real structs, so everyone uses dicts everywhere and for everything etc etc. Yet I love it myself because it's so simple and I'm productive in Python. I'm personally very intrigued by the idea of a progression from dumb simpler programs to larger, more advanced, higher quality applications. Like when I write a shell script I mostly don't care about error handling at all while when I'm writing production code, error handling is almost all I do. For 500 people collaborating on writing a large system, the stricter type systems of C++, Java etc are helpful. People say "use the right language for the task" but I think that's giving up, for many of these aspect I think we could have one language with a progression where one can start out simple and advance. For example, in Python you can write a simple script with no error handling and make it robust by adding in exception handling in various places. Perl had "use strict". In what other areas can we apply a similar incremental approach to improving quality or robustness?

Acton was born out of a need for building non-stop automation systems. We are working on a concept called orthogonal persistence where the running state of a program is persisted to a distributed database and as such, can be resumed, so if a computer dies, any actors running on it can be resumed on other servers. It's pretty cool and fairly unique. Microsoft Orleans does something similar, but not as rigorously as Acton and there is also prior art in Argus, a programming language & run time system by none other than Barbara Liskov, from around the time I was born - she was certainly ahead of her time.

We want to eradicate certain types of problems. While Java etc might restrict certain objects from doing stuff, you can pretty much at any point make a syscall and then there are no restrictions whatsoever. The whole log4j debacle is a product of that. I am using a log library to write files to disk and all of a sudden it is connecting to the Internet, w t f? Acton has capability based authentication which means actors are only able to do things based on what capabilities they can reach. Other actor languages have similar systems, like Pony, and the general concept OCAP (Object Capabilities) is implemented in many places. It's quite incompatible with Python though.

You mention async but not specifically what part of async you don't like. Acton is actor based which means it's pretty natural to be async. Unlike many other actor languages, Acton does allow sync calls to other actors (really await on async, but user doesn't need to know), but any external I/O is indeed async callback based. The reason is simple, there is no guarantee that any external I/O will ever return anything, so an actor waiting for external I/O could be stuck waiting forever. How can we encourage users to write robust software while allowing for actors to get stuck like that? I think we are already more async under the hood than what is exposed to the Acton programmer, but I suppose you meant to take this further? Even allowing blocking calls for external I/O?

Not sure if you are implying Acton should use fibers or light weight threads. Acton is actor based, and actors are already pretty light weight.

I think it's a necessity to at least be different than Python, which might appear "more cumbersome" simply by virtue of being different. We aspire to keep it to a minimum but where necessary I am sure it will lead to more robust programs and in turn also unlock and simplify things that are not possible with Python.

Have you tried out Acton or simply run across it? :)

Feedback as your is always welcome, so keep it coming :)

Did you see Mojo? Chris Lattners project on a faster Python?

[highfestiva]

Thanks for the great response, a perfect summary of your over-arching goals. The idea of taking hacks to production-grade is a good one, I like it! Unfortunately I have not tried out Acton, I am early majority guy and not bleeding edge adopter. :)

Many speak about the virtues of programming languages which generate robust production software. To me that is very similar to talking about optimization as a goal of programming language. While the truth is that optimizations need to happen in a few tight loops. And stability is not as important in setup, shutdown, resource loading, unloading, boilerplate, iterations with little variation, http endpoints via some well-established framework and so forth, i.e. 95% of most applications.

Preventing log4j-alternatives from connecting to the internet might be a bad idea in general. If people want to create badly designed code, I think they should be allowed to do so, as in all other human ventures.

Other programming languages who tried preventing developers from making mistakes are hardly popular at all. In fact, it almost looks like the most popular programming languages are the best at allowing people to make a mess of their algorithms. Why might that be? I don't know, but perhaps for the same reason the axe is a more popular tool than the mallet.

Anyway, you've got lots of interesting ideas. I would only caution you to focus more on what we know works (as you're investing so much time), instead of trying out concepts that are much less popular.

Hard to comment on Mojo without trying it out for myself on actual code that isn't Hello World. Speed sounds good. def -> fn not so good (as compiler could auto-detect it).

[plajjan]

We're not preventing anyone from implementing log4j in this exact way, what we are doing is making it explicit to the user of the library what capabilities the library requires and thus what it is capable of. To run a ported version of log4j, you would need to give it the capability both to write files to disk and connect over the network. It would perhaps make you think "wait, why does this library want to connect over the network when I just want to write a log file".

But perhaps more importantly, it would encourage the author of a log4acton to design the library in such a way that you can use portions of the library, choosing if you want logging over the network or to file, so that you can limit its privileges. Or that you can limit which TCP hosts it can connect to, allowing syslog to a remote host, but not the TCP connect to anything else.

I think this is a natural progression, similar to how adopting structured programming brought, well, structure to programming, capabilities does the same for privilege restriction and security isolation. If you remember before the time of function (I don't, I was hardly born ;) ), any piece of code could at any time jump to any other place. The only way to understand a program was to know the entirety of it. You could not skip any single function, since it could jump anywhere else and completely change the control flow from what you thought. Dijkstra changed this with the now classic "Go TO considered harmful". When you call a function in C, you know that the control flow is such that the function will return. While goto still exists, in modern C, goto is confined to jump within a function, so the function still returns. It is this promise of called functions returning (and not jumping to anywhere else in your program) that makes it possible to reason about large programs because you can gradually move up in abstraction layers and you can still understand the control flow. Syscalls happening at any layer is, in a way, similar to goto, that it at any point can make radical changes to the environment of your program. You call "printfoo" and it turned off your computer, what a surprise. In Acton, you would have to grant the printfoo function the capability to turn off the computer and you might ask why a print function would need that.