Why Janet? (opens in new tab)

They only seem obvious to you because you are used to them.

Quite the opposite to you, Rust is obvious to me because I'm used to low-level programming and careful memory management, where JS is more than often very surprising.

Another example: I wrote a Lisp-like language in my company for mathematicians to develop constraint systems; now this purely functional, bastard Lisp feels like a second nature to them, whereas they could barely put three lines of Java together to save their lives.

Does not mean that I'm more or less right than you are; just that just like human languages, no PL or paradigms are ‶naturally obvious″, we are just more or less used to them.

How does the quote go again, someone can learn Lisp in a week, except if they know C then it will take three weeks? I'm sure I've got the quote completely wrong (maybe it was about Forth?), but the essence is there: if you're learning a programming language it may take longer if you're already used to a programming language with different semantics compared to getting into it from scratch.

Also Raku is the most obvious language because it inherited the "it" variable ($_) from Perl, and "it" is unbeatable for writing obvious code (read a line, uppercase it, replace all numbers in it with dollar signs, and print it out again).

That's very subjective. Of the languages you mention JavaScript, C++ and Zig are not obvious to me at all – I usually find myself on Stackoverflow looking for answers when trying to write even the simplest things in them.

Janet on the other hand felt instantly familiar after reading the language introduction. It has all the usual imperative constructs from C-family languages – for, while, if – but also extremely expressive macros like `loop` and `as->` that are more common in the world of lisps, and `partial`/`comp` from the functional paradigm. For such a small language Janet really covers a lot of bases.

Functions/macros are often called exactly what I expected them to be, which has allowed me to figure out how to do most things by simply guessing in the REPL. If I need to figure out the details I can use the `doc` function (or Ctrl-g in REPL), and the docs work perfectly even for what would be keywords in non-lisp languages. It has been a really pleasant experience that I haven't really had with other languages, aside from maybe Julia which also has very intuitive syntax and function naming conventions.

I used to work at a US EMR company, not as a programmer though. They use a terrible language called M or MUMPS. New hires would spend their first month or so literally in a classroom with an instructor and homework to learn the language (and other company specific things).

Now I'm not recommending you use an unusual language, but I think most companies don't spend enough time on boarding new hires and expecting professional development happen on the employees time.

If I am going to use a tool every day for a couple years I want the best tool, not the easiest tool to learn how to use.

Functional programming it's quite obvious, actually: there's data, there's transformations, there's data again. Sometimes there's side effects. Doesn't math work that way? I'm no expert on it, but the key for me was understanding that usually, in functional languages, you actually write _less_ functions, and most of the application behavior is expressed through static data.

I remember the first time I encountered a C-like for loop, and felt as a most alien thing: until this day I still feel it's an unnatural construct, a third of it abstracted from the application logic, the other two halves low-level requisites. And of course, watching that classic video of Rich Hickey destroying Java's HTTPServletRequest class just once made it clear, at least for me, that OOP's stance to redefine every data input and output into its own understanding of the universe isn't the obvious approach at all.

> Python, javascript, they’re not perfect but they’re pretty obvious.

It’s really strange to call JavaScript obvious… strange implicit conversions, broken equality operator, strange variable scoping… I still have no clear idea what the `this` keyword does in the majority of circumstances…

That depends on what you are used to.

I was mostly used to C and Perl when I was young, and Python made a lot of sense.

I would not say that javascript was more obvious to me than rust was when I started to use them.

A lot of people seem to be hung up on borrow checker, but if you are used to low level C, you had to keep track of that with comments on functions and conventions anyway (and you had to keep it in your head).

The thing that I had to get used the most of in rust is using more functional style of programming, but since I liked python comprehensions and collections, It want such a long jump as it otherwise might be.

Does someone with no programming experience at all say the same?

Have also seen cases where people with background in Physics, Mathematics found functional programming more obvious. Obvious is relative.

Even for people with programming experience - once I got hang of Haskell, learning and using Scala professionally became more "obvious" for me.

There's probably a distinction to be made between being obvious and having no surprises. I agree Python is relatively obvious, and I write a lot of small python scripts for data analysis because if I can figure out what I want to do, doing it in python is usually very simple. But for larger programs I care less about obvious, and more about no unpleasant surprises. Once the amount of code grows larger than I can hold in my head at once, I really want the language to help me avoid footguns. Python mostly isn't great for this due to its type system (with a few exceptions such as its big integer support avoiding most integer overflow surprises).

