I think it would be a great programming language if it arrives 5~10 years earlier. Highlights to me are: green thread, TCO, easy distribution, great interop with C, flexibility of choosing between imperative vs immutable data structures.

However, I just couldn't find a good use case for it. For embedded programming, I would always choose Lua if not using Zig/Rust directly. For low latency backend stuff, I can use Clojure or NodeJS, which are much more performant and mature (Janet's performance is roughly on the same level with Lua without JIT).

For general latency insensitive backend projects, there are just too many choices nowadays and Janet doesn't shine enough.

If it arrives 10 years ago with these feature sets, I would love it!

We have been making great progress in terms of features since then to "flesh out" the languages and libraries including threading support, an event loop, and some basic networking (socket) support built in to the runtime. Generally though, the PL design space is already incredibly fatigued an most new languages claiming something have already been made a few times over, just doing doing one thing slightly better, so it is true we cannot truly compete in that space.

Janet is a hobby lisp(?) taken too far and I have been adding lots of features that I find useful for day-to-day programming and experiments while still being something "embed-able" into another project. Janet is not a corporate project in anyway and donations are accepted mostly as a token of gratitude and expenses used to maintain the website and CI bills. My goal is really just to make it a good, clean, useful language for my own use and not as some kind of advertisement or product for anything, it is a project I started in my college dorm and have continued working on as a passion project since.

I am aware that there are already libraries that cover these to an extent like circlet and halo for http. Joy also features an http client. Maybe it's outside the scope of the project, but I think an http server and client as part of the core would really add to the utility of Janet. It would also answer some of the licensing questions for distribution if these were included directly in Janet core. For example, circlet is MIT, but it is based on mongoose is GPLv2.

Also, seeing Janet on HN a year or so ago was what got me to watch The Good Place, so thanks for that as well.

But yes, at some point a canonical replacement for circlet that was MIT licensed and event-loop friendly would be nice.

Lua is extremely lightweight and portable. The interpreter doesn't exceed 500 kb in the fattest build, and the used dialect is a strict subset of ANSI C that is equally comfortable running on mainframes as on Nintendo consoles.

In short : If it has a C compiler and can spare 300 kb ram, it can run Lua. So people sometimes use it there.

After a career in embedded software, I'd have to say that I've only worked on a couple of products that had less oomph than a high-end PC of the same era.

Depending on the context, "embedded systems" go even larger, although usually people stop calling it "embedded programming" at some point. Obviously many problems in large embedded systems are different from small ones, but others remain similar.

What's probably different today is that you have more options also on MCUs (not just assembly and maybe C), because MCUs have grown.

I like the language, except I have never liked the “low parenthesis” Common Lisp loop/for macros, which Janet’s “for” loop reminds me of. Pardon the stylistic nit-pick.

As an aside, Cosmopolitan is news to me, but looks quite nifty.

Edit:maybe my comment was too short, but for me it is important to know what problem a new language solves (better). And I seriously think the landing page does not explain it well/at all. I mean like: D is C++ done right with garbage collection (and of course expand from there). Zig and Rust are safe languages and aim to replace C (with different strategies). And of course more than one sentence.

So if anybody knows what problem Janet lang solves, pls enlighten me.

But I'd say the biggest draw for me now is that Janet has a lot made a lot of choices I agree with.

It's language that boots up very quickly, makes for easy building of CLI tools, compiles to statically linked executables, has full compile-time metaprogramming (Lisp style), and can interface with C libraries very easily.

It doesn't solve any particular novel problem better outside of PEGs, but it makes a lot of the right decisions. And, being a Lisp-like, it also gives enough expressive power to help you build things your way, if you want.

Most of that probably appeals to folks who a) have been programming for a while b) don't hate parens c) Are ok forging in untread territory

Janet isn't something I'd build a business on, not quite yet, but it has been a very, very satisfying hobby, and I've written a lot of small tools in it, more than Nim or Go during my times with either of those.

What would you say needs to change about Janet or its ecosystem to make it business-proof?

For context, I've found and/or helped fix bugs around multi-char string split, process termination on windows, and async IO on Windows. All things that forced me to pop the hood on the language, study relevant OS APIs, and generally yak shave, rather than focus on the task at hand. Which has been really edifying, but would have slowed me down if I was writing for a job.

