Starting in 2000, I decided to help build out Scheme to "batteries included". (Initially, portable Scheme, and then eventually I focused on what's now called Racket.) https://www.neilvandyke.org/racket/
What's "batteries included" changes over time. In 2000, I needed batteries like Web scraping and crawling, various parts of a Web application server, CSV import, multimedia file handling, PostgreSQL access, embedded API docs, embedded unit tests, package tools, so I made batteries like that. (I also did some later non-open-source work of more specialized and sometimes fancier batteries.) (Racket already had portable desktop GUI.)
The batteries I need today, I'd have to roll up my sleeves and build for Scheme, since they include things like: Wasm targeting for in-browser front-ends, polished Android and iOS apps (ideally doubling as desktop GUI apps, and mobile-friendly Web apps), GPU/TPU targeting, good interfaces to cutting-edge ML libraries, various data science tools integrations. I'd be happy to build these new batteries, except grinding Leetcode and copying&pasting Stack Overflow would pay the rent much better.
Sadly, no. For one thing, despite several attempts, there's not really any good mobile deployment story for Racket at the moment (especially for iOS).
The Racket team appears to be more interested in (primarily) education and (secondarily) tinkering with programming language internals than making something that can be used to produce polished, packaged, distributable binaries (and let me stress here that this is perfectly fine... it's not a criticism, just an observation. Different people are interested in different things, and there's not anything at all wrong with that).
Things that would have to change in order for for me to consider Racket fully "batteries included":
1) Capable of building binaries for all major platforms (including iOS), including stuff like code signing.
2) A standard GUI and widget library that, again, works on all major platforms. The days when cranking out a command-line binary was good enough are long gone.
3) At one time there were some licensing issues that precluded use on iOS. I think that this may have been resolved by switching to the new Chez-based system, but am not 100% sure of that.
There are probably some other things.
Let me stress once again that I think Racket is great! It's just not something that easily be used for commercial software development in its present form.
In that case almost nothing is batteries-included. You can't turn a native iOS app into a web app. So the iOS SDK isn't a batteries included development platform.
If you have a requirement of GUI apps and reject the iOS SDK since it's a single native platform and reject things that only build to the web since it's lacking integration with platforms that native apps have, you're left with a bunch of stuff like Flutter, React Native, Qt, and HaXe. None of those have great ecosystems like each platform individually of the web, iOS, Android, Mac, and PC.
If you decide to settle for a limited ecosystem like React Native and others, I think it would also be fine to settle for Racket, which as you say, doesn't provide tools for building apps with iOS and Android's native UI components (though non-native UI components can be packaged into an installable mobile/desktop app and the LGPL is no longer an issue since Racket re-licensed almost everything).
If you decide you gotta have GUI apps and you gotta have a full ecosystem, going with XCode would be one option. Stanford chose that. I would have liked to think that MIT with their past involvement of open source wouldn't choose such a walled garden. However, this expectation of mine has eroded as I've watched scandals unfold at MIT. If you choose the web, that's clearly great for commercial software, but the students may lose out on important trends like AR & VR. Developing directly for Android might be a good compromise, since at least it's possible to run a fully open source Android device.
Edit: I see that the market's mostly rejected web-based installable mobile apps, though the mobile web is certainly a big thing. I would argue that the market has also mostly rejected React Native and Flutter. It works, but um, yeah... https://www.thecodeside.com/2021/08/03/why-flutter-is-not-yo...
There's clearly a continuum here. The XCode ecosystem is more batteries-included than Racket, though it's not fully so (at least by my definition). For one, it does run on mobile devices (albeit only Apple mobile devices) and it does have standard GUI capability. Racket has neither of those capabilities.
> For one thing, despite several attempts, there's not really any good mobile deployment story for Racket at the moment (especially for iOS).
And what about Python? Is there a good mobile deployment story there? I'm not trying to be snarky, it's been a while since I did any serious Python work. I'm genuinely curious.
At one time there were numerous packages that let you run JS-based code across both mobile and desktop (e.g., Cordova). These seem to be mostly moribund nowadays, though.
I think there are a couple of options for running Python on mobile.
Has Racket somehow taken over the commercial software world when I wasn't paying attention?
How many Racket apps in the Mac App Store? How many Racket apps on Steam? How many on any app store? I know there have been one or two, but would be surprised if there were more than a couple of dozen.
How many non-hobby web sites are using Racket as a back end? Any?
I did that a bit more than a decade ago and everything worked except for the "picture language" section from chapter 2, but that's a very minor part of the course. There may have been an occasional definition I had to add to get code to work, but it was certainly nothing difficult.
Look into Chicken Scheme. The language offers a repository of "eggs", which cover all kinds of functionality, from SRFIs (akin to Python PIPs), to object systems, to library wrappers.
