> you can actually distribute Janet programs to other people. You can compile Janet programs into statically-linked native binaries and give them to people who have never even heard of Janet before
In theory you "can" do that with python too.
"Can" is a very different kettle of fish from "most people are inclined to".
Before you start screaming "cxFreeze/pyOxidizer/pyInstaller", NO. I have gone this route. It is incredibly painful. Python was built with the thought in mind that it would be interpreted. It wasn't engineered well for compilation. A significant amount of effort, often a significant percentage of the total effort, is spent shoehorning things into this as an escape hatch because requirements have changed. This is not the route to choose from the start. Same goes for Clojure and `native-image`. I'm glad the native image project exists, and we all hail babashka as a success story, but it doesn't mean its author didn't have to spend a ton of time with native-image. If you go this route, prepare to spend half your time with the build tool itself, and be prepared for "oh the language technically works with this, but not if I use library x" type disappointments right and left.
The best, most painless route is to go with a language which has thought about the end result of the build pipeline beforehand. Rust and Go are gold standard for this. If I want a Python that is statically compiled, I reach for Go.
So to hear that the language made a bunch of tiny little design decisions up and down the line with the idea of making static executables from the start is, from this DevOps engineer, incredibly compelling.
Sorry, but you truly need to re-educate yourself on how excellent native compilation supporting infrastructure like GraalVM is. So many HN folks have some decade-old view of old programming language and tools without trying anything out for themselves. And get stuck in a "bias bubble".
It takes ~2minutes TOTAL to download, install and compile Graal VM against Java sources to produce a ~11MB debug build native binary. Utterly painless and even measured. You can reduce that considerably further to ~4MB by seeing what modules contribute to the size using the Graal VM dashboard https://www.graalvm.org/dashboard/ and choosing to omit them with a flag.
Frankly, I found it easier to work with than your Rust+Go standard as I can easily see exactly which modules contribute to binary bloat-up and choose alternatives.
There are also excellent, first-class frameworks built from the ground up for Java native compilation like https://quarkus.io/.
I'm sure it's easier with Java, and I apologize for not being clearer. I have recent, unpleasant experience with Clojure, not java. That said, I would still be (pleasantly!) surprised to hear of someone using a sqlite java library and having it work without a hitch on native-image.
Sadly, another baseless assumption. I just downloaded sqlite java driver from https://github.com/xerial/sqlite-jdbc/. And compiled their sample program on the home page (creates db with table and some rows) to native code. I did all this within ~2min after reading your response.
Its very, very hip nowadays to worship Rust/Go and bash Java and gain HN karma from the younger generation while doing so, but at-least do it on real facts and not assumptions.
javac Sample.java && native-image -cp .:sqlite-jdbc-3.41.2.1.jar Sample
./sample
name = leo
id = 1
name = yui
id = 2
ls -al sample.db
-rw-r--r-- 1 OMIT OMIT 8192 Apr 1 22:22 sample.db
My Python isn't very good so I'm not familiar with your cxFreeze/pyOxidizer/pyInstaller list, but couldn't you just develop your python using one of these tools from the start?
Bare Python is mostly useless. People use Python because of the libraries. The kinds of projects that are developed in Python all, save the most trivial ones, rely on stuff that's not written in Python.
For instance, if you do ML, then you use NumPy, Scikit-Learn etc. It's all C / C++ code, which you will have to link with somehow. And even if you figure out how to link with it, your program will still suck because of the unnecessary (as I call it) PyObject layer, i.e. the Python interpreter interface that is used for communicating between Python libraries. Eg. say you wanted to pass a pointer from one library to another. If you were writing in C -- no big deal, just have some externally visible function in one library and call it in another, and you are done. But if you want to connect two Python libraries, at best, you'll have to use a special struct PyCapsule, with two dozens or so of fields, which is allocated by Python's allocator and also needs to be deallocated... The overhead will be tremendous.
Similarly, if you do Web development, you need some HTTP server that can run fast. I haven't touched this part of Python in a long time, but the last thing I came to use was Tornado, which was a C library with Python bindings.
When it comes to infra, there are plenty of tools that are also written in C, various database drivers, Kafka client, encryption library... and so on.
---
Bottom line, even if you defeat the system and manage to make it all compile together... it won't work well, not as well as it could have if only you could ditch Python entirely from this equation. And if you could, then... well... you'd be just writing in C...
Reading through your comment history, it seems like you are on a personal crusade against Python, but your arguments boil down to this:
"Python is a shit language because it doesn't do/have [insert a niche thing that you think a language should do]"
Which is failing to grasp the role Python plays. You can make this sort of argument against any language, and generally you would be correct in the fact that languages can be improved.
But the fact remains that Python is widely used, and no, its not because people are dumber than you and don't know better, its because they simply dgaf about any of the niche cases you talk about.
For example, nobody is going to look at Numpy and realize its C, and ask the question of "Hmm, I wonder why Im using Python in the first place if its really just C under the hood".
Not to mention that the practice of patching Python libraries through C like you describe pretty much never happens. Not to mention that core ML isn't even the standard C, its open cl or CUDA C which are specialized, and how you get to defining those kernels is largely irrelevant for functional sake, but largely relevant in how efficient and simple it is, which is why Python is used.
For all your other issues across comments (like venv, pip dependency), you seem to assume that when someone runs into the issue, it somehow causes everything to break and things to fail. None of what you describe really plays out in reality on a large scale. Things work because people are smart enough to realize what they are doing. It could be that you personally have issues with your company, which is the source of your frustration, but I can assure you that is not the case across all of industry. Google, despite its many issues, has built plenty of good things using Python, and defaulting to C/C++/Go when they need to.
Google, despite its many issues, has built plenty of good things using Python, and defaulting to C/C++/Go when they need to. When you start building better things than Google in other languages and prove that the thing is better because of the language choice, then you will have a point.
In your reply to my other comment, you said
"But, even, imagine that in your fairy-tale world Python is somehow so super-important and successful? Didn't I already explain how this is possible while still being a garbage language?"
This is the equivalent of you just standing in the middle of the busy street with a sign that says "everyone is on a path to hell with your choices in life, you must repent and follow Jesus". You are entitled to your opinion, but I hope you realize that you aren't making any real points.
That's a very strange post that doesn't sound like it's coming from a professional programmer. "Do everything in C" really misses the value of using a glue language. Furthermore you overlook the cost of python as glue, which can be relatively quite low under the right circumstances. Everything is a trade-off.
For a script with a few dependencies, pyInstaller isn't too bad. I love Python, but it's an interpreted language first and foremost. Distributing Python code is never easy, no matter what you throw at it. Things that are supposed to "just work" almost never work when you need them to on someone else's machine.
Sure you can, but last I tried (admitedly a good long while ago) the exe included everything except that fucking Visual Studio DLL that everything requires.
Native image has been getting better, with the Graal project recently making it much easier to get builds working on Windows. So it’s getting to be quite painless, so that I think it’s already worth it for people already familiar with Clojure.
But if you’re looking specifically to write small tools distributed as native binaries, Janet sounds like a much better choice.
I will be most interested when this gets easier, in particular if it works with sqlite and the unzip libraries. Those libraries are the major snags. I could not get it running on windows (the repo in question[1]).
In theory you "can" do that with python too.
"Can" is a very different kettle of fish from "most people are inclined to".