You can write Haskell in the Racket environment[0].

Racket has a lot of well-designed and well-documented libraries that are a joy to work with. In his Racket manifesto Mathias Felleisen (author of The Little Schemer) describes how Racket is supposed to be useful for programmers at any level.

I'm currently working on a web app using the Datalog[1] back end. I guess that's very similar to Clojure's Datomic or core.logic, and I'm not sure which is "best", but Racket is certainly good.

[0]: https://lexi-lambda.github.io/blog/2017/05/27/realizing-hack...

[1]: https://docs.racket-lang.org/datalog/interop.html

> Why should a company use it over Clojure?

Not wanting to support the JVM ecosystem.

I'll add wanting to avoid any legal risk from its owner, who is very sue happy. They also got that copywritable, API ruling in one battle. I just stay away from anything Oracle owns. Using open standards future-proofs against this a lot.

I think racket would be a good choice for internal company tools. It’s batteries included philosophy allows you to create very complex apps with minimal effort.

Racket is significantly more expressive than clojure in many different ways (nice gui tools, very sophisticated macro system, good IDE)

I wouldn’t want to use racket for applications that would have thousands or millions of concurrent users. For programming in the large, clojure wins by a long shot.

> I wouldn’t want to use racket for applications that would have thousands or millions of concurrent users. For programming in the large, clojure wins by a long shot.

Can you explain why?

Because it's been used more in big prod envs? Or for reason intrinsic to the languages themselves? If the latter, which ones?

This is a bit funny to post in hacker news which was written in arc, a language built on Racket and serves large numbers of people.

Indeed, and Arc has some brilliant ideas, but if you ever tried to hack in it, you'd experience how dog slow it really is. But Arc's web framework is implemented in somewhat low level MzScheme and is entirely different (and much slower) than web apps in Racket's[0].

Part of what makes Hacker News fast is that the page only has 4-ish images (if you count the invisible gif that is used for indentation) and a tiny amount of JS.

[0]: https://docs.racket-lang.org/continue/

Yeah, but that's sort of the point: for most web applications, most performance issues are not the result of the implementation language but of the chosen architecture. If a fairly inefficient language like Arc can handle HN loads (for the most part, at least), almost anything can.

> for most web applications, most performance issues are not the result of the implementation language but of the chosen architecture.

I don't think that's true (but I also don't understand what is meant by architecture in this context).

There's a simple file upload form example in the Arc community repository. It's so slow that it would timeout on files smaller than 100K. I tried optimizing the POST request parsing, but could still only barely get Arc to handle file sizes of 5M.

Tried making a similar simple file upload form in Racket, and it runs way faster. But it shouldn't be surprising that some languages are less efficient than others, right?

I'm also not sure that most web applications are text-only. Many web applications send and receive other things that plaintext.

> But it shouldn't be surprising that some languages are less efficient than others, right?

A long time ago I read a comment somewhere saying that Arc is interpreted (as in by a program itself written in MzScheme, instead of translated down to MzScheme), which struck me as odd but I didn't check back then, so now I finally went and looked through the Arc history[1] and release 0 already does the translation, so apparently that was just wrong. There can still be reasons why Arc could be slower, though, I remember PG's design called for overloading function calls so that e.g. hash table lookups could be written like function calls, and if implemented naively this could cost a slower than usual type check on each function call and prevent optimizations applied by the MzScheme/Racket compiler like perhaps function inlining. But just a different parsing infrastructure could explain it too (working on strings-as-vectors vs. lazy lists would make a large difference, but I couldn't get down far enough to see how that's implemented; srv.arc in parse-multipart-args uses regular expressions, not sure that's what you optimized?). Anyway, new code always has large potentials for optimization (early lisps were very slow, today's implementations are generally very fast; same was/is true for Java, JavaScript, ..).

[1] http://github.com/arclanguage/anarki

clojure has incredibly strong story for leveraging host platform ( jvm/js ) ecosystem

I think Racket is by far the better language. But the tools you have on the JVM are unparalleled. Racket's GC is not the greatest and the number of options you have to tune it are very limited. The JVM is very flexible and allows you to tune your application through a multitude of parameters.

simply because of battle-tested jvm.

The JVM?

What about the battle-tested Linux kernel? If you compile your racket apps to a native binary, you can run it directly on the Linux kernel, and benefit from 25 years of use in production! People deploy Golang and Rustlang apps everyday in prod using that approach it seems to work well for them. Note, both languages are younger than Racket.

Compiled Racket programs are nowhere near the speed of Rust or Go. Racket's GC is objectively much much worse than the JVM.

Of course you can serve millions of users with Racket, like HN. But the JVM today is much better choice. The JVM's GC is world-class and the number of man-hours put in it is probably many orders of magnitudes more than that of Racket's.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

So execution speed, fair enough.

FWIW, I've been staying away from Clojure because of the JVM. A lot of us are wearing the scars of the JVM battles!

If you need performance and want to avoid the jvm, there are also lisps like Chez Scheme and various Common Lisp implementations (sbcl, in particular, can produce really well-tuned numerical code).

... which is why Racket-on-Chez[0] is a really exciting development.

[0]: https://blog.racket-lang.org/2018/01/racket-on-chez-status.h...

"Keep in mind that the original goal is not to have a faster Racket, but a better-implemented Racket with acceptable performance."

racket compiled binaries are not "native", they are bytecodes jitted during runtime, and jvm's jit is highly performant.

Oh, so like python. Explains the poor performance. I did not know that. thanks.

As a broad approximation from the results of The Computer Language Benchmarks Game, Racket is 5 times faster than Python and 5 times slower than C. https://benchmarksgame-team.pages.debian.net/benchmarksgame/... (I can't find a direct comparison of Python-vs-Racket in the site.)

The difference with Python is probably bigger in programs with a big numeric part, and much smaller in programs with a lot of string. Take that number just as a general guide, not as a precise scaling factor.

> I can't find a direct comparison of Python-vs-Racket in the site

Now you will.

Why is not everything-vs-everything available?

Racket vs Python is a "common" comparison. I write the same comment once or twice per year :). (Probably because both are high level and have the batteries included. (The syntax is slightly different :) ))

1) Everything-vs-everything is available, here —

https://salsa.debian.org/benchmarksgame-team/benchmarksgame/...

2) People show interest in just a few comparisons (much much fewer than are currently shown).

3a) Everything-vs-everything is available, here —

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

3b) Everything-vs-everything is available, here —

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

no, python isn't jitted.