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.
"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.
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.
Personally I don't use it for anything server-side, but that doesn't mean it's just for education. I suppose it's an unavoidable misconception given that its most obvious strength is the quality documentation and IDE.
Its built-in image support is much better than anything I've seen in any other language, so I've used it a couple times for writing simulations that need a histogram. It's also much better than Clojure for things that require low memory usage or fast startup time.
I learned with Racket, and I found it to be a great experience. It comes with an IDE, DrRacket, that makes it very comfortable to start experimenting. It's also "batteries-included", with libraries for GUI, graphics, networking, etc. It also comes with really good documentation (at least as good as Python's, I'd say, and better than either Perl's or Ruby's).
Racket has a good foothold in educational environments, so it's no coincidence that it's conducive to learning. However, Racket also sees a lot of usage in the PL research space, so it's also conducive to just experimenting. Those two combined can make it a very fun environment.
There's also #racket on freenode, which I've found rather welcoming.
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.
All the major lisp dialects are rather different and encourage different styles. My own opinion is that no one is a better first lisp, as long as you check out the others eventually. Racket is an excellent start. I always advise people interested in lisp to check out racket, clojure and Common Lisp in whatever order they wish. I started with scheme in 2008, moved to clojure in 2009 and I've been a happy Common lisper since 2010/11. Depending on your own style as a programmer you might choose a different main dialect you like best, but only after you try them all :)
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.
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.
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?
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)
"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/) 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://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?)
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/ and [many others][1].
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.
[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. :/
When Racketeers talk about documentation, they're not talking about the sort of documentation that you are holding out as better. They're not talking CSS and markup and formatting. No.
When Racketeers talk about documentation, they are speaking in Lisp and the context is code as data and data as code. When Racketeers talk about documentation they are talking about Scribble.
I disagree with your examples. Taste is an odd thing that way.
Specifically, previous/next are great if you are reading it straight through. I agree this isn't that likely, but is nice to have. (I have actually used these. Recently, even.)
The fonts and colors are mostly pleasant. I can see how you would like other schemes. But I can't find anything atrocious.
I love how linked everything is. Specifically in the code samples. Even in the intro[1], all code samples are linked to the docs for what is there. Contrast this with the flask documentation, where if I want to see what @app.route does, I have to go find it elsewhere.
So, yes. There are things I would find to complain about if asked to look for them. At no point in actually perusing and using the site have these ever bothered me. And there are more niceties thrown in there that have made things easier than any of the complaints you mentioned.
Despite me not really liking Java all that much, the javadocs can be very useful; although in that example they chose a bad non-default colour - black on (dark) green is difficult to read.
I think we just disagree on taste for documentation pages. For example, I find the Vagrant docs somewhat garish and hard to read.
The current look of the Racket documentation was designed by Matthew Butterick. You can see his excellent book on typography and design here: http://practicaltypography.com/ -- and it was made with Scribble, the same system that generates Racket's documentation.
[+] [-] pavpanchekha|12 years ago|reply
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|12 years ago|reply
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.
[+] [-] samth|12 years ago|reply
[+] [-] Oculus|12 years ago|reply
[+] [-] m0nastic|12 years ago|reply
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.
[+] [-] samth|12 years ago|reply
[+] [-] technomancy|12 years ago|reply
Its built-in image support is much better than anything I've seen in any other language, so I've used it a couple times for writing simulations that need a histogram. It's also much better than Clojure for things that require low memory usage or fast startup time.
[+] [-] whyme|12 years ago|reply
[+] [-] gus_massa|12 years ago|reply
[+] [-] dobbsbob|12 years ago|reply
[+] [-] derengel|12 years ago|reply
[+] [-] bhrgunatha|12 years ago|reply
[+] [-] gexla|12 years ago|reply
[+] [-] groovy2shoes|12 years ago|reply
Racket has a good foothold in educational environments, so it's no coincidence that it's conducive to learning. However, Racket also sees a lot of usage in the PL research space, so it's also conducive to just experimenting. Those two combined can make it a very fun environment.
There's also #racket on freenode, which I've found rather welcoming.
[+] [-] brudgers|12 years ago|reply
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.
[+] [-] pavelludiq|12 years ago|reply
Happy Lisping!
[+] [-] jonnybgood|12 years ago|reply
[+] [-] 616c|12 years ago|reply
And with ARM this will soon become the only language I need!
[+] [-] minikomi|12 years ago|reply
[+] [-] yfefyf|12 years ago|reply
[+] [-] saurabhnanda|12 years ago|reply
[+] [-] EastCoastLA|12 years ago|reply
[+] [-] codygman|12 years ago|reply
[+] [-] turtle4|12 years ago|reply
[+] [-] sigzero|12 years ago|reply
http://docs.racket-lang.org/pkg/getting-started.html#%28part...
[+] [-] makmanalp|12 years ago|reply
"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/) 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/ (well designed, tasteful font, color and spacing selection)
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 ("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
http://junit.sourceforge.net/javadoc/ (ughhhh)
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|12 years ago|reply
The simplest way to make good-looking docs might just be to 'just use Sphinx' (as does Flask, mentioned and 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
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/) 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
[+] [-] brudgers|12 years ago|reply
When Racketeers talk about documentation, they are speaking in Lisp and the context is code as data and data as code. When Racketeers talk about documentation they are talking about Scribble.
http://docs.racket-lang.org/scribble/index.html
Scribble is Racket's documentation tool. It adds an independent documentation phase to the Lisp expansion. Here is Mathew Flatt introducing it:
http://vimeo.com/6630691
None of the examples even comes close. The closest thing is EMACS Org.mode, but it is still ad hoc to whatever language one is documenting.
[+] [-] taeric|12 years ago|reply
Specifically, previous/next are great if you are reading it straight through. I agree this isn't that likely, but is nice to have. (I have actually used these. Recently, even.)
The fonts and colors are mostly pleasant. I can see how you would like other schemes. But I can't find anything atrocious.
I love how linked everything is. Specifically in the code samples. Even in the intro[1], all code samples are linked to the docs for what is there. Contrast this with the flask documentation, where if I want to see what @app.route does, I have to go find it elsewhere.
So, yes. There are things I would find to complain about if asked to look for them. At no point in actually perusing and using the site have these ever bothered me. And there are more niceties thrown in there that have made things easier than any of the complaints you mentioned.
[1] http://docs.racket-lang.org/guide/intro.html
[+] [-] userbinator|12 years ago|reply
Despite me not really liking Java all that much, the javadocs can be very useful; although in that example they chose a bad non-default colour - black on (dark) green is difficult to read.
Here's a better example, they normally look more like this: http://www.jdom.org/docs/apidocs/
[+] [-] samth|12 years ago|reply
The current look of the Racket documentation was designed by Matthew Butterick. You can see his excellent book on typography and design here: http://practicaltypography.com/ -- and it was made with Scribble, the same system that generates Racket's documentation.
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] unknown|12 years ago|reply
[deleted]