My info is a bit out of date, but I'll try to go through big block of concerns...
> Do I want to iterate every 18 hours waiting for the pkgs.racket-lang.org build server to finish building my package? Then do it again because the build failed (my mistake, but now my users have to wait until later that week…)?
( https://pkgs.racket-lang.org/ is one way of sharing an open source package, through a public repository analogous to PyPI. There is a small delay upon uploading a new package/version, because the server builds the package, runs the package's tests, formats the package's documentation, etc.)
I don't know why it would take 18 hours, and I don't see a bug report linked.
Maybe the author was just doing a commit to their own random GitHub repo, without telling the Racket packages repository, and so waited for the packages repository to do a periodic scan of all third-party packages' random Git/Web sources for new versions? (I'd always go to the Racket package repo Web UI, and push a button of some kind there, and the new version would go through promptly.)
> Do I want to worry about packaging and deploying Racket code or could I simply do the same in most other languages without any fuss? I tried packaging Racket in Nix, it did not go well.
What didn't go well? Racket runs on a wide variety of systems. I once experimentally packaged it for plastic OpenWrt routers, and it was straightforward. https://www.neilvandyke.org/racket-openwrt/
That was a helpful bug report, and looks like Matthew Flatt followed up on it promptly, and the bug report even got Matthias Felleisen's interest.
Then, given Racket's emphasis on cross-platform and backward-compatibility, Matthew's decision to add the semantics support without breaking production for all of the existing users. That seems reasonable and predictable to me.
> Do I want to force users to adopt an application written in a language that uses at the very least 122M resident memory on my workstation? Or do I consider Python or Guile which both use less than 10M?
I don't know how the author is running their code, so this might be the best Racket can do with the code, or maybe...
DrRacket (IDE) can run code with very heavy debugging instrumentation, and you can also do similar things from the command line.
DrRacket also has a feature that limits memory usage to a specified amount, IIRC defaulting to 128MB, which is great for alerting programmers on workstations with multi-gigabytes of RAM that they might be doing something inefficient.
Code can be run from source files (silently compiling/recompiling on demand and caching for later runs), from the compiled form, or into a more packaged form (which IIRC does some tree-shaking).
What libraries you pull in can also mean surprises (e.g., I see a later comment by author in which they mention a third-party package having inappropriate dependencies).
If you want to run in really tight memory, that will affect how you program, and will include an awareness of the garbage collector.
But also, small executable size probably isn't a top priority for Racket.
> Do I want to force users to package Racket which itself has no clear custody of its build inputs - can you produce a Racket tarball yourself that is exactly like the one on the release site? Who knows what’s in those tarballs!
I suspect the author is talking here about what's now called "reproducible builds".
> Do I want to invest in a community without a mechanism to apply community feedback constructively? RFCs?
The author got Matthew Flatt and even Matthias Felleisen giving prompt attention to the bug report they linked.
They'll find similar responsiveness on the mailing list.
> Do I want to write 4x the code (in Racket) because I forgot my secret move was actually all the pypi packages that I took for granted in Python?
Depends what you need to do. The normal case, with programmers who are performing at normal levels and with normal practices is just to using PyPI (or NPM, or Cargo, or whatever), and bang out a solution to a normal problem.
But if you need to do something unusual, or you have programmers who are super-effective and can even judiciously bang out that reusable code as needed (better than the reused packages), then consider getting out of their way -- whether they just do it in Python or NodeJS, or they say this will go better in Racket, Rust, or something more exotic.
> Do I want to wonder about what was meant by “contributions welcome” when most of the core racket codebases at best have a README, at worst have no contributor documentation?
Documentation is one of Racket's strengths. From near the top of https://docs.racket-lang.org/ , see, for example, the document "Building, Distributing, and Contributing to Racket".
> Do I want to invest in a platform where leadership is building Rombus a.k.a. Racket2 instead of focusing on making core Racket just that much better and easier to adopt? (see also: Future of Racket.)
That's a good question. Racket is solid for production, has features that other languages still haven't discovered or done as well, and the author saw the prompt attention to their bug report. (The Rhombus thing has been going on much longer.)
> Do I want to wait 10+ minutes for my package to build in CI because some other package maintainer decided to pull in racket or racket-doc (which pulls in the entire big Racket distribution)?
Talk to the developer of that third-party package?
> Do I want to ship multi-gigabyte docker images because of the above kitchen sink package?
Talk to the developer of that third-party package, and there might be additional things you can do.
> Do I want to deal with being blocked due to not understanding how to use the less understood features of racket such as continuations, syntax-parse/syntax-case macros, units/signatures? You’ll want to know about all these things to write effective Racket code.
You'll need to understand first-class continuations to work on all the Racket internals as a compiler developer. But I don't recall ever seeing a non-internals use of that.
For the syntax extension mechanisms, you can learn that as-needed and at your own pace, because it's for things that most languages can't do (and does it better than languages that can). And you can definitely learn them incrementally, and start with the higher-level forms, which might just do what you need.
Units/signatures are ancient, and you probably don't need to use them. Just use the very nice module system (including submodules), and then decide whether you need more.
> Do I want to add business risk by writing a product in Racket? Does anybody work as an industry Racket coder at all? Would I struggle to hire more talent?
It's probably needless additional risk/unknown to use for business unless you have more or more people who are able to dig in and figure out technical stuff without Stack Overflow. (Though there are helpful forums, but you'll need to rise to the occasion more often.)
And one of the the secret weapons of beloved fringe languages/platforms is that they attract those mythical "10x" programmers on basis of technical/aesthetic/community merits rather than employability, so there's more of them than there are great jobs using Racket...
> Do I…. yeah there’s more but let’s move on ;)
(End of the contiguous block, switching to sparse quoting.)
It's quiet most of the time, but picks up when a new person joins or there's a question/idea.
> Or really all the production users? I only found one production user.
There's more than that, including doing spectacular productivity and importance, but there's not many.
One thing the author of the blog post might be realizing is that the Racket professors are generally super-capable, they support production users like most professors couldn't, they'll provide technical support to any random person around the world. They'd love more commercial uptake, but that's been far from their top priority.
> > Do I want to wonder about what was meant by “contributions welcome” when most of the core racket codebases at best have a README, at worst have no contributor documentation?
Historically all repos were in `racket/racket`.
When the repo was split into `racket/racket`, `racket/drracket` etc no readmes were added. This could be improved for sure -- but is it really that hard to ask
in an appropriate forum such as Racket Discourse or Racket Discord?
If a question is asked on Discord, then the answer will be lost in Discord as well, not findable via search engines. I personally think the move to Discord was a mistake.
I am not sure whether anything from the Racket Discourse forum is findable via search engines. But that is also merely a JS only forum, so not ideal.
There used to be the Google groups thingy including a mailing list. Google, so not ideal either. But at least it had a mailing list.
It would be great to have a way of communication again, that does not require JS or Google or Discord or any other closed thing or walled garden. Especially for a programming language. Of those listed JS is probably the smallest inconvenience, so if I had a question now, I would probably prefer going to the damn discourse thing to ask it, rather than joining the Discord server.
> But that is also merely a JS only forum, so not ideal. There used to be the Google groups thingy including a mailing list. Google, so not ideal either. But at least it had a mailing list.
I was a long-time skeptic of moving away from the Google Groups list, so I try to be equally vocal in saying that the move to Discourse was handled really well IMO. In fact it is not "a JS-only forum": you do need to sign up in the web UI, but, after that, you can put it in "mailing-list mode" and ignore the website completely, including for starting new threads (see <https://racket.discourse.group/t/how-to-enable-mailing-list-...>). The email interface is important to many Racketeers; if other Discourse instances don't enable it, that's their admin's choice. The Google Groups list had been rendered nearly unusable by spam, and it was never free and open-source software, which Discourse is. (I wrote more detailed thoughts at the time in <https://groups.google.com/g/racket-users/c/RnIAQnZpvh0/m/A78...>.)
On the other hand, I share some of your concerns about Discord (the similar names are unfortunate). But there was never an organized "move to Discord": some people just started talking about Racket there, as people had before, and still do, on IRC and Slack and all sorts of places. People are also regularly nudged to move non-transient conversations to searchable and archived venues.
> If a question is asked on Discord, then the answer will be lost in Discord as well, not findable via search engines.
That's why I put Discourse first.
> I am not sure whether anything from the Racket Discourse forum is findable via search engines.
It is.
> There used to be the Google groups thingy including a mailing list.
The mailing list is still running. But people have moved on to Discourse.
You can configure Discourse to send you digest mails, if you prefer mailing lists.
Personally, I liked the mailing list. However, forums such as Discourse have replaced the role of the mailing list. See the forums for Swift, Rust, Processing, etc. They have all moved on to Discourse.
> I don't know why it would take 18 hours, and I don't see a bug report linked.
It seem systematic to the current architecture or developer experience - since the build environment is different than the local environment, there's going to be stuff that leaks through. For example, missing info.rktd dependencies, native dependencies, not pushing changes to dependencies that were on your local machine but not on pkgs.racket-lang.org yet (breaking api changes, additions), sometimes one gets 5xx errors from the frontend so that doesn't help.
When one clicks the "rebuild" button it simply queues the package to be rebuilt. Then you wait and hope everything is working. And come back to address the above issues.
> Then, given Racket's emphasis on cross-platform and backward-compatibility, Matthew's decision to add the semantics support without breaking production for all of the existing users. That seems reasonable and predictable to me.
Bottom line, any language that tries to break away from filesystem semantics of your host OS, is going to cause footguns. Sometimes it's okay to break backwards compatibility.
> What didn't go well? Racket runs on a wide variety of systems. I once experimentally packaged it for plastic OpenWrt routers, and it was straightforward. https://www.neilvandyke.org/racket-openwrt/
My rule is if it isn't packaged in my OS, it doesn't exist in a redistributable form. Racket isn't quite there yet; there's some effort underway to package Racket packages on various operating systems such as Nix, Gentoo, and so on.
> The author got Matthew Flatt and even Matthias Felleisen giving prompt attention to the bug report they linked.
It's true, however a formal process to discuss feedback and next steps for Racket would help folks like myself feel confident in the direction of Racket. Otherwise it's just people on the internet saying "trust me".
> Talk to the developer of that third-party package?
Unfortunately I have found not everyone is interested in fixing their packages. I think this problem might be best fixed by making changes to the package manager to improve the developer experience. My usual work around is to vendor code.
> Units/signatures are ancient, and you probably don't need to use them. Just use the very nice module system (including submodules), and then decide whether you need more.
Is it possible to set up a unloadable plugin architecture without signatures and units?
> There's more than that, including doing spectacular productivity and importance, but there's not many.
I look forward to learning more about these users.
The package server maintains a catalog of available packages.
When you submit a new package, it is more or less immediately
registered in the catalog. This means other users can
try your package quickly.
What takes time is the build server.
The build server builds every package available on the package server.
The build server
- builds the package in a sandboxed environment
- builds documentation
This takes time, since packages can refer to each other.
The advantage is that the documentation can use scope information
to link all identifiers to the correct sentry in the docs.
It would be nice for some improvements though:
- getting a mail when the build is done
- incremental build of packages that no other packages rely on
> Do I want to iterate every 18 hours waiting for the pkgs.racket-lang.org build server to finish building my package? Then do it again because the build failed (my mistake, but now my users have to wait until later that week…)?
( https://pkgs.racket-lang.org/ is one way of sharing an open source package, through a public repository analogous to PyPI. There is a small delay upon uploading a new package/version, because the server builds the package, runs the package's tests, formats the package's documentation, etc.)
I don't know why it would take 18 hours, and I don't see a bug report linked.
Maybe the author was just doing a commit to their own random GitHub repo, without telling the Racket packages repository, and so waited for the packages repository to do a periodic scan of all third-party packages' random Git/Web sources for new versions? (I'd always go to the Racket package repo Web UI, and push a button of some kind there, and the new version would go through promptly.)
> Do I want to worry about packaging and deploying Racket code or could I simply do the same in most other languages without any fuss? I tried packaging Racket in Nix, it did not go well.
What didn't go well? Racket runs on a wide variety of systems. I once experimentally packaged it for plastic OpenWrt routers, and it was straightforward. https://www.neilvandyke.org/racket-openwrt/
> Do I want to invest trust in a programming platform that considers umask of optional importance? https://github.com/racket/racket/issues/4511
That was a helpful bug report, and looks like Matthew Flatt followed up on it promptly, and the bug report even got Matthias Felleisen's interest.
Then, given Racket's emphasis on cross-platform and backward-compatibility, Matthew's decision to add the semantics support without breaking production for all of the existing users. That seems reasonable and predictable to me.
> Do I want to force users to adopt an application written in a language that uses at the very least 122M resident memory on my workstation? Or do I consider Python or Guile which both use less than 10M?
I don't know how the author is running their code, so this might be the best Racket can do with the code, or maybe...
DrRacket (IDE) can run code with very heavy debugging instrumentation, and you can also do similar things from the command line.
DrRacket also has a feature that limits memory usage to a specified amount, IIRC defaulting to 128MB, which is great for alerting programmers on workstations with multi-gigabytes of RAM that they might be doing something inefficient.
Code can be run from source files (silently compiling/recompiling on demand and caching for later runs), from the compiled form, or into a more packaged form (which IIRC does some tree-shaking).
What libraries you pull in can also mean surprises (e.g., I see a later comment by author in which they mention a third-party package having inappropriate dependencies).
If you want to run in really tight memory, that will affect how you program, and will include an awareness of the garbage collector.
But also, small executable size probably isn't a top priority for Racket.
> Do I want to force users to package Racket which itself has no clear custody of its build inputs - can you produce a Racket tarball yourself that is exactly like the one on the release site? Who knows what’s in those tarballs!
I suspect the author is talking here about what's now called "reproducible builds".
> Do I want to invest in a community without a mechanism to apply community feedback constructively? RFCs?
The author got Matthew Flatt and even Matthias Felleisen giving prompt attention to the bug report they linked.
They'll find similar responsiveness on the mailing list.
> Do I want to write 4x the code (in Racket) because I forgot my secret move was actually all the pypi packages that I took for granted in Python?
Depends what you need to do. The normal case, with programmers who are performing at normal levels and with normal practices is just to using PyPI (or NPM, or Cargo, or whatever), and bang out a solution to a normal problem.
But if you need to do something unusual, or you have programmers who are super-effective and can even judiciously bang out that reusable code as needed (better than the reused packages), then consider getting out of their way -- whether they just do it in Python or NodeJS, or they say this will go better in Racket, Rust, or something more exotic.
> Do I want to wonder about what was meant by “contributions welcome” when most of the core racket codebases at best have a README, at worst have no contributor documentation?
Documentation is one of Racket's strengths. From near the top of https://docs.racket-lang.org/ , see, for example, the document "Building, Distributing, and Contributing to Racket".
> Do I want to invest in a platform where leadership is building Rombus a.k.a. Racket2 instead of focusing on making core Racket just that much better and easier to adopt? (see also: Future of Racket.)
That's a good question. Racket is solid for production, has features that other languages still haven't discovered or done as well, and the author saw the prompt attention to their bug report. (The Rhombus thing has been going on much longer.)
> Do I want to wait 10+ minutes for my package to build in CI because some other package maintainer decided to pull in racket or racket-doc (which pulls in the entire big Racket distribution)?
Talk to the developer of that third-party package?
> Do I want to ship multi-gigabyte docker images because of the above kitchen sink package?
Talk to the developer of that third-party package, and there might be additional things you can do.
> Do I want to deal with being blocked due to not understanding how to use the less understood features of racket such as continuations, syntax-parse/syntax-case macros, units/signatures? You’ll want to know about all these things to write effective Racket code.
You'll need to understand first-class continuations to work on all the Racket internals as a compiler developer. But I don't recall ever seeing a non-internals use of that.
For the syntax extension mechanisms, you can learn that as-needed and at your own pace, because it's for things that most languages can't do (and does it better than languages that can). And you can definitely learn them incrementally, and start with the higher-level forms, which might just do what you need.
Units/signatures are ancient, and you probably don't need to use them. Just use the very nice module system (including submodules), and then decide whether you need more.
> Do I want to add business risk by writing a product in Racket? Does anybody work as an industry Racket coder at all? Would I struggle to hire more talent?
It's probably needless additional risk/unknown to use for business unless you have more or more people who are able to dig in and figure out technical stuff without Stack Overflow. (Though there are helpful forums, but you'll need to rise to the occasion more often.)
And one of the the secret weapons of beloved fringe languages/platforms is that they attract those mythical "10x" programmers on basis of technical/aesthetic/community merits rather than employability, so there's more of them than there are great jobs using Racket...
> Do I…. yeah there’s more but let’s move on ;)
(End of the contiguous block, switching to sparse quoting.)
> Where did the racket-money mailing list go?
https://www.neilvandyke.org/racket-money/
It's quiet most of the time, but picks up when a new person joins or there's a question/idea.
> Or really all the production users? I only found one production user.
There's more than that, including doing spectacular productivity and importance, but there's not many.
One thing the author of the blog post might be realizing is that the Racket professors are generally super-capable, they support production users like most professors couldn't, they'll provide technical support to any random person around the world. They'd love more commercial uptake, but that's been far from their top priority.