Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SPy: An interpreter and compiler for a fast statically typed variant of Python

antocuni.eu

Post reply on HN
Print view View original

81–90 of 133 posts

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#81

Post by netbioserror »

almostgotcaught wrote: post #76
netbioserror wrote: post #56

Earlier quoted context omitted.

Throwing my hands up and moving to Nim was downright easy next to the excessive effort I put into trying out Nuitka, Numba, and PyInstaller for my use case. If you want static compilation, use a language and libraries built with that assumption as a ground rule. The herculean effort of building a half-compatible compiler for a dynamic language seems like a fool's errand, and would be a fun curiosity if so many people…

all of this is well and good if you completely forget that there are billions of lines of Python in prod right now. so your grand epiphany is basically on the level of "let's rewrite it in Rust". i'll let you hold your breath until that rewrite is done (and in the meantime i'll explore workarounds).

I finished the rewrite in just a few months and have been happily maintaining it for two years and extending it with powerful features it never had before, partially thanks to optimized native binary speed, partially thanks to the ludicrous compatibility of a musl-libc static binary. The rewrite is the backend foundation of a web product stack that is best-in-category.

I didn't choose Nim because I was an evangelist; I had only toyed with it twice before. After much evaluating (and wrestling an ultra-frustrating previous attempt at a Rust rewrite my predecessor had tried), Nim surfaced as the best tool for the specific job. And it still is. It doesn't have to be our entire product stack; it's doing a small subset of very important jobs, doing them well, and is invoked by other languages that do their jobs better as web servers and such. A modular stack helps each language and tool shine where it works best.

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#82

Post by HanClinto »

pansa2 wrote: post #52
ajb wrote: post #45

It's weird, but the pain of moving to a whole new language seems less than the pain of using one of these language subsets. I guess it might be because of "loss aversion": we dislike losing something we have more the value we put on gaining it. In a new language each newly added feature is a gain, but in a language subset you're always encountering things you would have in the full language. So no matter how good the…

> in a language subset you're always encountering things you would have in the full language Exactly. I once pitched the idea of a Python subset (with a different focus, not performance like SPy), and almost every reaction was "will it support ". For example, a new language can build its own solution for array math, or maybe that's not something its users need. OTOH many consider a Python subset to be unacceptable if…

I can see the wisdom in this.

As a counter-example, it feels as though Typescript has managed to (largely?) succeed as a subset of Javascript, so maybe the "do your own thing" isn't entirely a lost-cause -- maybe it's just really really difficult?

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#83

Post by odie5533 »

summarity wrote: post #8
wodenokoto wrote: post #3

I like the idea of a compiled language that takes the look and ethos of Python (or at least the "looks like pseudocode, but runs"-ethos) I don't think the article gives much of an impression on how SPy is on that front.

You can have that today with Nim.

There don't seem to be great web frameworks like Flask, Django, or FastAPI for Nim.

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#84

Post by rangerelf »

walterlw wrote: post #14
wodenokoto wrote: post #3

I like the idea of a compiled language that takes the look and ethos of Python (or at least the "looks like pseudocode, but runs"-ethos) I don't think the article gives much of an impression on how SPy is on that front.

I believe that Python is as popular and widely used as it is because it's old enough to have an expansive ecosystem of libraries. It's easy enough to implement one in pure Python and possible to optimize it later (Pydantic is a great recent-ish example, switching to a Rust core for 2.0). That same combination of Python + (choose a compiled language) makes it quite difficult for any new language to tap into the main s…

It's not just its age, it's how easy it is (was?) to jump in and start writing useful code that could be revisited later on and be able to read it and understand it again.

All of these efforts to turn it into another Typescript are going to, in the end, kill the ease of use it has always had.

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#85

Post by dec0dedab0de »

HanClinto wrote: post #82
pansa2 wrote: post #52

Earlier quoted context omitted.

