Janet's purported focus is that it's easy to embed in a larger C program. I haven't really seen that in practice, but I have used the C api to write some language extensions, and it is a joy. In comparison with Clojure, I much prefer using either C or janet to using Java and lisp side by side; with Clojure running on multiple hosts now the differences in language semantics between clj and cljs are just annoying.
As far as language features, I miss a lot from clojure: immutable/persistent data structures, protocols, not to mention concurrency primitives. But Janet's approach to performance and design is "do less". With the C api you can easily add bindings to some C library that provides a desired feature. But even without that stuff, Janet is for me a python-killer, if not a clojure killer.
Edit: at any rate, I think it's not meant to be a competitor to Clojure, its similar syntax just often invites the comparison. It's much more fair to compare it to Lua.
> Janet's purported focus is that it's easy to embed in a larger C program.
There is Guile https://www.gnu.org/software/guile/ that is an implementation of Schema with the focus on being an extension language that integrates with C and C++. Wouldn't it more practical to adopt and contribute to it, rather than invent an own wheel?
Firstly, this is a rather silly argument in general. One could say that Embeddable Common Lisp and Guile address the same niche and all developers from one project should consolidate in the other.
I have not used Guile to any extent, nor was Janet really influenced by it, but the comparison has been brought to my attention several times in the past. Janet is not scheme nor common lisp, so there are of course many differences that I cannot address here. However, as an extension languages, there are several things that I believe Janet does better than Guile.
Guile is not an ideal extension language for C projects (this is distinct from an extension language for GNU projects). Firstly, they address garbage collection with the Boehm GC, which takes some control over your runtime and is not known for great performance (the runtime/non standard C is the bigger issue). This was of course a decision made by Guile devs to make it easier to write correct bindings to C libraries in Guile, but it is not without it's downsides. Secondly, the project is not easy to embed in foreign build systems. Janet is more like Lua - built in tracing GC that is not conservative nor platform specific, no external dependencies beyond libc, and can be added to a project as an amalgamation (a single C file and 2 header files). This has enabled people to get Janet running more easily on a variety of platforms like mobile phones and even recently someone has been doing some work on getting Janet running on the Nintendo Switch. I believe Janet is also significantly smaller than even the smallest build of guile. Basically, Guile is not simple, which is (IMO) antithetical to an ideal extension language.
At the same time, Janet should feel like a much less minimal language compared to Lua. While core Lua limits itself to pretty much only standard C, Janet goes a little further to provide some abstractions over different platforms (that can be turned off via compile time options).
Thank you for elaborating on the reasons to create Janet!
My argument can sound silly, particularly considering the fact that you do not have any obligations to justify your project that you opened for others. I am very thankful to open source contributors, but I have a feeling that many open source languages, frameworks, libraries, and desktop environments would be more popular, polished, and maintained, if we could compromise, tolerate, and control our ego or creativity, and contribute to existing projects.
I think, we can see the benefits of focus and discipline by comparing Rails and its gem ecosystem with “blossoming thousand flowers” of Node.js web frameworks.
I'm in no way associated with Janet, so I can't answer for them. But as someone who is implementing their own language which shares a lot of goals with Guile, the reason I didn't contribute to Guile is that Guile is an implementation of the Scheme Standard, and it bound at least loosely to that. Certain modern features just aren't compatible and might not be accepted if you go through the effort of implementing them. There are real benefits to implementing a standard, and I'm not criticizing Guile for doing that--I use Guile. But if your goals aren't compatible with the standard you have no choice but to go a different way.
Guile is more than a Scheme implementation. You can implement a completely new language for it (somebody recently did Python) and reuse their embedding capabilities. Guile comes with an Ecmascript implementation, just to show that it can be done.
You can do that in most (all?) Scheme implementations. Macros are powerful, yo.
This goes back to another discussion here: just because you've implemented a language doesn't mean you've implemented it well. Sure, I can implement all the syntax of what I want. But is it fast? Does it report errors well? Am I enforcing my type system, or can I accidentally drop back into normal Scheme?
I think a lot of times new Lispers learn macros and, drunk with their newfound power, start writing 20% implementations that get them 80% to mature languages. And if you don't need or want the other 20% of a mature language, then that's fine. But if you do need or want the other 20% of a mature language, then you'll quickly discover that the Pareto Principle[1] applies. Lisp metaprogramming can be super powerful, but it's not a magic bullet: not only does it not kill werewolves but you can shoot yourself in the foot with it.
As far as language features, I miss a lot from clojure: immutable/persistent data structures, protocols, not to mention concurrency primitives. But Janet's approach to performance and design is "do less". With the C api you can easily add bindings to some C library that provides a desired feature. But even without that stuff, Janet is for me a python-killer, if not a clojure killer.
Edit: at any rate, I think it's not meant to be a competitor to Clojure, its similar syntax just often invites the comparison. It's much more fair to compare it to Lua.