Comment by nerdponx | Hacker News Reader

Comment by nerdponx | Hacker News Reader

One obvious point I'm missing here, and that I've been missing from Janet discussion in general: why Janet and not Scheme?

Gauche for example implements the latest (and IMO greatest) R7RS, its standard library is huge and "batteries-included" including a wide array of RFCs to the point of rivaling Python, and has a package manager in the form of Akku. Chicken has a similar story. Racket is arguably more useful "out of the box", but its community seems so heavily focused on using it for PL research that it's harder to justify using it for day-to-day programming. And there's Clojure as well, which I know comparatively less about, but is well-loved by its users.

Heck, even Common Lisp has a lot going for it, but the Standard and the conventional Lisp dev tools are kind of chaotic and idiosyncratic enough that it's understandable if people don't want to use it.

To be clear, Janet seems like a great little language. But as someone with limited time and energy who is interested in using it, I want to know why I should spend the time learning it, compared to Scheme

Janet has close integration with C going both ways. It has built in C ffi and you can easily build and distribute a janet binary that uses C libraries.

It's also easily embeddable in C programs the same way lua is, making it possible to use it as a config, extension, or scripting language in a larger program.

Aside from that having used it a fair bit I think it's got a very "practical" orientation. It provides immutable structures, but doesn't enforce immutability semantics the way clojure does. It has a good concurrency system but is cleanly single-threaded and performant by default. And imo the standard lib is a really good balance, neither forcing you to build EVERYTHING yourself (lua) or having the whole last 50 years of CS research in it (racket).

> is cleanly single-threaded

And here I immediately lost my interest. Anything that cannot do real concurrency is a toy in my book. There's no excuse for a language developed for practical computers in 21'st century to not be able to utilize concurrency which is practically built into every existing computer.

Maybe you should reread that sentence bc I don't think it says what you think it says.

Then it's a good thing those words were preceded by:

> It has a good concurrency system

It has none. When code isn't executed concurrently, that's not concurrency. There's idiotic fashion to call unrelated things "concurrency", but it's the same as calling various soy drinks "milk". It just adds confusion for no reason. This language has zero concurrency. It has some mechanism to randomly / unpredictably execute bits of different functions in succession: this is worthless, but has nothing to do with concurrency.

I think you're using concurrency in a non-traditional sense https://stackoverflow.com/questions/1050222/what-is-the-diff... and I also think you're being a little bit uncharitable

Really? You are going to quote StackOverflow for an expert opinion? Why should anyone care about what that site users have to say? "Concurrent" means that something happens at the same time. It's that easy. The use of the word you refer to is a marketing trick used to bait you and switch the products before you pay. It's used by people who want to justify the existence of a worthless tool by pretending it has something to do with the one you really want. Very similar to "vegan cheese", which is really not a cheese in any way, but it's sold to you labeled as "cheese" because you wanted cheese, not ground cashew nuts.

You're wrong on all points :-)

Vegan cheese is not named this way to trick you, it's for vegans who want something functionally similar to cheese. Same goes for oat milk and the likes, they're used _like_ milk, in coffee, etc.

Concurrency can mean doing several things that are interleaved, even if they're not literally running on multiple cores. Otherwise, you literally couldn't have concurrent network connections because the NIC only sends one packet at a time. Similarly, fibers, promises, etc. are valid implementations of concurrency as they're running different, unrelated strands of logic in an interleaved fashion.

I'm not a vegan, so the vegan "cheese" isn't named like this to trick me. It's named like this to trick vegans.

Apart from that, there are organizations that act on behalf and to protect consumers' rights. Some of that goes against false advertisement. This is why, for example, products that aren't meant for children or puppies aren't allowed to have children or puppies on the packaging, or the reason why it would be illegal for different products to have packaging that inflates the perceived amount of good that you buy by essentially, selling you air. This is also the reason that in many countries vegan "cheese" is not allowed to be called "cheese" in advertisements on on the packaging. Same goes for vegan "milk" and similar products.

It doesn't have to be about vegan products, it was just a convenient example. In some countries "crab" sticks are only allowed to be called that if they actually contain some crustacean meat. Or products aren't allowed to be called "juice" if they have less than a certain % of actual juice in them and so on.

"Concurrency" in languages like Janet is exactly the same thing. It is false advertisement. You pay with the lost ability to debug and to predict code execution path for nothing, whereas that would've been the price you might have wanted to pay for executing code concurrently. That's swindling. Most likely unintentional in the case of the people working on Janet, but for you, as a user, it makes little difference.

You misread the sentence. Janet supports full parallel execution on multiple CPU cores using native operating system threads, while using clean and fast single-threaded data structures by default on each thread.

I don't think Janet and Scheme have very much in common. If you're looking for a huge, batteries-included language, you will not have a good time with Janet :)

Janet is much closer to Lua, in scope and applications, than it is to any Scheme or Common Lisp or Clojure implementations.

r5rs is significantly smaller than Janet.

This was the last good Scheme.

it seems to me that gebril scheme fits janet's use cases

https://cons.io/

Janet has a lot in common with Lua: tables, coroutines, easy embedding, lots of API similarities. Compared to a language like Lua, Janet is bursting with "batteries". Almost to a Ruby level where whenever you think to do something, you check the docs and find yourself saying "of course there's a function for that". I have to disagree completely with your assessment.

Scheme feels really verbose to me. I get that it's 'minimal' and 'elegant' and everything, but then why are all the identifiers so long? I feel like I have to do a lot of typing to get anything done. Maybe it's better if you're using emacs and have good lispy autocomplete, I don't know. But broadly, it makes me feel like the people who developed scheme were working from a very specific definition of 'elegant', and it doesn't align with mine. Janet feels better for that.

Janet users are not encumbered with the historical cruft of scheme like hiding libraries behind unmenorable srfi numbers, or the ancient an un-portable oop implementations etc etc

This should be studied a bit. At what point a partial reboot benefits the community/language before.

Reply on news.ycombinator.com