It probably isn't a popular opinion, but I actually think C++ does a fairly good job of this, so long as you're disciplined in how you use it. That discipline is not necessarily obvious, but I've acquired it over 30+ years, and now I find that I almost never have memory safety issues (I do use sanitisers here, but they rarely show up anything). Perhaps more importantly, C++'s fairly strong typing means I'm generally pretty confident refactoring code as requirements change without getting unpleasant surprises. Sure, C++ could do better in many ways, but it is pretty good at avoiding many of the unpleasant surprises I care about, at least for single-threaded code.

Pattern matching and referential transparency are much more "obvious" or "natural" (meaning closer to the way we humans think) than javascript and its idiosyncrasies (think that even something like `x = x+1` in imperative languages is an infamous tripping point for beginners). C++ is definitely anything but obvious.

obvious is too subjective here, what is not obvious in FP ? is it the terminology ? or the accumulated culture (monads and such) ? because FP at its core is pretty much very obvious. Functions from domain to domain, that's it.

I somewhat agree with this, note that Janet is not very functional, when I briefly used it I never used a single recursive function. It's meant to be used more in an imperative way.

For you Janet is obvious or non obvious?

I find it interesting to compare Janet to Guile Scheme because they both claim to be fit as embed-able scripting languages.

Haven't done any practical comparison yet bc Janet has only caught my eye recently (;p), but it appears to have a culture of vendoring and an edge in implementation size and complexity which (ideally) enable diving into the language's implementation to scratch your own itches, learn how it (and the stack in general) work more throughly, and allow eg. low level code optimizations with less FFI boilerplate.

I wonder how executable size and performance pan out, but with C FFI available in each language (and the reality of how much time optimization is worth), I feel that comforts matter more.

Color me intrigued!

I mean, let's be real: if you have SBCL and QuickLisp most newer S-expression based languages don't have much to offer.

I’m on the verge of trying Racket to write my own DSLs. I wonder if Janet is better for this task?

Lisps and nil have a symbiotic relationship, not an adversarial one.

They are an everyday falsy value that you program _with_ not around. Nil doesn't signal that you forgot to initialize a value. It simply means stuff like "I don't have this" or "no more". You don't check for it at every corner like an anxious squirrel, but pass it around freely, knowing that your code knows, accommodates and embraces nils.

Option types are inherently a bad idea for languages without value semantics. In rust, the Some variant of an option type can just be allocated on the stack at almost no cost, but doing this here would require a million small allocations every time you want to return something. Beyond that, it makes no sense to have union types when every value is already a union of all possible types.

I love option types, but I don't think they make a lot of sense in dynamically typed languages.

Option types are from ML, not rust. ML predates rust by about 40+ years.

Rust did not invent Option types.

I would say from Boost C++ or from C++ std. Rust came far later.

Racket is a great choice for learning but also very batteries included if you want to make real projects in it.

Janet has a more Clojure-inspired syntax but the semantics and general ideas should carry over. I think trying to work through the books in Janet would be a great extra challenge. You can always drop that and focus on Racket if it becomes it too much for you.

Why not try doing the exercises in Janet? It gives you the end-product goal so you don't have to waste energy on ideation, but having to figure out syntactic differences and compatible standard library functions and macros yourself really helps you understand a language top-to-bottom and is arguably the best way to learn. The way I learn languages all the time is to translate exercises on sites like HackerRank or exercism along with toy projects I already have.

