
Racket v7.2 - ethelward
https://blog.racket-lang.org/2019/01/racket-v7-2.html
======
IngoBlechschmid
Mike Sperber used Racket in his excellent 35c3 talk "How to teach programming
to your loved ones":
[https://media.ccc.de/v/35c3-9800-how_to_teach_programming_to...](https://media.ccc.de/v/35c3-9800-how_to_teach_programming_to_your_loved_ones)

From the abstract: "A word of warning: The resulting approach is radically
different from most teaching approaches used in universities and schools. In
particular, it avoids teaching purely through examples and expecting students
to develop the skills to arrive at the solutions on their own. Instead, it
eaches explicit methodology that enables students to solve problems of
surprising complexity on their own, whether they are 11 or 55, whether in a
classroom, a training facility, or your home. Extensive documentation,
material, and software to support this methodology is available for free."

~~~
webwanderings
Thanks for sharing. Nice. I'm not a programmer but I have taken many courses
all over the web (I think I only lack practice). This talk reminds me of the
Edx course on functional programming using DrRacket. As the talk suggests
about the boring and bureaucratic aspect of the recipe design, I think that's
exactly the reason why I couldn't finish that Edx course twice, though I am
convinced that this design/recipe methodology to learning to program, is the
right solution (which is absent from the pedagogy of a lot of courses). This
talk makes me want to try and take that edx course again, the third time!

~~~
WoodenChair
If a methodology doesn't motivate you to actually do the work (i.e. finish the
course) no matter how intuitive it might be, it will not work. That said of
course everyone is different, and what motivates one person, may not motivate
another.

------
seertaak
Racket is such a cool project. I keep telling myself I'll find the time to do
something serious with it, but I never get around to it.

One minor bit of criticism - would be it be so hard/expensive to hire a
designer to do some minor touching up of the DrRacket GUI? It looks like a
toy, and the icons didn't even look good in 1998.

I'll balance this criticism with the remark that any language/platform that
manages to a) add, ex-post, a type system, b) fix the Gordian knot of modules
_and_ macros, and c) has the audacity (combined, curiously, with humility) to
just swap out the entire backend to eek out more performance, deserves my
respect. In addition both Flatt and Tobin-Hochstadt give excellent
presentations where it's impossible not to notice their passion for Racket.
They're definitely among my nerd heroes right now.

~~~
velcrovan
> and c) has the audacity (combined, curiously, with humility) to just swap
> out the entire backend to eek out more performance

Unfortunately they are not doing it for performance reasons. They are doing it
solely to make the code base cleaner and easier to maintain.

Based on their most recent blog on the subject ([https://blog.racket-
lang.org/2019/01/racket-on-chez-status.h...](https://blog.racket-
lang.org/2019/01/racket-on-chez-status.html)), the new backend is almost
uniformly slower to load, takes up twice as much memory, takes more than twice
as long to build, takes twice as long to compile Racket code, and the compiled
code generally runs slower than it used to. (They expect that this last one
will improve, but they have never indicated that they expect it to actually
match or exceed the speed of code compiled with the old backend.)

Also, the new back-end, by design, permanently removes support for the Racket
C API.

This trade-off is hard for me to understand. I don’t maintain Racket, so I
don’t have any idea how much effort this will ultimately save those who do.
But I do know that I the main thing holding me back from investing more
development time in Racket is its poor performance compared to languages like
PHP, Python or Go; and I have never seen explained, and can’t even imagine,
what new features the maintainers will now be able to implement that would
actually make Racket development more productive or enjoyable.

~~~
hajile
The new backed is overall faster according to that post. In addition, looking
at raw Chez, the results are even more one-sided. Chez is _always_ faster and
often 2-8x faster. New racket is usually faster and where it isn't is mostly
due to new IO. Sure, compile times get bigger -- Chez is doing _way more_
optimization passes than Racket (Chez is the only scheme I know of that can
get close to SBCL in performance).

[http://blog.racket-lang.org/img/posts/2019-01-29-racket-
on-c...](http://blog.racket-lang.org/img/posts/2019-01-29-racket-on-chez-
status/pict.svg)

According to them, fixing things takes much less time and is much easier to
understand. For a system where lots of development is free, ease of
understanding and fixing is extremely important.

> But I do know that I the main thing holding me back from investing more
> development time in Racket is its poor performance compared to languages
> like PHP, Python or Go

Racket is slower than Go because racket is dynamically typed, is a much
higher-level language, and has to implement continuations. Racket is _much_
faster than python or PHP.

My big issue with racket is dev tools. DrRacket isn't very good IMO. They need
to make a server that implements the Language Server Protocol with some
additional hooks for more dynamic lisp stuff. At that point, devs can choose
to use all kinds of actually good editors (sublime, VS Code, Vim, Emacs,
IntelliJ, etc) for coding. They can even add the LSP to DrRacket and continue
to use it.

