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 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 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 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 racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/0d79e2bc-536c-a6da-5c15-3d84790864cc%40neilvandyke.org.