> in a language subset you're always encountering things you would have in the full language Exactly. I once pitched the idea of a Python subset (with a different focus, not performance like SPy), and almost every reaction was "will it support ". For example, a new language can build its own solution for array math, or maybe that's not something its users need. OTOH many consider a Python subset to be unacceptable if…

I can see the wisdom in this. As a counter-example, it feels as though Typescript has managed to (largely?) succeed as a subset of Javascript, so maybe the "do your own thing" isn't entirely a lost-cause -- maybe it's just really really difficult?

Typescript is a superset of javascript

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#86

Post by skavi »

miohtama wrote: post #16
falcor84 wrote: post #6

This seems to be going for a somewhat similar goal to Mojo [0] - anyone here who used both and is willing to offer a comparison? [0] https://www.modular.com/mojo

Based on my understanding, Mojo aims to make number crunch computation faster (GPU), while as SPy aims to make generic Python application logic faster. Very similar, but different sweet spots and use cases.

Your understanding of mojo is incomplete. Just visiting their website would have cleared that up.

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#87

Post by HanClinto »

dec0dedab0de wrote: post #85
HanClinto wrote: post #82

Earlier quoted context omitted.

I can see the wisdom in this. As a counter-example, it feels as though Typescript has managed to (largely?) succeed as a subset of Javascript, so maybe the "do your own thing" isn't entirely a lost-cause -- maybe it's just really really difficult?

Typescript is a superset of javascript

Aaah, you are correct -- I had that backwards. All Javascript is indeed valid Typescript, but not all Typescript is valid Javascript.

Appreciated

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#88

Post by pjmlp »

vidarh wrote: post #61
pjmlp wrote: post #21

Earlier quoted context omitted.

Just like Smalltalk and SELF, also Lisp Machines and Interlisp-D. Usually comes down from a urban myth that Python is special and there was no other dynamic language before it came to be. The JIT research on those platforms is what gave us leading JIT capabilities on modern runtimes, OpenJDK HotSpot traces back to Smalltalk and StrongTalk, while V8 traces back to SELF. Especially in Smalltalk and SELF, you can change…

> Granted what messes up Python, or better said CPython implemenation, is that C extensions are allowed to mess up with its internals thus making void many possible optimizations that would be otherwise available. I'm doing a Ruby compiler (very, very slowly, though faster again now with Claude Code doing most of the heavy lifting), and the same issue with Ruby has made me seriously toy with the idea of one day embed…

Have you seen how TruffleRuby makes use of LLVM bitcode, to ship C compiler as well?

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#89

Post by Smaug123 »

ltbarcly3 wrote: post #73

Statically typed. That's just Java with python syntax again, which the article tries to talk it's way out of but that's what it is.

This assertion is so vague as to be meaningless - say more? You're presumably not asserting that all statically typed languages are fundamentally Java, because that would be saying the patently false "C and Haskell are fundamentally Java". Are you specifically saying the article's hope that it's not "Java with Python syntax" is misplaced; if so, why?

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#90

Post by ajb »

almostgotcaught wrote: post #76
netbioserror wrote: post #56

Earlier quoted context omitted.

Throwing my hands up and moving to Nim was downright easy next to the excessive effort I put into trying out Nuitka, Numba, and PyInstaller for my use case. If you want static compilation, use a language and libraries built with that assumption as a ground rule. The herculean effort of building a half-compatible compiler for a dynamic language seems like a fool's errand, and would be a fun curiosity if so many people…

all of this is well and good if you completely forget that there are billions of lines of Python in prod right now. so your grand epiphany is basically on the level of "let's rewrite it in Rust". i'll let you hold your breath until that rewrite is done (and in the meantime i'll explore workarounds).

Now there are billions of lines of python in production. But it wasn't so long ago that it seemed like the entire industry was going to completely standardise on C++, and if you wanted a picture of your future, it would be grinding away debugging buffer overflows and thread lockups - forever.
Post reply on HN