
Racket 6.0: New package system, new doc CSS, JIT support for ARM - racketlang
http://blog.racket-lang.org/2014/02/racket-v60.html
======
pavpanchekha
I'm using Racket for a major project right now. It's been hit and miss. On the
one hand, Racket is by far the best alternative/non-mainstream language—the
docs are good, there are surprisingly broad libraries, and of course it's
great to support the good people at Northeastern.

On the other hand, there is evidence here and there that this language isn't
commonly used in production. For example, the pattern-matcher is very well-
implemented and feature-full, but there's no way to use it programmatically
nor is there a way to get the set of bindings. There is also the sad fact that
Racket is a Scheme in the traditional Scheme fashion, and so is still trapped
in an 80s design aesthetic. Generics are poor, ADTs aren't easily implemented,
static types exist but are not so widely used and have strangenesses.

~~~
noelwelsh
"no way to use it programmatically nor is there a way to get the set of
bindings"

These don't really make sense in the context of Racket. Pattern matching is a
macro and thus doesn't exist at run time, though of course with eval the
distinction between run time and expansion time is not so well defined.
Accessing the lexical environment is not something you do in Racket -- it
breaks optimisations and is generally considered a bad idea.

------
Oculus
Racket is my first functional language and its been fun, but is it more of an
educational language or is it used in production?

~~~
m0nastic
We're using it in production at my job. (In a decent-sized polyglot system
also made up of Haskell and Clojure).

There aren't as many libraries available compared to more popular languages,
but I haven't yet had too much trouble getting things accomplished. For the
above-mentioned languages we're using, I'd put the useful library situation
at: Racket-> Haskell-> Clojure in order of least to greatest.

Depending on what you need it to interoperate with, it's totally usable in
production environments as it stands.

~~~
oskarth
How come you are using all three of those languages in production rather than
just one of them?

~~~
m0nastic
I'm using different languages for different parts of the system.

While I could probably do everything in one language, I'm not sold on the idea
that that's actually a good idea (aside from developer convenience, which
considering I'm the only developer I don't rate very highly). I also don't
feel qualified enough as a language person to really hold defensible opinions
about their relative strengths and weaknesses yet.

For example, part of the system is a network service that runs deployed on
servers in our environment. All that code is Haskell. I didn't want to have to
deploy and manage an interpreter or JVM on those systems, and I don't trust
myself to write C that I feel confident deploying in production. Haskell
seemed like a good win there (other folks might use Go, or whatever). It
turned out to be really easy to write a network server in Haskell that
receives the messages that the service needs to receive. Also, it was the
first time I used a language that had good (or really, any) pattern matching,
and I'm sold on it.

The "business" logic of the system is all currently in Racket. It could
certainly have been written in Haskell, but I'm still getting up to speed in
it, whereas I was able to get pretty minimal functionality up and running with
Racket very easily.

Right now only the web interface is Clojure. I briefly considered using Yesod
for the web piece, but it seemed really complicated. And although Racket has a
nice web server, it requires buying into the "continuations" style that they
advocate (or rolling your own web libraries, which seemed like a bad idea for
this project).

I think the continuation-based approach for web servers is certainly valid,
and maybe even technically better, but they're swimming against the tide with
that approach, and as web programming is so far my least favorite part of
building this system, I wasn't willing to buy into that enterprise.

Thankfully, I was able to get a Clojure web app up and running very quickly
(basically just Ring and Compojure).

The system is designed where there's pretty hard boundaries between all the
parts, so by the time all is said and done, it might all be written in the
same language; but that's not necessarily a design-goal. I figure different
languages seem to have different strengths, and there's not really a good
reason for me to try and shoehorn everything into one.

~~~
biscarch
If you want to try out Haskell for web development again one day ping me
(email in profile) and I'll send you a copy of Snap for Beginners[1]. I'm
releasing it at the end of the week and it should make getting started in web
dev with Haskell easier.

