4 ms·

What made it not a practical competitor to CL before for you? Racket has a nice runtime (much nicer than what you get with CL, though with some downsides (eg.

What made it not a practical competitor to CL before for you? Racket has a nice runtime (much nicer than what you get with CL, though with some downsides (eg. memory usage is higher in Racket)), a large standard library, a comparable number of packages (~1800 on pkgs.racket-lang.org versus ~2100 on quicklisp), good editor support and a pretty great distribution story (via `raco exe`, `raco distribute` and the relatively-new `raco cross` for cross-compilation). All things that make it very practical in my book.

sph 5y ago
Last I checked it was pretty slow, performance and use in production was not its main focus. I'd like that, I absolutely adore this language.
- Bogdanp 5y ago
  > Last I checked it was pretty slow I agree it is slower than the fastest CL implementations, depending on what you test, because some of the features present in the language make optimizations harder. The compiler is definitely also slow. As far as dynamic languages go, however, Racket is very fast in general and you can push it very far. > use in production was not its main focus. What makes you say this/what do you think it's missing as far as "use in production" goes? Instrumentation? Something else? I've deployed both production web apps and desktop apps with Racket, and the experience has been as good or better than other languages I've deployed similar things in.
- Decabytes 5y ago
  Racket is definitely slower than Common Lisp. But it is one of the fastest Schemes on the market currently^1. But it also has the ability to create static executables, runs on M1 macs, has a statically typed sister language, a build in package manager, and gui library. And it's faster than other dynamically typed languages like Python when looking at pure implementations (not written in C). So there are still a lot of reasons to use it over Common Lisp if any of those things appeal to you 1.https://ecraven.github.io/r7rs-benchmarks/ https://ecraven.github.io/r7rs-benchmarks/
the-smug-one 5y ago
Racket is slow which impacts the entire dev cycle, has even less use of ad-hoc polymorphism than CL (very annoying to have to use the monomorphic functions all the time), editor support isn't great (SLIME still contends well here, the speed is an issue here too), and the package story is a bit more difficult to get familiar with. Not as interactive in dev as CL, because safety. Cool arrows in Dr.Racket though, nice macro system, and so on.
- Bogdanp 5y ago
  I agree that Racket development is less interactive than CL development partly because of the slower compile times and partly because of the way the editors choose to reload modules on change. Nothing inherent prevents fast reloading[1], though, and Racket development is still plenty interactive[2]. I would say the package story is more complicated in CL as a consumer of packages. As a package creator, they're similarly complex. [1]: https://www.youtube.com/watch?v=wWj7OPvXGgA https://www.youtube.com/watch?v=wWj7OPvXGgA [2]: https://www.youtube.com/watch?v=7uGJJmjcxzY&t=495s https://www.youtube.com/watch?v=7uGJJmjcxzY&t=495s

sph 5y ago

Last I checked it was pretty slow, performance and use in production was not its main focus. I'd like that, I absolutely adore this language.

Bogdanp 5y ago
> Last I checked it was pretty slow I agree it is slower than the fastest CL implementations, depending on what you test, because some of the features present in the language make optimizations harder. The compiler is definitely also slow. As far as dynamic languages go, however, Racket is very fast in general and you can push it very far. > use in production was not its main focus. What makes you say this/what do you think it's missing as far as "use in production" goes? Instrumentation? Something else? I've deployed both production web apps and desktop apps with Racket, and the experience has been as good or better than other languages I've deployed similar things in.
Decabytes 5y ago
Racket is definitely slower than Common Lisp. But it is one of the fastest Schemes on the market currently^1. But it also has the ability to create static executables, runs on M1 macs, has a statically typed sister language, a build in package manager, and gui library. And it's faster than other dynamically typed languages like Python when looking at pure implementations (not written in C). So there are still a lot of reasons to use it over Common Lisp if any of those things appeal to you 1.https://ecraven.github.io/r7rs-benchmarks/ https://ecraven.github.io/r7rs-benchmarks/

the-smug-one 5y ago

Racket is slow which impacts the entire dev cycle, has even less use of ad-hoc polymorphism than CL (very annoying to have to use the monomorphic functions all the time), editor support isn't great (SLIME still contends well here, the speed is an issue here too), and the package story is a bit more difficult to get familiar with. Not as interactive in dev as CL, because safety. Cool arrows in Dr.Racket though, nice macro system, and so on.

Bogdanp 5y ago
I agree that Racket development is less interactive than CL development partly because of the slower compile times and partly because of the way the editors choose to reload modules on change. Nothing inherent prevents fast reloading[1], though, and Racket development is still plenty interactive[2]. I would say the package story is more complicated in CL as a consumer of packages. As a package creator, they're similarly complex. [1]: https://www.youtube.com/watch?v=wWj7OPvXGgA https://www.youtube.com/watch?v=wWj7OPvXGgA [2]: https://www.youtube.com/watch?v=7uGJJmjcxzY&t=495s https://www.youtube.com/watch?v=7uGJJmjcxzY&t=495s