In the process, I've written a few libraries of my own for things like string manipulation, data schemata, rendering html forms/tables based on a schema, and so on.

If you have people that are competent with C, then Janet atop that could work well, but by itself, it's still a long ways from having all of the things one might expect from Python/Ruby, let alone Java or .NET

> Janet makes a good system scripting language, or a language to embed in other programs. Think Lua or Guile. Janet also can be used for rapid prototyping, dynamic systems, and other domains where dynamic languages shine.

I could see the sections reordered, but it's hard to really fault this home page, it's pretty terse yet quite complete.

The biggest issue I have with it is the first-time reader is hit by the community / contribution bits before even knowing what the language is about. A two-columns layout would probably be useful there. And while having a basic in-page repl is nice, improving the discoverability of the language through it (e.g. providing autocompletion and inline help) would be neat.

[0] https://github.com/bakpakin/Fennel

I mean this landing page is/should be their 2 minutes sales pitch.

Some people simply enjoy computers and are not looking for external validation.

Spin up your jvm/.net bloatware and code yet another CRUD application and leave us alone.

Zig is a nice improvement over C, but it is not safe.

There is work in progress (https://github.com/ziglang/zig/issues/2301), but from what I can tell, key details are still to be decided, including the classes of errors that will be covered, whether they will require runtime tracking, etc.

In my opinion, Zig should look into becoming UB-less -- listing undefined behavior instances like the C standard does or enabling safety only in some build modes is not enough.

When comparing to non-lisps 1. It has a real REPL, so you can do live coding (this is what makes me choose it over many languages at the same "level", js, lua, python, java). Honestly, this feature alone makes or breaks languages for me. 2. It is easy to interact with C (I found this hard in js, haven't tried the other)

Comparing to lisps (I've only properly tried guile & clojure) 1. Easy to build on windows / macos / linux (compared to guile which I didn't manage to build on windows) 2. Compared to clojure, just closer to the machine overall, in my case specifically OpenGL libs. I love Clojure but have had a hard time making client side apps with it. Done a bunch of CLJS stuff (e.g. card game https://animal-capital.surge.sh/), but many little things get annoying (e.g. can't open my editor from a browser error, can't `eval` etc. Doesn't quite have the live coding feel).

1. Decent support from the language to do REPLy things

E.g. being able to change a function during runtime. Imagine an animation which is defined by perhaps: `(defn anim [time v] (* time v))`. Now you want to try something else, without having to recreate all state, so you just do `(defn anim [time v] (* time v v))` and hit Ctrl+L ("load file"). Oh, it seems I need to reset the animation, so I add some code to reset just the part of the state needed. Now I'm able to hit Ctrl+L and it'll run the new animation each time. The ability to do this ad-hoc anywhere in my code is so flow-inducing it's crazy. And I do this for games, web servers and browser GUIs. It's surprisingly general!

2. Editor support

The Ctrl+L I mentioned above is something I do in my editor to send code from my editor to the repl server. I haven't tried Ipython, but I'm guessing it might work similarly to node, where the client and server are kind of stuck together. With a "real repl", you generally use your editor as the client. Here's a video I've made that shows how this can look: https://youtu.be/Enumt6qxAgc?t=667

I know it's often possible to disconnect these (I've tried connecting my editor to the chrome debugger -- that's pretty cool!), but it doesn't seem to be in common use, which leads to...

3. Libraries supporting being run from REPLs

One not-so-uncommon problem is that e.g. a web server or game loop might block the REPL. This one is probably the hardest one to fix for existing languages and their libraries. There are often ways around this, like running on multiple threads, but that can lead to new problems. Even in clojure, I've had problems due to java libraries blocking (e.g. game lib LWJGL). It doesn't help that on macos all GUI related calls must be done on the main thread (so running LWJGL on one thread and repl on other breaks things). So far with janet I've managed to solve these issues easily thanks to the event loop (which iiuc works similar to js event loop).

---

I think the main thing to realize is that this way of developing leads to new possibilities of exploring software development. Suddenly you're able to experiment quicker, in a way that sometimes leads to typing speed being a bottleneck! :D It feels really cool, and I want to share this feeling of flow with as many as possible.

If you get a chance to watch the videos it might give you some extra ideas on how to enhance your vscode + ipython experience, or maybe you can find issues with what I'm doing and tell me how to do it better. :D

It's also not dogmatic. You can use mutable and immutable versions of the same data structure.

Docs are concise: https://janet-lang.org/docs/index.html

Full API is here: https://janet-lang.org/api/index.html

[edit] I fully agree that "getting started" on Clojure is easier than used to be. Anyway I still think there is room for improvement.

- click here[0]

- click on SSO provider

More information here[1]. Of course, it'd be better to just use the Calva plugin with VSCode. That's a bit more than 2 clicks, maybe about 5.

On another hand, I don't mean to say that it's easy to start programming on Clojure, merely that it's now easy to try it out. There's a steeper learning curve than python or JavaScript, specially on the tooling side.

[0] https://gitpod.io/#https://github.com/PEZ/get-started-with-c...

[1] https://calva.io/get-started-with-clojure/

However from their description and the complexity promises it looks like the immutable collections are literally just the mutable ones without mutation ability (similar to Java's immutable* wrappers) which greatly limits their effective usefulness.

> Full API is here: https://janet-lang.org/api/index.html

Sadly even worse than clojure's which is already not great.

I thought Clojure's immutable collections were generally considered good. What else would you consider "great"?

Edit: or was that a complaint about the quality of the documentation, not the quality of the immutable collections?

Yes, sorry if that wasn't clear.

I think, however, that scala raised the bar with RRB trees over the trie-based immutable vectors. And using java strings is pretty sad...

Interesting

Why?

And what’s the alternative implementation?

I can absolutely understand not using them if the implementation is intended to be simple or the systems it's running on is resource limited, but simply removing the mutation bits of mutable collections is quite limiting as it incurs large overhead when actually working with them (you have to copy the entire thing every time you want to update anything).

Unless the collections are always kept quite small: modern architectures are very good at dense arrays, so modern immutable data structures are trees of small-ish arrays (usually a small number of dozens, IIRC Clojure uses 32-wide nodes).

Working with Janet has deepened my knowledge of the Win32 APIs, for example, because it makes writing small bits of C for interacting with them about as easy as that can be.

I also like how it makes data structures and functions look the same in terms of access, and how it handles nil.

Submitting one file at at time doesn't trigger it.

Even packing up all the binaries and submitting that doesn't trigger is (and neither does packing up the rest of the files abd submitting them.)

So I'm going to ignore MS on this one since no one else found anything suspicious either.

https://ibb.co/dQpKT3T

I wonder if there is someone here from either Microsoft or Virustotal who could do something about it?

I wonder how many users these sort of languages have, aside from its creators and perhaps the company where it has been born. There are tons of embedded languages, many with libraries and all sort of utilities, why should someone invest themselves in such languages with all the risk it takes?

Problems such as: additional build steps, security, ecosystem, train employees and maintainers into new languages, additional maintenance barrier, etc

18:52

https://en.wikipedia.org/wiki/Gaston_Julia

(I jest. Three times, in fact.)

[1] https://en.wikipedia.org/wiki/Telephone_exchange

[2] https://en.wikipedia.org/wiki/Cryptanalysis_of_the_Enigma

(don't ask me how reliable that source is)

But it does not change the point. People who created Ada believed that Ada Lovelice was the first programmer and named the language after her. So it's not named after "somebody's girlfriend". The fact that they were probably mistaken does not change this. It she was brilliant anyway, even if not the first programmer.

    * JOSS    - male   - 1966
    * Pascal  - male   - 1970
    * Ada     - female - 1983
    * Perl    - both   - 1988
    * Haskell - male   - 1990
    * Lua     - female - 1993
    * Ruby    - female - 1995
    * Delphi  - female - 1995
    * Julia   - female - 2011

Some caveats apply. Many language names are also surnames, I leave that to future work.

See also: Beryllium

Perl: doesn't strike me as a name at all, and the language name definitely wasn't referencing it (more likely a reference to the shell).

Lua: doesn't strike me as a name either, and the language was named for the moon.

Ruby: is a girl's name, but the language was named for the precious stone.

Delphi: is the name of a city, though it does reference the (female) Oracle of Delphi (the language was designed to make Oracle databases accessible).

Telling their wife that it means 'moon' in Portuguese made it an easy sell.

And no, no problem with me. I just pointed out one reason why people might prefer a female name for a project.

Another valid reason might be because they want to bring some women into the spotlight in what is ofte perceived as a male dominated field.