I haven't used Janet but there were some notes in the author's ebook (https://janet.guide/) that suggested it had some small but key differences with a more "traditional" Lisp that might trip you up or at least cause friction. I'd suggest using Racket for those books.

With a little bit of effort you can make it work. But I believe Racket has specific language definitions for some of these books so you can follow them more or less seamlessly.

dont overwhelm yourself. use the language the book was designed for

common lisp also has some really great books, beginner and advanced. paip is probably the most famous of these

Are you familiar with Lua? How about Fennel?

because Janet is a lisp-1, this should be very doable.

Agreed. What is perfectly fine in a blog post can get tiresome in long form. It is not the question pre-empting structure, which is great in my opinion, but avuncular lines like "Okay wow; we’re just diving right in huh".

Yeah... he says you can learn the language in an afternoon, but his book is so long-winded... I just want a short intro so that I can start writing programs.

+1 I find it hard not to read that sort of writing style as condescending.

I'm writing go in my dayjob right now, and my reaction was "hey under a megabyte for a runtime with GC is pretty good!"

So I checked just now, and my hello world for go was 1.9M. And you're well within your rights to just declare "the fact that go is even worse doesn't make Janet good" but let's be honest - plenty of people have accepted go's compromises, so something coming in at better than half the size is relatively much better.

edit: out of curiosity i used gcc to make hello worlds in C and C++, which came in at 32k and 37k respectively.

What are you comparing the size to?

I think Lua is in the same range, so this seems reasonable (but obviously much larger than anything without an included runtime).

That doesn't seem that bad to me for a Lisp.

Common Lisp / SBCL equivalent for me is 41MB.

Clojure überjar size for the same is 4.6MB.

There is a cost to having so much language ("all the language, all the time") available at different stages of the program lifecycle (macroexpand, compile, runtime, ...). Not sure if a Janet program can run eval, but it still has a garbage collector, etc.

Even a Go equivalent is 1.9MB.

Most of the need for hygienic macros goes away if you have a compiler (or macro expander) that warns about shadowing.

Code has to go out of its way to do something silly, like reference a variable which it does not define; and by coincidence this has to be defined by a macro that is used in the same scope (so that it simultaneously evades unbound variable and shadowing diagnosis).

Hygienic macros do not solve accidental name capture in code that contains no macros. Manually written code can contain a mistake of reference due to variable shadowing, creating a bug.

Kind of. Passing around extra context in order to resolve the symbol in the right environment does fix the problem, but it's hard to argue with unqoting the symbol as the better fix. Embed the function foo in the macro instead of the symbol foo and information on how to turn that symbol into the function later.

I can really feel the author’s excitement in every sentence. Reading his work is great fun, and really does make me want to use Janet

His writing for janet.guide grated me a bit at first, but the guide was good, and then I found myself laughing along. I already liked Janet, but that guide got me back into it. This guide is just confirmation bias for me, but I'll read it because I (now) like the author.

I looked into Shen recently. I ultimately decided not to use it because their remote compilation model thing seemed... cludgey.

I've since landed on Gerbil Scheme (https://cons.io) which is a modern front-end to Gambit Scheme. It seems like the perfect mix of performance, (modern) features, R*RS, and FFI that I want/need. Baring some significant bugs, it will probably be my goto Lisp going forward.

The last time I look at shen it was a complete waste of time, it was like a cooking recipe with all spices combined and then find out the food is still part frozen. Let alone no way to build programs or having 8MB of js programs etc.

Does Janet have a language server yet? That would go a long way, but last time I checked it did not

Oh, thats.. certainly not encouraging.. Because other than that, Janet seems interesting. Well.. Maybe one day, we will have good emacs integration, I guess?

If you count raylib as a GUI, yes!

https://github.com/tantona/janetroids/blob/master/main.janet

Mm, I don't think it makes a lot of sense to compare Janet and Racket. They're so different that they aren't really bidding for the same projects -- you could ask the same question about Janet and Python, or Janet and Ruby, or Janet and Erlang. They aren't really substitutes for one another -- a comparison with Lua or Tcl makes more sense. That said, I think the original article serves as a decent starting point -- how many of the listed points apply to Racket?

Same, but I'm not sure if it's enough to pick it up.

in case your comments get flagged and removed, i just want you to know someone appreciated your humor. Technically speaking though, humor is not allowed on hacker news, it's litterally in the TOS....and I only know that from many flags of my own.

Hmm, maybe?

https://janet.guide/janet-for-mortals.epub

That's a super hacky epub that I just generated from the markdown source and have not read over thoroughly. Formatting is a bit different, and code blocks have no labels, which are occasionally significant... but from a quick glance it looks pretty close.

Also https://janet.guide/all has the full text of the book, which you could save to HTML and convert to an epub with pandoc (or print to a PDF). Not sure if the results would be better or worse.

Yes! With spork/netrepl and Conjure in Neovim

https://janet-lang.org/api/spork/netrepl.html

https://github.com/Olical/conjure

And me!