4 ms·

It's disappointing that this is the state of things from a "working programmer" perspective. Racket is, as far as I understand, a research and teaching languag

It's disappointing that this is the state of things from a "working programmer" perspective. Racket is, as far as I understand, a research and teaching language, as well as a viable scheme. I've used it for some [command line tools and side projects][1], but I never tried to deploy anything with it. Maybe a new [Chez][2]-based (as Racket now is) scheme is needed: one with much of Racket's nice syntax system, but focused on dependency management, targeted solely at "production" use, and other Serious Business Purposes. Not it! I'm not saying that Racket isn't a serious platform -- far from it. But the author's concerns, while expressed as a hot take, might be why Racket doesn't see wider industry adoption. Or maybe it's a chicken and egg problem. [1]: https://github.com/dgoffredo?tab=repositories&q=&type=&language=racket https://github.com/dgoffredo?tab=repositories&q=&type=&langu... [2]: https://www.scheme.com/ https://www.scheme.com/

kej 3y ago
> Or maybe it's a chicken and egg problem. Maybe Chicken Scheme is the solution, then? http://www.call-cc.org/ http://www.call-cc.org/
- pg_1234 3y ago
  Chicken Scheme is great, but for production use you need an ecosystem. For this reason Clojure and perhaps SBCL will dominate serious lisp dev. Racket is a classic example of those peculiarly dysfunctional systems that emerge from an out of touch (dare I say ivory tower) academic community who think hype and prototypes are one step away from being enterprise ready.
znpy 3y ago
I don’t see equivalent sobbing when somebody praise lets say Rust (random choice) for being productive, for the easiness of working with cargo or some other random stuff from the “working programmer perspective”. Is this sad only when people have to talk about their pain points?
- winny314 3y ago
  Op here. It's important to recognize pain points so we do not become complacent with low quality developer experiences. Worse, complacency with software lifecycle at scale - will our product deploy on a cluster? Will our software be maintainable 5 years from now? Better we look at the pain points now than accept a poor DX for years to come.
- aidenn0 3y ago
  Totally ignoring your point and ranting about how much I hate Rust from easiness of working with. Not the language itself (which I love) I can write code so quickly in it, and I didn't struggle for very long with fighting the borrow checker, which seems to turn so many other people off. It's everything else. Long build times. "Modern" dependency management, which seems to mean package X only works with 0.6.x of package Z and package Y only works with 0.7.x of package Z and the current version of package Z is 0.8 and has a bugfix you really need. Though I should say that very few languages with a central repository don't have this problem; you make it easy to depend on libraries with unstable APIs and everyone will rush to do it.
  - jandrese 3y ago
    So many people rushed to copy the node/Python dependency management system that nobody asked if it was really a good idea. I totally agree that nailing everything down to the one particular minor rev causes way more problems than it solves. The worst part is I'm pretty sure you can be more general (give me version 3, or >3.3.1, not =3.3.1) but all of the automatic tools and online guides default to nailing it down to exactly one version because they're so damn paranoid about API changes. I will say that CPAN somehow avoided this problem. I think that is mostly because Perl programmers are far less liberal with dependencies, you don't typically see programs pulling in dozens or hundreds of modules the way you do in node projects. But it's remarkable how many old Perl programs can still pull the dependencies and start right up.
    - pphysch 3y ago
      > But it's remarkable how many old Perl programs can still pull the dependencies and start right up. I was surprised when I installed `git` and it pulled a couple dozen Perl packages from the distro repo. There's definitely something to be said about Linux distro maintainers/packagers being sort of middlemen that help enforce compatibility for popular Perl (or Python2, etc) packages. That is, there is a nonzero amount of greybeards between the developer and random end user, which cannot be said for your average npm or pip package.
zitterbewegung 3y ago
I have daydreamed about making Racket more serious and calling it Tennis.
- faitswulff 3y ago
  How about less serious and calling it Badminton?

kej 3y ago

> Or maybe it's a chicken and egg problem. Maybe Chicken Scheme is the solution, then? http://www.call-cc.org/ http://www.call-cc.org/

pg_1234 3y ago
Chicken Scheme is great, but for production use you need an ecosystem. For this reason Clojure and perhaps SBCL will dominate serious lisp dev. Racket is a classic example of those peculiarly dysfunctional systems that emerge from an out of touch (dare I say ivory tower) academic community who think hype and prototypes are one step away from being enterprise ready.

znpy 3y ago

I don’t see equivalent sobbing when somebody praise lets say Rust (random choice) for being productive, for the easiness of working with cargo or some other random stuff from the “working programmer perspective”. Is this sad only when people have to talk about their pain points?

winny314 3y ago
Op here. It's important to recognize pain points so we do not become complacent with low quality developer experiences. Worse, complacency with software lifecycle at scale - will our product deploy on a cluster? Will our software be maintainable 5 years from now? Better we look at the pain points now than accept a poor DX for years to come.
aidenn0 3y ago
Totally ignoring your point and ranting about how much I hate Rust from easiness of working with. Not the language itself (which I love) I can write code so quickly in it, and I didn't struggle for very long with fighting the borrow checker, which seems to turn so many other people off. It's everything else. Long build times. "Modern" dependency management, which seems to mean package X only works with 0.6.x of package Z and package Y only works with 0.7.x of package Z and the current version of package Z is 0.8 and has a bugfix you really need. Though I should say that very few languages with a central repository don't have this problem; you make it easy to depend on libraries with unstable APIs and everyone will rush to do it.
- jandrese 3y ago
  So many people rushed to copy the node/Python dependency management system that nobody asked if it was really a good idea. I totally agree that nailing everything down to the one particular minor rev causes way more problems than it solves. The worst part is I'm pretty sure you can be more general (give me version 3, or >3.3.1, not =3.3.1) but all of the automatic tools and online guides default to nailing it down to exactly one version because they're so damn paranoid about API changes. I will say that CPAN somehow avoided this problem. I think that is mostly because Perl programmers are far less liberal with dependencies, you don't typically see programs pulling in dozens or hundreds of modules the way you do in node projects. But it's remarkable how many old Perl programs can still pull the dependencies and start right up.
  - pphysch 3y ago
    > But it's remarkable how many old Perl programs can still pull the dependencies and start right up. I was surprised when I installed `git` and it pulled a couple dozen Perl packages from the distro repo. There's definitely something to be said about Linux distro maintainers/packagers being sort of middlemen that help enforce compatibility for popular Perl (or Python2, etc) packages. That is, there is a nonzero amount of greybeards between the developer and random end user, which cannot be said for your average npm or pip package.

zitterbewegung 3y ago

I have daydreamed about making Racket more serious and calling it Tennis.

faitswulff 3y ago
How about less serious and calling it Badminton?