Racket v6.8
blog.racket-lang.org
blog.racket-lang.org
Shoutout to Prof Clements and his excellent sideburns.
[1] http://ziotom78.blogspot.it/2011/02/experiments-with-racket-...
In general, one of the benefits of Scheme versus (say) Python is the regularity and simplicity of the syntax. It also has a better concurrency story.
Racket also makes it incredibly easy to parse new languages and run them in a JITed intepreter (Racket). Though I haven't played around with this yet. See [0] for a really great example.
There are some not great parts though. You'll need to spend time deciphering the use of custom languages (#lang). I wrote a little about this for #lang webserver [1]. But my biggest issue with Racket right now is its completely useless stack traces. I found an "errortrace" module [2], but it has not helped in practice.
Additionally, the Racket standard library lacks a comprehensive time library and a good string templating library (for HTML generation). I am working on an internal web app in Racket, but am limping through the built-in web-server/template module [3]. There is a mustache implementation but I'm not a big fan [4]. I plan to write a more jinja-like library when it's not a distraction from finishing the app.
Footnote: Scheme is very similar to Standard ML in that it is a simple base that many people experiment with to test out patterns in language design (styles of concurrency, garbage collection, compilation techniques, etc.) Racket is no different. Pycket was posted recently and I found it very interesting [5]. It is written in RPython. In particular, the white paper introducing it has a fascinating background on JITing and compilation techniques in Scheme [6].
[0] http://beautifulracket.com/stacker/
[1] http://notes.eatonphil.com/2016/29/walking-through-basic-rac...
[2] http://docs.racket-lang.org/errortrace/
[3] http://docs.racket-lang.org/web-server/templates.html?q=web-...
[4] https://github.com/adolfopa/racket-mustache
1. Could you elaborate on the stacktrace issues you encountered?
2. The Gregor package [0] is currently a bit of a community standard for date and time functionality. There's a general desire to merge this into the Racket stdlib. Would this package suit your needs?
3. For string templates, a lot of folks use Scribble "at expressions" via the `at-exp` meta-language combined with format specifiers from `racket/format` to write code that looks very similar to python string interpolation and other language-integrated string formatting systems. You can see an example of that on Greg Hendershott's blog [1]. Would this work for your use cases or were you looking for something a bit more involved?
[0] http://docs.racket-lang.org/gregor/
[1] http://www.greghendershott.com/2015/08/at-expressions.html
In particular, syntax errors are reported well. The issue is that runtime errors only seem to report the function in which an error occurred and not even a line number. This makes debugging slow and tedious.
The web-server template library has similarly poor stack traces in both runtime and syntax errors. And while I better understand the complexity here, I still feel uncomfortable asking a coworker to contribute with the state of template debug messages.
Certainly, compared to the Python standard time library, Racket does well. And between SRFI-19 and Gregor, 3rd-party time libraries are not bad. The biggest thing the standard time library and SRFI-19 misses are some default formatting and parsing constants for the most common formats (like ISO8601). This way users don't need to look up the ISO8601 format every time and and the SRFI-19 format keywords. Furthermore, documentation for and examples of SRFI-19 and the standard time library are lacking. This makes it difficult to get started.
The at-exp language may have its use-cases. But I really don't enjoy hacking together HTML templates with it right now. Furthermore, HTML templates are especially a cross-team piece of a project. I think the only suitable tool for it is a simple DSL that (e.g.) doesn't require interpolating Racket to loop over data.
By default, DrRacket has "errortrace" enabled. With "errortrace" the errors get a better stack trace [1], but it indirectly disable some optimizations, so the programs are slower.
But the command line version doesn't have "errortrace" enabled by default, so it's faster but with less useful stack traces.
[1] Actually, they are fake stack traces. The compiler may inline the function but use continuation marks to keep track of what the stack trace would have been.
It wasn't confidence inspiring.
EDIT: It's fixed in 6.8, which fills me with some hope.
Which is good.
It handled everything fairly well, for a short-lived (month or two), API server that received several hundred thousand requests a second. (A stand-in server to handle some updating for some hardware in the field. Our normal server failed catastrophically, and took out the entire rack, which included the backup... So we needed something up quick, whilst we rebuilt the backup and redeployed the front-facing servers.)
It was fast to work with, but that's sort of a given with any Lisp, even though we had some ties between web, typed, and lazy Racket.
The documentation wasn't awesome. There's enough to get you started, but at the time, there wasn't a lot more.
But, Racket is fairly predictable in how functions are exposed, and how they should work. (As well as having a REPL to rapidly prototype).
I lifted out the MIME functions and some of the threading functions. Probably the request constructors as well.
It was also on a Heroku scaling dyno.
In my testing, the inbuilt web server is decent, but starts becoming hit and miss around 10,000 - 25,000 requests/sec, depending on hardware.
More than enough for hobby sites, but not quite enough for heavier enterprise applications.
What you do with each request can have huge impacts, a colleague tried to lazily render templates, so follow pre-rendering best practices.
What are you comparing it to here? Something fast written in java or go? I could understand racket being slower than that, but surely it'd perform faster than the likes of flask or sinatra.
Also, rewriting it in Go helped me understand that my brain is wired for imperative languages, not functional: writing algorithms felt so much easier and more natural in Go. Nevertheless, learning Racket was fun!
Vector lacks many operations that List has, it should be easier to interchange each others. Vector even lacks combinations despite this one being implemented by converting the list to a vector first.
https://github.com/racket/racket/blob/master/racket/collects...
I have encountered many inconsistencies like this.
I haven't read RoR--placing an order now.
From 2009 mail list of R on the similarities and differences between R and Lisp
https://stat.ethz.ch/pipermail/r-help/2008-December/181982.h...
R is much more functional then most people give it credit.
From Saint Hadley
> R, at its heart, is a functional programming (FP) language. This means that it provides many tools for the creation and manipulation of functions. In particular, R has what’s known as first class functions. You can do anything with functions that you can do with vectors: you can assign them to variables, store them in lists, pass them as arguments to other functions, create them inside functions, and even return them as the result of a function. http://adv-r.had.co.nz/Functional-programming.html
It isn't a pure functional language which is really only available in Academics and Haskell has nomads to get things out which is arguably not pure.
Learning Racket helped me to use the Scheme parts found in R. It really is a little mind blowing. R was mostly used by people with little computer skills and was used with a imperative mindset but when you use it more functional R really shines.
In addition to going over how to write various DSLs in Racket, there are 'explainers' for a lot of Racket concepts.
Edit: One feature they should really consider adding is an online documentation for functions that is displayed in a status line while you type. I've found this incredibly helpful in other IDEs.
It's a pity that iOS and Android are still missing.