Comment by eatonphil | Hacker News Reader

Comment by eatonphil | Hacker News Reader

I've been getting into Racket recently after spending some time with Chicken. I like Chicken a lot. It has a great ecosystem. However, it can't compete with the Racket standard libraries (and/or libraries that get included by default) -- which are better than most languages its age and popularity (OCaml, Haskell, other Schemes, etc.). For instance, the standard library includes a completely asynchronous web server and asynchronous database drivers.

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

[5] https://github.com/pycket/pycket

[6] http://www.ccs.neu.edu/home/samth/pycket-draft.pdf

Hi, Racket community member here. Thanks for the in-depth comment about your experience, and thanks for writing about your work with the webserver library! A couple follow up questions if you've got the time:

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

Hey, I'm a racket beginner and I'm wondering where the best places are to ask questions. I'm asking in general, but also specifically I'm trying to do more complex terminal input/output, and I'm having trouble getting the charterm package running.

I've always gotten great feedback quickly on the #racket channel on freenode.

There are some very helpful folks on Stack Overflow, but the racket-users mailing list is definitely the authoritative resource. Also, Neil Van Dyke (the package's author) is helpful and responsive.

Hello! I cannot say for sure that I am not imposing the issues on myself but writing in a bad manner.

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.

Can you give an example where you don't get the stack trace you expect? For example, when I run simple programs at the command line I get the stack trace I'd expect, and I get more if I run it in DrRacket (with and without errortrace).

Are you running the programs in DrRacket or at the command line?

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.

I really, badly wanted to use racket for server side programming. But last time I tried, in december, I discovered there was a typo in the contract of the struct used for http responses.

It wasn't confidence inspiring.

EDIT: It's fixed in 6.8, which fills me with some hope.

I've run an async Racket web server on Heroku, and it was entirely unexciting.

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).

Were you using the built in web server? I've been wondering about its performance in real world loads.

Only partially.

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.

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 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.

It's about the same as what I get out of most things. Usually, this just ends up being the C10k problem, which you need some not-so-nice code to work around.

The documentation is my biggest frustration with Racket. Trying to grok how to use something as simple as their HTTP module proved difficult. It's great documentation, but seems to be aimed at a more academic level than pragmatic.

As a data point, this little Racket server — https://github.com/coding-robots/iwl — served millions of requests from late 2010 until early 2016 (when I switched to Go) without any issues first on a smallest Rackspace Cloud instance, then on a smallest DigitalOcean instance.

Thanks for the info. Curious - why the re-write if racket performed well enough?

For no practical reason — actually, for the same reason I rewrote in from the original Python version: I just fell in love with the language (first Racket, then Go).

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!

i found the Racket library to be inconsistent, especially anything related to Vector.

Can you say more here? What things are we missing?

vector-immutable is unusable, all operations on vectors return a mutable vector forcing you to rely on vector->immutable-vector every time.

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.

Yes, immutable vectors are not a convenient data structure -- I recommend using one of the other random access functional data structures available as libraries, such as RRB trees.

Reply on news.ycombinator.com