What some people seems to forget is that doing something simple is simple in every lang with any framework.
Can we have a sample with allowed hosts, cors, auth, input validation, open api docs, request logging with true IP addresses, XSRF/CSRF attack protection and so on?
> Can we have a sample with allowed hosts, cors, auth, input validation, open api docs, request logging with true IP addresses, XSRF/CSRF attack protection and so on?
It is pretty much industry standard within the C# and Java community to provide Open API docs. It also displays the flaws of the API designs at an early stage. Stops one from going live with something embarrassingly bad as the Hashicorp API:s for instance.
I had not pushed a project public in a while and recently had to kick something off and I hadn't been testing fully to get things into open space. CORS/CSRF and really getting my head back in the space of SSL being properly handled took me way longer than I'm comfortable to admit. These are things that I consider myself fairly comfortable with but chops had atrophied and browser enforcement leaves less wiggle room for failure. Also static file management really tapped me in my nuts.
It's really easy to think you've got it all figured out when it's just running on your local machine or a private network or to quote Mike Tyson "Everyone has a plan until they get punched in the mouth."
This experience has reinforced for me how critical getting CI/CD is to the process of taking something from a sketch pad to something that no only ships but other people can work on. Not saying that has to be a huge production, but it's just as crucial as how to post a form or connect to a data source. Looking at you JS bros that think they can cobble together an ORM that won't be a massive chore.
Most of what you're asking for is described in the docs, with examples. If you're looking for an example project using Joy, I think janetdocs[0] may be a good example. Some Janet experience may be good before diving into that repo, because it imports Joy with `:prefix ""`.
Also keep in mind that 99% of this seems[1] to have been made by 1 guy (Sean Walker), I think in his free time.
PS: I did a very minor contribution to Joy once, so minor that I actually forgot about it :) I don't use Joy myself at the moment as I'm using my own framework, but the Joy docs + source code helped me out a lot in figuring out how to do authentication, csrf, etc!
Why would someone use Joy on Janet over Reitit & Ring on top of Clojure?
I see Janet is small and embeddable. Does that mean faster startup time than a full JVM? It's nice that most of Janes the literals match Clojure, so aside from `def` inside a function (as opposed to `let`), it's natural for a Clojure user to read.
Maybe they don't want to tie themselves with the JVM, or have no experience with the Java ecosystem? Janet seems like a much simpler ecosystem. Also, for fun would be a great reason :P
I don't really care about startup time personally but the linked page mentions "very low memory usage" which is quite a contrast with Clojure which seems to use insane amounts of memory for simple things.
Do you have a reference for Clojure's 'insane amounts of memory' use?
Our product (https://kpow.io) is written in vanilla Clojure/Clojurescript, it will quite happily run with a 64MB heap for smaller workloads.
64Mb for a non-trivial full-stack enterprise-grade application with authentication enabled providing a rich UI and multiple asynchronous and/or scheduled background processes that monitor and manage Kafka resources. Sure we don't recommend running multi-cluster production workloads on a 64MB heap, but requiring further memory for real workloads has nothing to do with Clojure and we're a long way from 'insane' memory use, or doing simple things.
I wrote janetdocs with joy and it's been running for quite a while on a pretty small VPS. htop shows RES memory usage as ~16MB and SHR as ~6MB, so it's anecdotal, but there's at least one data point.
I'm not saying it is using a low amount of memory, but I just fired up a new Clojure repl and it seems to end up using 90MiB memory once up and running. Is that what you'd call "insane amounts of memory"?
Maybe spending too much time in JavaScript-land has jaded my view of memory consumption.
Janet, for comparison to that 90MiB will use something more like 16MiB. Using less than 20% of the overall memory footprint does make Clojure seem insane by comparison.
I was surprised to discover that Janet tuples and records (the immutable array and hashmap you've mentioned) aren't the Clojure-style immutable which is designed for cheap updates, but the more usual kind of immutable where if you want a copy with changed data, you have to make a copy with changed data.
Makes a lot of sense. Babashka will be faster than Clojure as well.
Where Clojure shines, is long-running processes. Try the same benchmark, but instead printing "hello world" 1000000x times and compare it, and you'll have a benchmark showing Clojure's strength rather than weakness.
In the end, benchmarks usually show what the author(s) wanted to show with the benchmark.
Hiccup syntax for HTML is such a joy to use. It maps perfectly onto HTML, it is a breeze to write, and I haven't encountered anything yet that it can't express. It is one of my favorite parts of Lisp.
I'm curious about and interested in janet, definitely keeping an eye on it. The author's last language, fennel, is very very impressive to me as a project.
Its strict adherence to lua's runtime semantics repulses lisp nerds like me at first. But after actually using it in some heavy lua projects, it's incredible how clearly the author understood the practical day-to-day problems with lua and air-dropped in a solution to only and exactly those. It doesn't introduce any extra complexity, perf, or debugging concerns; it runs on any version of lua with no compromises. There are endless lisp purity quagmires to get bogged down in and it completely avoids every single one of them. From a language design standpoint I really think it's an incredible achievement.
I've never used janet and don't particularly have a reason to right now. But who knows maybe I'll find an excuse soon.
> There are endless lisp purity quagmires to get bogged down in and it completely avoids every single one of them
Which is odd, because purity has never been a defining characteristic of the Lisp family of languages. It's somewhat analogous to the disputes over what is and isn't a rogue-like game. It's more a matter of spirit than any particular feature. Although there are features that the overwhelming majority of Lisps have, like a syntax that is pretty much directly is a tree representation of the AST (modulo reader macros if available). Of course the very first Lisp is an exception thanks to M-expressions!
I wouldn't say it's that odd - Purity is one of the largest defining differences between Scheme and Common Lisp. To the point where the Lisp family of languages can be defined by whether it takes after one or the other by its level of purity.
I didn’t mean purity in the functional programming sense. Rather, I was using the general English sense of strictly adhering to some ideal. I claim that there is no such thing as the Lispiest Lisp.
This is great timing. I just started learning Janet yesterday. I look forward to working with this framework.
On a related note, I like the use of katakana in the name of the framework, but シoy would be pronounced "shi-oy." It should be ジoy, which would be closer (ji-oy).
I've spent a fair amount over the last few years experimenting with CL, Clojure, Gerbil, and Racket for web development. I really enjoy all of them but I always inevitably find problems that I can't really overlook and end up sticking to python or go.
I'll give this a try soon, it looks promising. Hopefully it hits a sweet spot!
Wll, with CL, Gerbil and Racket I understand coming across road blockers (for me this means, missing libraries)
But for Clojure, this doesn't add up, Clojure is either hosted on the JVM or Javascript, how can you not find the library you need on one or the other ?
the programming language is janet, which looks like a lisp at a cursory glance.
why might I choose this stack with janet for a web app versus, say, Common Lisp? For instance https://lispcookbook.github.io/cl-cookbook/web.html
Honestly, the easiest to approach for me was Racket's out of the box web libraries. I just never took it further than that. I've dabbled with Clojure was well with lein and luminous web framework. I just am so undecided on what Lisp I want to use for a web project. I'm so spoiled by things like Django and ASP .NET Core. I really do want to do something with Lisp beyond just simple hello world web projects just because web development is something I do often enough in my career so it makes sense to jump straight into it, but I'm not sure. Of course if I went for Common Lisp which compiler do I even go for? I liked Racket a lot because it was easy to get into due to DrRacket. I liked Clojure because it had two simple editors that are now defunct, so I'm kind of left wondering what to use if I go that route.
You mentioned Net Core, so I wanted to share this.
I started a project using Giraffe recently and love it. It’s an F# web framework that runs as a middleware in a AspNetCore app. I found F# to give me a lot of nice functional features, while also leveraging all the Dotnet ecosystem and CLR knowledge gained from my day job.
I mean why use anything for anything, since another thing already exists.
Look I like common lisp just fine and have used it for serious professional work and value it for its practical strength and longevity.
It is gnarly though, and a pain in the ass sometimes, and really pretty hard to onboard people into. It's huge, and the intense focus on backwards compatibility means there are huge swathes of the language you won't use, some that possible no one should use. If you've already put the time in to learn all that then yeah sure why would you use this. But most people interested in lisps haven't spent hundreds of hours trudging through common lisp already, so maybe this is more for them.
Is there a "common lisp - the good parts" style thing that a decent percentage of users agree on?
(I've done scheme and a few others with great enjoyment and repeatedly bounced off common lisp, so I'm very much aware of the extent to which "lisp users agreeing on things" is a substantial ask, but it seemed worth a try even so ;)
> I mean why use anything for anything, since another thing already exists.
My question was to figure out WHY this might be better than the solutions that already exist, which I think is a fair question. If you're always going after the new thing without it having known / expected advantages, aren't you setting yourself up for pain?
Back in the day, I wrote a lot of Web applications in Chicken Scheme. Some are still running today, although they are harder to maintain now (bitrot, eroding skills on my part, etc.). I enjoyed the experience, though there was a lot of rolling-your-own to get to a finished solution. Maybe that has changed in the past 15-ish years...
Writing web applications with Lisp is a joy, so this is aptly named.
I wrote one app with Uncommon Web framework on Common Lisp around 2009, with it you could similarly render the HTML from Lisp functions, and use continuations for multi part form submissions.
I have also used Fennel recently, and if Janet is anything as good, I'll try Joy on my next suitable project!
My one fear with a lisp-based framework would be code-injection stuff, unless janet has some way of freezing the source in production. You could do a lot of damage if you suddenly realize you can inject code via a request payload on some server running a lisp-based framework.
Unless the code you've written uses eval and passes user-provided data to the eval function, there's no way to inject code. JavaScript also has an eval function that and code injection is not a worry at run-time for Node projects unless they're using eval() as well.
Joy is beautiful to work with in that it's _just_ enough. The scaffolding is great, the CLI is handy, and the API is very agreeable. Joy is (almost) enough incentive to start a project with Janet (like Rails for Ruby) even if I didn't have other plans to do so. Janet is also very nice as an aside, I just personally don't care for lisps syntactically.
It looks like janet supports great interop with c, so in theory it isn't much of a stretch to connect to other databases. I had the same question and came across this: https://github.com/newhook/janet-mysql
I know this is probably not for PROD but its a lot of fun to look at a nice clean database driver. I've been working with mysql off and on for ~13 years and never have really looked at the source of a client.
Can we have a sample with allowed hosts, cors, auth, input validation, open api docs, request logging with true IP addresses, XSRF/CSRF attack protection and so on?