[1] [http://snapforbeginners.com/](http://snapforbeginners.com/)

~~~
m0nastic
Yeah, I pre-ordered your book, I look forward to reading it.

When I originally looked at using Yesod, it seemed fairly complicated for what
I needed (which is basically just the crud-iest of crud apps). I'd only been
using Haskell for a couple of months, and I'd never done any web programming;
so I figured I should try to use something that wouldn't require quite so much
"stuff".

I finally decided to try out Clojure because I'm planning on using Datomic for
the main datastore (because it looks like I can have it backed by Cassandra,
which lets me store all of our data in an HDFS cluster.) and the "Web
Programming with Clojure" book just came out. I figured I could probably
figure out a very basic database-driven view web app just by going through the
book. That turned out to be true, actually, and it wasn't that hard to get my
app up and running.

What dawned on me going through the book was that what seemed complicated to
me really wasn't a function of the language, but the way almost all mvc web
libraries seem to be laid out; and that actually once I understood how they
worked, I could probably implement the same thing very similarly in almost any
language that has a similar library.

So I might eventually look into making a REST api using Snap to handle the
requests, and sort of encapsulating all input and output in the system with
Haskell.

------
derengel
Just want to make note that DrRacket has the best integrated REPL of all the
lisps around, its highly underestimated.

~~~
bhrgunatha
Have you tried SLIME? I'm wondering why you put DrRacket above SLIME.

~~~
laichzeit0
Is SLIME any better than Geiser? I've been using it with Racket and it's
pretty good.

[http://www.nongnu.org/geiser/](http://www.nongnu.org/geiser/)

~~~
pavelludiq
Geiser is great, but SLIME is much better mostly because Common Lisp was
designed with interactive programming in mind(the condition system, the object
system, dynamic variables ect. are all features that help with interactive
programming). You get an almost smalltaskesque feeling with slime.

------
gexla
Is Racket good for learning Lisp/Scheme or is it better to start with
something else?

~~~
brudgers
If you are interested in learning a LISP, then Racket makes a lot of sense. It
is actively being developed and extended and because of its roots in academia
extensions tend to be address interesting problems- many arise out of computer
science research by professors and grad students.

On the other hand, if you want to learn Scheme by working through SICP, then I
would recommend MIT Scheme to avoid impedance. There's not much benefit from
using the Racket ecosystem for that. Likewise, if the goal is to work through
_On LISP_ then a common Lisp implementation makes sense.

Of course there's no reason not to have all those languages installed..or at
least that's what I tell myself.

My last advice is that Racket is an ecosystem. It provides many languages
including Algol and Datalog and Scribble and Typed Racket. This makes for a
lot of documentation and it is uneven. The guide will be too shallow and the
reference will be more boilerplate rather than providing deeper explanation
and further examples.

~~~
Crito
It has admittedly been several years, but I distinctly remember MIT Scheme
being an utter pain in the ass to get built. I'd recommend Racket for people
just getting off the ground for that reason alone.

~~~
_delirium
GNU does provide binaries for some systems: [http://www.gnu.org/software/mit-
scheme/](http://www.gnu.org/software/mit-scheme/)

However, there hasn't been a release since 2011. The primary maintainer (Chris
Hanson) is now at Google, and seems to be busy with other things. Previously,
he was at MIT and used to write most of his own research projects in Scheme,
so it got a lot more maintenance attention.

------
616c
This language just keeps getting better and better. I am so glad I bought the
Realm of Racket book. Cannot wait to get my Scheme on!

And with ARM this will soon become the only language I need!

~~~
minikomi
Yes, I really love racket. Congratulations to the team!

------
yfefyf
Congrarulations, the Racket team! It's really a joy to use Racket. Racket is
elegant, powerful and fast. Everybody should try it. It's extremely easy to
install and setup. And whenever you have any question, a fantastic community
is there waiting for you.

------
saurabhnanda
Anyone used Racket AND clojure in production? Any first hand experiences?
We're looking to add another language/environment to our, currently
RoR+Postgres stack, and have a soft corner for lisps.

------
EastCoastLA
How is whalesong coming along? Anyone using it for production apps.

~~~
codygman
What is whalesong? Do you have a link?

~~~
klibertp
Racket to JS compiler by Danny Yoo.
[http://hashcollision.org/whalesong/](http://hashcollision.org/whalesong/)

------
turtle4
Having used clojure for a few things recently, I am interested in picking up a
non-jvm lisp. It seems like Racket and Chicken Scheme are both well
recommended. Anyone reading this have experience with both / insights as to
why I might want to select one vs the other?

------
sigzero
The package ecosystem has expanded. I like that.

[http://docs.racket-lang.org/pkg/getting-
started.html#%28part...](http://docs.racket-lang.org/pkg/getting-
started.html#%28part._github-deploy%29)

------
makmanalp
I like that the docs look less like they jumped out of the geocities era.
Still could go a long way though. Signalling is important, and if you signal
"old and unupdated" to your users, that's not a great start. (e.g.:
[http://docs.racket-lang.org/pkg/Package_Concepts.html](http://docs.racket-
lang.org/pkg/Package_Concepts.html))

"prev", "next" (when the table of content is right there next to it) and "top"
(usually the header / logo link these days) and collapsible TOC trees screams
"we copied this out of MSDN '97 and windows .chm files".

The "...search files..." looks like it was written by a programmer. The white
on gray line with the black on white line next to it looks odd. Natural
spacing sometimes is a great substitute for lines.

The main docs page ([http://docs.racket-lang.org/](http://docs.racket-
lang.org/)) contains way too many fonts and way too many colors. Pick a scheme
and go with it.

My favourite examples of docs that look like people cared:

[http://flask.pocoo.org/docs/quickstart/](http://flask.pocoo.org/docs/quickstart/)
(well designed, tasteful font, color and spacing selection)

[http://docs.vagrantup.com/v2/getting-
started/index.html](http://docs.vagrantup.com/v2/getting-started/index.html)
(lack of search bugs me)

[https://developer.mozilla.org/en-US/docs/Web/CSS/:nth-
child](https://developer.mozilla.org/en-US/docs/Web/CSS/:nth-child) ("hide
sidebar" here serves a real purpose: hides the whole thing so the doc display
is wider, kinda nice that TOC follows you)

Conclusion: Glad it's improving, but please keep at it! Great docs make your
product a joy to use!

\-------------------------

edit: let me add some WORSE examples to put things into perspective:

[https://www.tcl.tk/man/tcl8.6/TdbcCmd/tdbc.htm](https://www.tcl.tk/man/tcl8.6/TdbcCmd/tdbc.htm)

[http://junit.sourceforge.net/javadoc/](http://junit.sourceforge.net/javadoc/)
(ughhhh)

[http://www.gnu.org/software/smalltalk/manual/](http://www.gnu.org/software/smalltalk/manual/)
(whenever I see the gendocs selection page I get nostalgic. Really? 120 vs
420kb? I didn't care even when I was using dialup. Also the "one webpage per
node" version almost always sucks because you can't search for anything. And
the "all in one page" version sucks because it's too huge sometimes. Who uses
the ascii text version or the info docs version?)

~~~
tekacs
I think you have a valid point (other than in the case of the Vagrant docs,
which I absolutely detest [0]).

The simplest way to make good-looking docs might just be to 'just use Sphinx'
(as does Flask, mentioned and
[http://docs.python.org/](http://docs.python.org/) and [many others][1].

Another example of amazing docs (they've always been pretty decent, but
amazing in their most recent style) are the PHP docs:
[http://www.php.net/manual/en/function.pg-affected-
rows.php](http://www.php.net/manual/en/function.pg-affected-rows.php)

The docs are a necessity to make up for the shoddy, inconsistent patchwork
that is their language design, but they are damned well designed and easy-to-
use for the wading through flat scope that is required by those who use the
language.

Similarly, styles based on YARD/codo
([http://coffeedoc.info/github/coffeedoc/codo/master/](http://coffeedoc.info/github/coffeedoc/codo/master/))
are pretty nice for API references.

[0]: Disappearing sidebar when you resize to narrow, _huge_ amounts of spacing
everywhere and sidebar names that can't be expanded without navigating to
their root. :/

[1]: [http://sphinx-doc.org/examples.html](http://sphinx-
doc.org/examples.html)

~~~
makmanalp
Ooooh the PHP ones are even better than they used to be, I hadn't checked in a
while. I have always loved the user comments in docs idea. I've noticed so
many bugs, gotchas and idiomatic patterns simply by looking at those comments.
I bet it gives the devs a good idea on what to work on next, too. It didn't
used to have votes which was bad because it perpetuated bad advice sometimes,
but now it seems they have that too!

