2. "Janet runs on Windows" as claimed by their website. Why not change to "Janet runs on Windows 8+" or whatever version is also not supported. I have lost several hours while figuring up this issue. How much time of other dudes have to be spent before somebody will write down this clarification on the webpage? All the Windows history tells me that backward compatibility is the killer feature of Windows.
3. Windows 7 is the last good version of Windows. Also there is a lot of computer equipment which is stuck to Windows 7, for example laptops with ATI videocard only which does not support any modern Linux because of xorg version, x32 machines, machines which are not supposed to be exposed to Internets any more, most laptops in second-hand etc. I do not think Windows 7 deserves to be forgotten right now.
Backwards compatibility generally means you can use programs made for older versions of Windows on newer versions of Windows.
What you want is the opposite of that: run a new program on an old version of Windows. Expecting that of all programs would mean no new OS feature or API could ever be used.
Generally staying on an old OS means you accept that you don't get to use newer programs.
https://github.com/LuaDist/srlua
The Lua runtime is 340kB on Windows and there's plenty of project including the one above made by the Lua maintainers to produce statically linked and dynamically linked binaries.
But it's Lua, so while I loved the language, you have to put up with the tiny list of standard features which can make it a grind.
As someone who's playing with Lua to run an incredibly lightweight HTTP server[1] which requires just a few MB on disk and 1MB of RAM (while supporting stuff like JSON, HTTPS, Sqlite DB, Email, MQTT and a lot more), I would be curious what you think are the problems with Lua.
But on a more serious note, I actually do care because I have around 4,500 packages installed on my system. If all of those were 100MB in size I'd have a problem.
With 50MB a piece that would be ~0.5TB. That is 50% of my system SSD.
Given that they have similar goals, why not merge and join efforts? Would help in softening the rough edges and reducing the bus factor.
on the other hand, i hear that commercial versions of common lisp can achieve better results. but seriously, is this such an issue for todays computers ? i have pdfs that are hundreds of mb
You're paying a higher initial capital cost for lower per-unit costs.
If you can distribute and run a trivial hello world program, you can expect to be able to distribute and run something like tail or uniq, and that it will be larger (more standard library portions linked) and slower (more actual work executed).
If I run `raco exe` on this, I get a 57MB file. On mac, it's only linking system libraries. (For Idris2 programs, there is an Idris support library that is dynamically loaded.)
I haven't tested transporting it to another system (my test was on an arm mac, so I don't have another system to test that on).
Cons:
- 200MiB archives
Pros:
- I can develop a GUI doing some stuff on proprietary binary files, extracting & converting data, generating a handful of plots in a couple of days and have all my colleagues enjoy it without any issue.
Then again I don't know much about the technical details here (when do you or don't you need your own runtime). It seems baffling to me with all the cruft and bloat in a modern windows install do you still have to install so many microsoft runtimes.
We just don't notice that typical C programs need libc and pthreads. Or that C++ programs on Windows require that cursed Microsoft Visual C++ Runime DLL which is always missing, but has few dozens of copies all over the system of the miserable Microsoft slave.
Go doesn't produce fully statically linked binaries by default. I used to make "from scratch" Go containers and, in general case, you need libc in them, unless you are willing to go through pain of statically linking with it.
Typical / practical Rust programs will also depend on libc and pthreads (but, sure, you can do w/o).
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.
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...
"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.
But if you’re looking specifically to write small tools distributed as native binaries, Janet sounds like a much better choice.
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/.
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.dbMy SBCL binaries are ±28MB, with the complete Lisp runtime and debugger (cool, I can eval and load configuration files or connect to a remote app) and dozens of dependencies, including a web server.
1: http://www.sbcl.org/manual/#Function-sb_002dext-save_002dlis...
anyone around knows how does it compare to Chicken?
If you want small binaries, then you'd want tree-shaking, not an entirely new language. LispWorks is already capable of producing small, graphical hello world examples. Even then, a hello world is a rather silly benchmark for binary size, especially since it totally ignores the fixed cost of a language runtime and no serious person is distributing a hello world.
- a terraform distro is 59M
- a kubectl distro is 44M
getting rust installed on a windows machine required not just a rust distro, but a visual c++ library set over 1G.
at a certain employer, the size of the teams golang tool was well over 100MB.
So - 50MB to start with a full Lisp image? yeah, sure, no worries.
I've heard that some scheme things will compile out to C even.
I'm sure I just missed it, but I haven't been able to find an answer to that question yet.
Edit: Probably pretty tiny based on this [0], right?
> The entire language (core library, interpreter, compiler, assembler, PEG) is less than 1MB.
Edit again: Found an example [1]:
> And the size is quite reasonable for a non systems language: the Pong example using Raylib is about 2.4MB on Mac OS Catalina.
> My favorite feature of Janet, though, is something that sounds really dumb when I say it out loud: 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. And they can run them without having to install any gems or set up any virtual environments or download any runtimes or anything else like that.
The space is ripe for a lisp that is easily distributable. Yes, common lisp can be statically compiled, but their binaries (at least with sbcl) can get pretty big [1], even with compression. Making a lisp specifically good at using to make CLI or desktop tools with good c ffi support is compelling.
1: https://blog.djha.skin/blog/50mb-for-hello-world/