Thanks for the info, Brian.

I'm getting the impression that Scheme/Racket Web production serving is sorta in same place it has been for the last couple decades: such that a really good and prolific developer can make a system work well in production, iff they can put in a lot of work beyond off-the-shelf components.

When deciding whether to to go Scheme/Racket, we consider the pros -- e.g., the linguistic power of Scheme, the ability to attract talent due to using a fringe language that people like or want to learn -- and weigh them against the greater amount of bespoke work, the necessity to then have non-commodity developers who are up to doing that well, and the greater risks/unknowns that might not be solved by throwing a larger AWS bill at a problem.[1]

For the server project I'll develop this week, it doesn't actually take advantage of Scheme, and the project also won't function as a good pilot project for scalability, so I'll probably just use Python&Flask this time.  I'll keep Scheme/Racket in mind for this, as a known-quantity backup plan, but probably Scheme/Racket will have to wait until later this year for a better opportunity to shine.

There is a GUI frontend project coming up that might be a better opportunity for Racket to be useful in production.  It would be 2nd generation replacement of a deployed specialized appliance frontend, which currently is done in JS in Chrome (no, not the horrifying touchscreen Web browser spaceship consoles we heard about the other day :), and some special hardware device interfacing.  I've prototyped replacing it with with Python Kivy,[2] but I happen to know that Racket's GUI library would be easier to use for this purpose, and result in more-solid UI operation.

After that, the next opportunity is probably 2nd generation of the entire server infrastructure, and we'll have to see what our needs and resources are like at that time.  We'll probably have that 2nd-gen work in mind if/when we do more engineering hiring later, and, in any case, I'd like to be able to hire the kinds of developers who are up to the challenges of doing bespoke work that works.[3]

[1] Though I think the risks/unknowns of a less-popular stack aren't what many developers are thinking when they flock to the most popular tools of the moment because a FAANG does it.  What tools&practices work for a FAANG, with massive infrastructure, massive staffing, and the practice of routinely shutting down large numbers of projects (and making many multi-billion dollar acquisitions of competitors, when the FAANG still fails to outperform upstart competitors with their project)... aren't necessarily the tools&practices a startup should use, with their handful of people who have to wear many hats, and actually have individual contributors understand the entire system, in order to make it work well enough and to troubleshoot problems rapidly, despite very limited resources.

[2] As I was evaluating GUI toolkits, there's ongoing bitrotting/abandonware of the desktop GUI space, as development flocked to adtech/VC-driven Web sites and smartphone apps, and people started favoring embedded massive browser engines (which have pros and cons).  And it looks to be self-perpetuating, because the non-Web GUI toolkits get less attention.  Kivy was one of the few current non-abandoned toolkits.  Racket's cross-platform GUI toolkit remains supported for solid Win95-era desktop GUIs, and is currently looking better than Python and JS-framework-in-WebKit options, for the particular kind of (non-consumer) touchscreen appliance console we'll need to do. (For slick consumer-facing UIs, I'm currently going through the rapid mood swings experience of the SwiftUI DSL and related iOS stack. :)

[3] And I've long believed that using one of the less-popular but beloved platforms -- like Scheme/Racket, Common Lisp, Haskell, OCaml, Erlang, or Rust -- is a great way to find and attract some of the best developers.  FAANGs can say to some of those developers, "we'll pay you more money, and everyone else who aspires to make FAANG money will be impressed when they see us on your resume", but the toolset you get to use can be one of the significant selling points of a competing value proposition.

You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
To view this discussion on the web visit

Reply via email to