8 ms·
My question for why Janet was answered: > My favorite feature of Janet, though, is something that sounds really dumb when I say it out loud: you can actually d
by djha-skin 4y ago
My question for why Janet was answered:
> 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/ https://blog.djha.skin/blog/50mb-for-hello-world/
- iansinnott 4y agoI wonder if Jank [1] could be such a Lisp? I haven't played around with it, but I really like the idea and would love to see it get more traction. [1]: https://jank-lang.org/ https://jank-lang.org/
- miroljub 4y agoUnless jank rebrands itself as NativeClojure retaining 100% Clojure compatibility with a few more native related goodies, I don't see it offering more than Janet, which is also inspired by Clojure. Given that they have similar goals, why not merge and join efforts? Would help in softening the rough edges and reducing the bus factor.
- cellularmitosis 4y agoLooks like the key difference is that jank is based on persistent data structures, while Janet embraces mutability.
- smegsicle 4y ago'jank' is a good name then- janky immutable structures sounds flexible and fast, while janky mutable structures sounds like a big mucky headache
- medo-bear 4y ago50mb for a hello world in common lisp is a bit misleading. its 50mbs for a hello world + an entire interactive common lisp runtime you can use to further extend the application. if you write 2x hello world it aint gonna be 100mb lol 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
- zdragnar 4y agoWhy would I want a 50mb hello world?
- thomascgalvin 4y agoWhy would you want a hello world at all? That isn't a realistic distribution scenario.
- HelloNurse 4y agoA simple "Hello World" is a realistic test scenario, representative of a large class of plain command line tools and approximately reduced to pure overhead. 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).
- deleted 4y ago[deleted]
- thechao 4y agoWhy do you want hello world, at all? Yes, the nearly-null program is 50MB; also, yes, a fairly nontrivial program is ... 60MB? The core for a computer algebra system is 100MB? You're paying a higher initial capital cost for lower per-unit costs.
- EggsAndOil 4y ago
- freilanzer 4y agoWho cares about these sizes though? I know I don't and nobody I know would either. 100Mb are downloaded in roughly 6 seconds with my connection at home.
- Malcx 4y agoYou forgot the /s right? Most of the world doesn't have that kind of connection.
- eru 4y agoYes, some of us have faster internet. (Assuming freilanzer talked about megabits, not megabytes.)
- freilanzer 4y agoI don't see how this is a huge problem. You don't need to download the executable once per minute.
- tmtvl 4y agoExactly, and loading stuff into memory is free, everyone has an SSD, and RAM and L1 cache are exactly as fast as each other \s. 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.
- krinkatt 4y agoSearching *.exe in Everyting and select all -> 12 779 objects. With 50MB a piece that would be ~0.5TB. That is 50% of my system SSD.
- sebstefan 4y agoI used to do that in Lua https://github.com/LuaDist/srlua https://github.com/LuaDist/srlua The Lua runtime is 340kB on Windows and there's plenty of projects including the one above (srlua is 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.
- brabel 4y agoThe project you linked to has been archived. Are you sure they are still maintaining it? 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. [1] http://barracudaserver.com/ba/doc/ http://barracudaserver.com/ba/doc/
- ianthehenry 4y agoI think Janet is an excellent choice for making redistributable CLI apps. Chapter 12 covers a bit of this, including the implementation of an extremely simple fzf-powered todo list: https://janet.guide/scripting/ https://janet.guide/scripting/
- eimrine 4y agoBut not if a support of Windows 7 in a CLI app is important.
- dylan604 4y agoin 2023, why would it be? we're talking creating something new in a newish language. we're not talking about supporting legacy code on a deprecated OS
- eimrine 4y ago1. Windows 7 share is 5% of all Windowses right now, that means that a number of Windows 7 machines is more than a number of all Linux ones. That's not an answer to question "why to support 7" but an important note. 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, also most laptops in second-hand has 7 by default and it still just works. I do not think Windows 7 deserves to be forgotten right now.
- ahtihn 4y ago> All the Windows history tells me that backward compatibility is the killer feature of Windows. 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.
- leoc 4y agoI think it's fair to say that that sentence almost screams "this is my adoption strategy". And fair enough, of course.
- ianthehenry 4y agoI am not the author of the Janet programming language, just a user who likes it enough to write a book about it. That is my real favorite feature, not a strategy of any kind :)
- andrewflnr 4y agoRacket can supposedly compile standalone packages with the raco compile command (IIRC). Does anyone have experience with this?
- butt____hugger 4y agoThey aren't standalone executables, they need to be distributed along with the lib folder that includes the racket runtime.
- nsm 4y agoDoesn't raco make followed by raco exe produce fully standalone (except libc) executables? I believe some platforms need an additional raco distribute step.
- andrewflnr 4y agoOh, raco exe is probably what I was thinking of.
- sschwarzer 4y agoAt least in some cases, you need the options --orig-exe (Posix) or --embed-dlls (Windows) to make the binary standalone. For me that worked for command line programs. The options are described at https://docs.racket-lang.org/raco/exe.html https://docs.racket-lang.org/raco/exe.html . You can use both options at the same time, regardless of running Posix or Windows.
- psychphysic 4y agoMaybe I'm being too simplistic but this should be a characteristic of the implementation and not the language? 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.
- weavie 4y agoThe difficulty with a lot of dynamic languages is that it is very difficult to determine at compile time what parts of the runtime are not going to be invoked so you largely end up having to include the entire platform in the executable.
- crabbone 4y agoI really struggle to think about a language that doesn't usually need a runtime. Some can produce binaries that don't need a runtime, but usually you need to jump through hoops to make that happen. 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).
- tpoacher 4y ago> 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".
- djha-skin 4y agoNah, you really can't. 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.
- _a_a_a_ 4y agoMy 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?
- cjohnson318 4y agoFor 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.
- JohnMakin 4y agocan't you compile C into statically linked binaries?
- vindarel 4y ago> common lisp can be statically compiled, but their binaries (at least with sbcl) can get pretty big [1], even with compression. My 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.
- djha-skin 4y agoI could get it down to 10 with the `:compression` option on[1] for hello world. Perhaps this is the option you use? The compression didn't hurt the run time much as I recall. It's the reason why I'm still okay with common lisp for this use case. 1: http://www.sbcl.org/manual/#Function-sb_002dext-save_002dlisp_002dand_002ddie http://www.sbcl.org/manual/#Function-sb_002dext-save_002dlis...
- vindarel 4y agoabsolutely, I use SBCL compression (following this recipe: https://lispcookbook.github.io/cl-cookbook/scripting.html#building-a-smaller-binary-with-sbcls-core-compression https://lispcookbook.github.io/cl-cookbook/scripting.html#bu... that boils down to save-lisp-and-die ultimately). Start-up times are still below the 50ms for me.
- zem 4y agochicken scheme can do this too, for what it's worth
- muyuu 4y agochicken scheme comes to mind anyone around knows how does it compare to Chicken?
- koito17 4y agoThe binaries are big because it's shipping a preprended lisp kernel together with the entire programming language in a heap image. It's also largely dependent on the Common Lisp implementation. SBCL is very inline happy and consequently consumes more memory than other Lisp implementations. A fresh CCL image consumes at most 8 MB on my Mac. 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.
- pnathan 4y ago- a helm 3 distro is 45M - 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.
- schemescape 4y agoHow big is an executable compiled from Janet using jpm? 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. [0] https://janet-lang.org/ https://janet-lang.org/ [1] https://github.com/phillvancejr/Cpp-Go-Zig-Odin https://github.com/phillvancejr/Cpp-Go-Zig-Odin
- ianthehenry 4y agoI just compiled a hello world and got 784k on aarch64 macOS with all the defaults.