[https://langserver.org/](https://langserver.org/)

~~~
velcrovan

        The new backed is overall faster according to that post.
    

No, according to that post, the new back-end itself is massively slower than
current Racket by every single measure shown. To reiterate, I’m talking about
startup and load times, memory use, expand and compile times, and build times
(i.e. time to compile the back-end itself). All slower. (Are you sure you're
not referring to _code compiled using_ the new back-end?)

I grant that there is some benefit in that the longer compile times result in
an improvement in some benchmarks, but that doesn’t negate that the new back-
end is still slower than the old one by every measure.

> Racket is much faster than python or PHP.

This is funny because although you will find benchmarks out there to support
this point, in my experience of writing and using Racket programs it has never
hold up. Most recent example: I participated in Advent of Code this year, and
there was almost never a Racket solution posted that wasn't ten times slower
(and in my opinion harder to read) than the simple & idiomatic Python
solution.

I love the Racket language, and there are some DSLs like Pollen that do things
I simply can’t imagine attempting anywhere else. But it’s for sure my last
choice for speed, based on personal experience.

~~~
samth
> Most recent example: I participated in Advent of Code this year, and there
> was almost never a Racket solution posted that wasn't ten times slower (and
> in my opinion harder to read) than the simple & idiomatic Python solution.

Can you point me to some examples of this? I haven't done AoC and so don't
know where to find solutions posted to compare. It should be very rare for
idiomatic python or php to be faster than idiomatic racket.

------
jashmatthews
Matthew Flatt did an excellent talk "Incremental Parallelization of Dynamic
Languages" on Racket [https://air.mozilla.org/incremental-parallelization-of-
dynam...](https://air.mozilla.org/incremental-parallelization-of-dynamic-
languages/)

There's a lot of useful discussion in here about parallelism which also
applies to Ruby, Python, Lua etc.

~~~
pritambaral
Is this video available without a login?

~~~
yorwba
Using Firefox on Android with uBlock Origin enabled, I was redirected to some
"onlinexperiences.com" site that displayed "System Check" and then a
constantly growing number of lines containing only "Browser".

Then I tried the stock Android Browser and it passed the browser check, but
redirected to a login page.

Going back to Firefox and disabling uBlock Origin, I was able to access a
description of the talk and the video itself. So I conclude that the video is
available without login, but you have to use Firefox and allow yourself to be
tracked.

Pretty grating "online experience" for something hosted on a mozilla.org
subdomain.

