Pyret has lots of nice ideas, looking forward to see it evolve.
That said, the title of this post is a bit misleading so I wanted to correct it. The group of people who develop Racket and Pyret are mostly disjoint. I'm not trying to diminish Pyret at all, but wanted to make sure the right people get the credit. You can find out who develops Pyret here: http://www.pyret.org/crew/
> but looking through the docs on typed racket it certainly looks like it adds java-style static typing
It's unclear what you mean by "Java-style static typing" then, because the Java type system and Typed Racket's type system are completely different.
One actually has local type inference (which is not "crappy" type inference necessarily; HM-style type inference is notoriously brittle), the other doesn't. One has nominal class types, the other has no class types (yet). One has intersection types, occurrence typing, "true" union types, and so on, while the other has none of those. One has bounded polymorphism, the other has System F-like polymorphism. One of them has variable-arity polymorphism, while the other doesn't. The list goes on.
In fact, aside from being explicitly typed, there are few similarities.
Typed Racket definitely doesn't add a "Java-style static typing" system at all. Its type system is quite specifically designed to accommodate the kinds of programming idioms you find in Racket programs (via occurrence typing, function intersection types, and so on), and comes with local type inference.
> Racket is really very complex thing with many man-decades of research behind it and even where it is being advertised, it looks like a typical "academic" thing.
As a fellow Racketeer, I'm curious: what do you think can be done to shake this "academic" image?
It does[1], but it's not necessarily preferred. The whole point of Typed Racket is that you can write your program in (untyped) Racket originally (maybe starting out as a small script), and then add types if you need your program to be more robust. Since typed and untyped modules interoperate smoothly, you choose whatever combination works for your project.
That said, some libraries start out typed too (e.g., the Racket math library[2]) and do benefit from type-driven optimizations and type-checking.
I use emacs with evil-mode (very good vim emulation) to program in Racket. The advantage of emacs is that it has paredit, geiser, and other useful plugins.
Racket's macro system and Kernel's fexprs are pretty fundamentally different, so I don't think the comparison is very apt. In particular, Racket's macros can be entirely compiled away.
It's an excellent free undergraduate-level PL textbook that covers a lot of ground and is informed by both research and practice. There's a 2nd edition linked from there as well.
To the contrary, Typed Racket is under active development and new Racket libraries are written using it. I don't know where you got the impression that it's going nowhere, but it's incorrect.
Here are two examples that have been presented at CUFP. The Starfire Optical Range[1, 2] uses it in production, I think as part of the control software for their telescopes. Naughty Dog, a major video game developer, uses it for scripting their games[3, 4].
> Now, admittedly, not all the productivity gain is from types. However, they certainly help me, not just in making the code robust but also in writing it in the first place. And typeclasses actually do make the language concretely more expressive in certain ways.
You said you started out in Racket. Did you try Typed Racket? You don't necessarily need to move to Haskell to get a type system (though you won't get typeclasses).
> AFAICT there is not a well-understood definition of first-class outside of "first-class functions."
Why not just the same notion of "first-class" as functions? In other words, that the feature is actually represented by a run-time value that can be passed around freely and stored. This is the usual definition of "first-class" that I hear most people use in the programming languages world. Examples include first class control (continuations), first class references (boxes, mutable cons cells, etc.), first class environments, first class modules (see OCaml, units, etc.), first class labels, and so on.
In Racket, any custom data type can be turned into a function by using the `prop:procedure` structure type property. It's usually not done with things like maps and sets because this kind of "punning" is not idiomatic. Being a function is not actually a necessary condition for being "first-class" though.
Re: macros, this is why tool support for macros is important. Many good Lisps come with macro debuggers that let you reason about the macro expansion. A good example is Racket's macro stepper: http://www.ccs.neu.edu/racket/pubs/cf-sp09.pdf
That said, the title of this post is a bit misleading so I wanted to correct it. The group of people who develop Racket and Pyret are mostly disjoint. I'm not trying to diminish Pyret at all, but wanted to make sure the right people get the credit. You can find out who develops Pyret here: http://www.pyret.org/crew/