Edit: the video file is here:
[https://airmo-7feeef12f503ef5d.s3.amazonaws.com/2014/02/06/4...](https://airmo-7feeef12f503ef5d.s3.amazonaws.com/2014/02/06/4q6e6u-hd_mp4.mp4)

~~~
darkpuma
Very bizarrely for something on mozilla.org, it incorrectly believes my
firefox is out of date:
[https://i.imgur.com/BRNBDPj.png](https://i.imgur.com/BRNBDPj.png)

I think there must be a cultural disconnect between how people at Mozilla use
firefox, and how users like us use Firefox.

~~~
detaro
AFAIK air.mozilla.org is some ready-made product by a different company (maybe
even run by them), not developed by Mozilla

------
kovrik
I just wanted to say that Racket docs are the best docs I have ever seen. It
feels they document everything -- so much detail. Treasure trove of knowledge.
Thanks guys!

------
kumarvvr
Does anyone use this in production? Will this be a good platform to develop a
DSL for a web app?

~~~
pmatos
We ([https://linki.tools](https://linki.tools)) use it for our main
development tools product - 100% Racket in production. Check S10
([https://linki.tools/s10](https://linki.tools/s10)).

Racket is an absolutely gorgeous language. It's the kind of language that
might look complicated but the important thing is to start with the basics.
Yes, there are complex features in the language and big words that might be
scary : continuations, impersonators, collapsible contracts, macros. However
most of the time you don't really need these features.

Even the basic features of the language are enough to make your software
shine. After you have a basic grasp, start to tackle other features of the
language refactoring your code as you go.

Another great feature is the community. racket-users mailing list (hosted in
googlegroups) is a great place to start asking questions.

You'll have a lot of fun. Enjoy your time in Racket lang. #not-a-typo

~~~
kumarvvr
So, I am an experienced developer but new to Lisp based stuff, which seems to
be what racket is based on. Can you suggest any books to learn racket.

edit: Spelling

~~~
BMarkmann
Seems like the most common answer to this might be SICP (Structure and
Interpretation of Computer Programs -- you'll find course videos pretty easily
from Google; the ones from the authors are really great). Note that it's based
on Scheme, which is a ancestor of Racket, but Racket has a language pack that
papers over the differences and works with the code from the book. Official
course website:
[https://mitpress.mit.edu/sites/default/files/sicp/index.html](https://mitpress.mit.edu/sites/default/files/sicp/index.html)

You might, as a novice coming to Racket, find "Realm of Racket" to be more
approachable as an intro:
[http://www.realmofracket.com/](http://www.realmofracket.com/)

~~~
klibertp
> Seems like the most common answer to this might be SICP

Please don't. SICP is beautiful and all, but it's neither an intro nor
practical/immediately useful. There's a lot of enlightenments to be had by
reading it, but they have very little to do with Racket specifically. IMO,
it's a bad book if your purpose is learning Racket.

> You might, as a _novice coming to Racket_ , find "Realm of Racket" to be
> more approachable

Or, as an _experienced programmer_ , be bored to tears by the slow pacing and
didactical style. It's a great intro to programming and to Racket, but more
focused on the former, which makes it ill suited for experienced devs who want
to learn Racket.

~~~
BMarkmann
Please don't what, have an opinion?

I read SICP as an experienced programmer and I didn't find it impractical at
all; in fact, it kickstarted my interest in other lisps.

I read Realm of Racket as an experienced programmer (after knowing Common Lisp
and Clojure well) and it was entertaining and, yes, a gradual introduction to
Racket.

I'm sorry if you disagree, but was answering the question that was given with
a couple thoughts that might be beneficial. I'm glad you feel confident enough
in your interpretation of what was being asked and the OP's personal
background and motivation to flame someone else without, I don't know,
answering the question.

EDIT: I see you did answer him below, but my general response is still valid.

EDIT 2: Your response makes more sense given context. Sorry I got internet
angry a little too quickly.

~~~
klibertp
And on a more general note - let's leave the misunderstanding to the separate
thread - I'm glad you liked the books! I'm not saying you can't enjoy them -
far from it - but if your goal is to just _learn Racket quickly_ (where I
interpreted "experienced dev" as "short on time working adult") then they are
not the best resource for that. SICP is not even about Racket at all and RoR
includes a lot of introductory material you wouldn't need. Instead of learning
by accident, ie. reading weakly related material and hoping that an
understanding will somehow form (which seemed to be default mode in
education), I prefer using materials which are strictly on topic and are dense
enough to be efficiently absorbed, but not so dense that it takes a day to go
from one page to another. And to that my answer is: Wiki, tutorial&cheatsheet
and the docs.

What is obvious is that YMMV - I'm just saying what I'd do if I wanted to
efficiently learn Racket today. That's it.

~~~
BMarkmann
Yes, I totally agree it comes down to YMMV. Everyone's learning style is
different -- some like dense documentation, some like book-style progressive
walkthroughs. I certainly didn't learn CL by reading the HyperSpec, for
instance... :-)

~~~
klibertp
Yeah, that's why I included the "but not too dense" part ;) Personally, I
actually did learn Common Lisp mostly from HyperSpec (plus reading code - I
used StumpWM for a while and wanted to script it), but at that point it was my
4th Lisp (after PLT Scheme/Racket, Emacs Lisp and Clojure) and I was well
prepared for it, I think, because of my focus in PL research (hobbyist). I
certainly wouldn't say that HS is the way to go for new CL programmers without
special preparation.

But, Racket reference docs are not a language definition like HS, RNRS or the
Dylan book. The tutorials especially are quite friendly, but the reference is
also full of examples, overviews, summaries and introductions, along with the
links to the Guide - which can further help in comprehending the content (but
only if needed, otherwise they stay out of the way). They're basically
amazingly well done and I think more people should read them, if only to learn
something about how to write docs and technical prose in general... :)

------
lettergram
I’ve used Racket in the past. Personally, I’d still never use it for
production because the learning curve is fairly steep AND as this post
highlights - there are still bugs being worked out in basic features like
“set”.

However, overall I like the language. So, overtime I think it’ll have its day
in the sun.

~~~
soegaard
> there are still bugs being worked out in basic features like “set”.

You are misreading the release notes.

What was fixed is a Redex model (a tool used in semantics to model computer
languages). A change to the modeling of `set!` (assignment) was made. It has
no impact on Racket itself.

~~~
maxiepoo
Really? Then as written it's very misleading "led to some bug fixes in
Racket’s implementation of letrec and set!."

~~~
Gene_Parmesan
[Edit -- misread comment.]

~~~
clacke2
If it is in fact the case that only some redex models of `letrec` and `set!`
were fixed, then it is indeed misleading that the release notes say "Racket's
implementation" of them was fixed.

Unless you're the one who did the work, I'd rather trust the release notes
than your unsourced assertion.

That said, just because a bug was fixed in an important function shouldn't be
an indictment against the language. Racket is stable and productive, and
formal modeling can reveal all kinds of corner cases which may not have been
exposed in typical use, and may not have security implications. Maybe it was
edge-case performance, maybe garbage collection, the release notes simply
don't say.

I'd rather use a language whose authors improve their tools to discover and
fix issues than one where this doesn't happen.

~~~
Gene_Parmesan
Ahhh, my bad. I thought you were the same commenter as the first guy, and I
doubly goofed by misreading the comment in the first place. The dangers of
commenting before coffee. You're right, the difference between redex models
and racket's implementation of them would be confusing, and I don't have
enough direct knowledge to provide any insight there.

