11 ms·

Racket frustrates me

122 points by lycopodiopsida 3y ago

https://web.archive.org/web/20240110183908/https://blog.winny.tech/posts/racket-frustrates-me/ https://web.archive.org/web/20240110183908/https://blog.winn...

MathMonkeyMan 3y ago
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.
- 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?
akkartik 3y ago
I don't use Racket much, but Python certainly frustrates me. So what I want to know is where people land when all these languages frustrate them. Builds taking too long seems like a perennial problem, for example. (Currently I work in LÖVE, but programs there use at least 100MB, so it probably won't be to OP's taste.)
- proxyon 3y ago
  Typescript. Kotlin. Java. I cannot imagine going back to Python, Ruby or PHP after using modern languages like these. Also, Java performance is good enough. Why did anyone ever abandon Java? It's easy to read, easy to write and pleasant enough to work with. If you need C level performance, by all means go with C, Go, Rust but Java to me is perfect, and Typescript is good enough for everything else.
  - adamc 3y ago
    In part, because the Java ecosystem kept getting more complicated. Fifteen or so years ago I was a full-time Java developer, but I wouldn't know half of what I need to know today, and I'm not very interested in going that route. Java kept the language simple-ish (not really, because they have added a lot on top of it), but the stack grew rapidly, and you have to know the tooling to function in that environment. Python remains a lot simpler. It is getting more complex, but it has miles to go before it reaches Java-land.
  - nightfly 3y ago
    > Why did anyone ever abandon Java Boilerplate code. Java applications (mostly picking on tomcat here) being pretty much their own world of configuration, with lots of different places to look. Slow startup time pretty much kills it for lots of things I'd wanna write. It's memory management stuff sucks, from a sysadmins perspective. Any java application I deploy takes easily multiple times more memory than anything similar in a non-JVM language.
    - mst 3y ago
      I've seen some slim running JVM stuff by developers who actually bothered to care about it - under 25Mb slim. Yes, lots of Java apps basically go "lol .... KABOOM" if you give them less than half a gig of RAM to play around in, but IMO that's a tragedy of the commons like thing within the ecosystem where common approaches mean you end up with layer upon layer of libraries none of which thought -their- RAM use was particularly egregious. At this point, it's not the runtime's fault (G1 is excellent), and while you could argue that the language design led developers to do things wrong I think it's more a culture phenomenom - I think I might consider blaming J2EE and its proponents rather than the language itself. Of course, from a sysadmin point of view, the runtime+application combination's memory usage is what matters in practice, I'm just saying the reason why you find yourself staring at the screen thinking "wait, it's using how much?!" is more complicated than "Java's memory management stuff sucks"
tryptophan 3y ago
Language ecosystem is more important than the language itself. Typing 5 lines of code because of fancy syntax is nice, but writing 20 doesn't take a significant amount of time. What does take tons of time however is figuring build systems, packaging, distribution, debugging, editor support, documentation, community, libraries, etc... I'm surprised no new languages focus on ecosystem. It is much less fun than making clever syntax I suppose.
- remexre 3y ago
  > I'm surprised no new languages focus on ecosystem. It is much less fun than making clever syntax I suppose. Honestly, this is a lot of the draw of Go and Rust for a lot of people; other than debugging (which I can't speak to from experience, but as I understand it, both are on par with C++), the points you hit on above are all things Go and Rust have really solid answers to compared to their contemporaries.
- cogman10 3y ago
  > I'm surprised no new languages focus on ecosystem. It is much less fun than making clever syntax I suppose. Most new languages that I know of have a package manager/inbuilt dependency resolution mechanism and a fairly robust module system to try and support 3rd party dependencies. Rust, Go, Dart, D. You can expect every language post 2010ish to have this.
  - throwboatyface 3y ago
    Pretty funny to say package management is table stakes and use go as an example. For a long time they had nothing, then hacky workarounds, and now they have a first party hacky workaround
    - anacrolix 3y ago
      I agree. I've been using Go as my primary language since 2011. Its package management has always been fairly simple, but deficient. Go modules have made things more accessible, but it lacks serious features and actually has quite a few bugs and edge cases. Every time I use cargo I'm blown away, it's incredible. People often gloss over Go and lump it in with Rust which is giving it far too much credit.
whalesalad 3y ago
higher resident memory is not ideal, but is it a dealbreaker? Anyhoot - I think clojure is the best lisp there is right now, but for better or worse it is tied to the jvm and seems to be stagnating.
- Jach 3y ago
  Do you use Clojure? I'd give the title of best Lisp to Common Lisp, the Actually Lisp -- it's so Lisp it even has Lisp in its name and runs decades of Lisp code, something neither Clojure nor Racket can do any more easily than Python. I suspect many of the author's frustrations would go away if he just used CL... though he'd find new ones for sure.
  - aidenn0 3y ago
    High RSS being a dealbreaker for OP rules out most lisps. ECL might be low enough, but certainly SBCL and CCL will be too high.
    - schemescape 3y ago
      Try CLISP. It uses a VM, so it's much simpler and uses less memory (but is slower, obviously).
- norir 3y ago
  High RSS makes me wonder how well the language is designed and implemented. Luajit gives you many of the things racket does (and can be easily extended to add any racket feature) without having crazy high RSS. Even though it may seem minor, it gives me a lot more confidence that at a minimum, luajit isn't _badly_ designed.
kaushalvivek 3y ago
I had a professor at college who mandated Racket as the mode of learning for a software engineering course. I remember how Racket just ended up taking centre stage, figuring language-specific concepts and hacks out let the larger engineering concepts fade into the background. I did not learn much in that course.
- paulddraper 3y ago
  Did we go to the same college? :) In seriousness, Racket is semi-commonly used in educational settings. Especially for "functional programming"-type courses.
- dangrover 3y ago
  Northeastern, Rice?
  - stephenhuey 3y ago
    He went to IIIT Hyderabad if I found the right Samsung-associated guy of the same name on LinkedIn. I went to Rice when Racket was Scheme and definitely it got pushed hard on me, at least in the intro CS course. :) But that was back when CS was one of the smallest majors, and now it's the largest at Rice and their curriculum is quite different!
- armchairhacker 3y ago
  Can you give specific examples? I’m not doubting you. I’m interested in what parts of Racket could be confusing to beginners, maybe to make better courses
- goda90 3y ago
  My professor for "Programming Language Concepts" was a contributor to Racket and it was center stage of the class. He did his lectures in DrRacket. He did a great job building up from principles to explain things, but was also very opinionated and had very high standards for homework. It was a tough class for me.
- chongli 3y ago
norir 3y ago
It is surprising to me that academics would not think that it is worth optimizing RSS for hello, world.
kazinator 3y ago
There is no situation in which your language doesn't impact your productivity to some degree, sorry. When you've put 40,000 lines into the program, and your language is suddenly impacting your productivity more than you like, you can't just drop all that and switch! Your language has you hostage. "If you don't like the dent I'm putting in your productivity, go rewrite 40,000 lines in something else. Mouhaha!"
wouldbecouldbe 3y ago
[flagged]
zitterbewegung 3y ago
I tried using racket to do something useful and totally failed each time. Even if you are a single programmer making some kind of prototype I think we have gotten beyond the stage of picking a small language. Also, doing a rewrite into an Ml style language is really strange when they should probably be trying to become more competitive with other languages by building more batteries for it or fixing fundamental problems that were outlined here.
- serf 3y ago
  >Even if you are a single programmer making some kind of prototype I think we have gotten beyond the stage of picking a small language. in what world does racket get classified as a 'small language'? it was one of the originals who focused on the 'batteries included' aspect for the sake of being more applicable in education.
- priime0 3y ago
  > Also, doing a rewrite into an Ml style language is really strange when they should probably be trying to become more competitive with other languages by building more batteries for it or fixing fundamental problems that were outlined here. From what I know, Rhombus and Racket are parallel, mutually-beneficial projects. The development of Rhombus has contributed smaller features into Racket, while showcasing Racket's capability for language development. Rhombus is, in a sense, filling in gaps that Racket may be missing.
deleted 3y ago
[deleted]
latenightcoding 3y ago
Something that I find a little concerning about Racket is that AFAIK there are no alternative implementations. (Clojure and Common Lisp have a couple). Why is that? is it too complex?
- Jtsummers 3y ago
  Racket itself came from PLT Scheme which was based on the Scheme standard (R5RS or R6RS at the time of Racket's diverging, can't recall which, wasn't paying much attention). It's still a fairly new language (13 years old now) and was largely Scheme compatible most of that time (still is, actually, if you stick to `#lang racket`, but not 100%). It also has no published standard, in this regard it's somewhat like Rust and others where to make an alternative implementation you've got to reverse engineer (fortunately it's open source) aspects of the current implementation. So it's not like you can just pick up R8RR (since it's on version 8, and keeping with the naming convention of Scheme standards as in R5RS) and start building something. Common Lisp also has a standard for implementers to follow, and is about 25 years older than Racket. That's given implementers a bit more time. Regarding Clojure, what's the status/quality of all the other implementations?
  - alwaysbeconsing 3y ago
    I believe Racket goes back further than 13 years. I clearly recall using Dr Racket in the early 00's
    - Jtsummers 3y ago
      It was DrScheme in the 00s. They changed the name to Racket and DrRacket in 2010. https://blog.racket-lang.org/2010/06/racket.html https://blog.racket-lang.org/2010/06/racket.html https://www.racket-lang.org/new-name.html https://www.racket-lang.org/new-name.html
- kazinator 3y ago
  Racket is a Scheme dialect (sort of), which has multiple implementations. People might be confused by the name Racket; it was clearer when it was called PLT Scheme. Common Lisp has more than a couple of implementations, especially when we take a historic view. However, say, Steel Bank Common Lisp has only one implementation.
yard2010 3y ago
[dead]
placesalt 3y ago
There's a live coding talk by John Carmack where he uses Racket for making small programs for the Oculus: https://www.youtube.com/watch?v=ydyztGZnbNs https://www.youtube.com/watch?v=ydyztGZnbNs He seemed happy enough with the language.
zelphirkalt 3y ago
Some of the points are probably valid. But some I do not see as quite so valid: Many other deployments work similarly. Make a docker container and put it anywhere. Are Racket docker containers necessarily that much bigger than lets say Python ones or GNU Guile ones? Racket is packaged in GNU Guix btw., even, if I have had mixed experiences with the package, it should be mentioned. So someone already succeeded in packaging it in the package manager, that once was derived from Nix. > 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? This really depends on what kind of code you are writing. When I wrote some Racket programs, I used mostly built-ins or perhaps 1 or 2 dependencies. Depending on the project, maybe one needs more of those dependencies and writing them oneself would be too much work. But for simple dependencies that are easy to write oneself, I wouldn't want to use a dependency from PyPI. > 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. Hm, I don't know whether you want to. Do you want to be a capable programmer understanding more language concepts, being able to apply them perhaps in your next project or when learning your next language? Do you want to be able to express things elegantly than possible in Python for example? Do you want to know Scheme things? If not then OK, we all make our choices. I personally don't think it is good to avoid learning about something like continuations and stumble on without such knowledge as a programmer, but in more mainstream languages it probably is sufficient. However, one can also write lots of effective Racket code without going into macros. One does not have to follow the idea of having to make a language. > But then the real hard truths started to appear. I was losing a lot of productivity. The productivity losses were incremental but certainly slowed down my velocity significantly over the last seven years. Sure the language has a lot of wonderful features, but there’s more to a good programming language than well, its programming language. This is probably the most important point raised. I hope though, that people who run into any shortages with Racket consider building the thing they are missing, if they are able to, to add to the ecosystem and to avoid the next person running into the same thing lacking. If no one ever writes their own, we will only ever stick with the status quo in terms of programming languages. (And fortunately people do write their own often.)
- 3y ago
JimmyRuska 3y ago
Macros feel magical, this idea you can make your own language in no time so long as it's s-expression based, and make your own personalized vocabularies, expression flows, fit to purpose. Personal computing at its best! But from a working-with-other people perspective, imagine opening some code and finding random invented constructs you have to reverse engineer and step through. These days it seems everyone creates yaml or json files, and then implements some kind of declarative engine or interpreter to implement their DSL. This can be both easier to read and debug. For more complicated use cases you can tie it to a graph database that supports reasoning, instead of json/yaml Even so, is there really something that can be done with macros that can't be done, just as elegantly, with simple state machines, or object composition style in other languages?
- memling 3y ago
  > But from a working-with-other people perspective, imagine opening some code and finding random invented constructs you have to reverse engineer and step through This feels just like working with another API to me. Macros can be arbitrarily complicated I suppose, but is the typical usage any more complex than learning an API? I don't really know, I guess, but my experience hasn't shown this to be that challenging. I can appreciate that programming languages are ultimately codifying a particular way to think about computation, and macros express more idiosyncratic ways of thinkingabout comouting that may not be readily understandable. I do think Racket has issues, but this isn't the first one I would cite.
- kagevf 3y ago
  > is there really something that can be done with macros that can't be done, just as elegantly, with simple state machines My guess would be a C# using block. I think the Java equivalent is "try with resources" but I don't remember. In Common Lisp it'd be WITH-OPEN-FILE, or a similar macro made on top of UNWIND-PROTECT ... > or object composition style builder pattern comes to mind :)
- kazinator 3y ago
  > finding random invented constructs you have to reverse engineer and step through Like functions and procedures? I would pray that a good number of them are compile-time code transformers that execute in the comfortable development environment, so I don't have to reverse engineer and step through them on the embedded target.
soulbadguy 3y ago
Some good points, but i find the tone a bit off. I have been eyeing racket for a while now, but could never quite make the jump. Racket (the programming language) has definitely a lot of potential, but i do believe the academic side of it and the focus on the "build your own language" part might be an impediment to racket growth. If i was to suggest some stuff : - Clearly split Racket (and typed Racket) the language, evolution of scheme and Racket the PLT framework use to build and construct new languages. Racket / typed Racket should focus on more production/libraries for regular programmer - More examples/libraries/package not directly related to PL and PL teaching. Create a website solely for Racket/typed racket, with the academic part. - DrRacket always felt and looked alien to me. I can't really judge the feature set, but having vscode as the defacto IDE i think would be it more welcoming - This one is will definitively be controversial but introduce a "curly brace"/C style syntax for Racket. Something implemented at the reader level. Same semantic/runtime behavior, and a reader/printer to go between Racket and {C|rust}SyntaxedRacket. That's a lot of effort, so why do this ? I believe the world is looking for a better python. There is a lot of contender right now (julia, nim , etc... etc...). I think racket should also throw their hat in the ring.
- priime0 3y ago
  > Clearly split Racket (and typed Racket) the language, evolution of scheme and Racket the PLT framework use to build and construct new languages. It's very much possible to use Racket without interacting with macros and language-building features. > Racket / typed Racket should focus on more production/libraries for regular programmer Libraries are dependent on the community, which unfortunately is comprised of mostly academic folk at the moment. > DrRacket always felt and looked alien to me. I can't really judge the feature set, but having vscode as the defacto IDE i think would be it more welcoming I do agree -- if I remember correctly, DrRacket was primarily built as a pedagogic IDE, not one meant for more professional use. VSCode, however, does have the "Magic Racket" extension. > This one is will definitively be controversial but introduce a "curly brace"/C style syntax for Racket. Not necessarily C-style syntax, but you could take a look at Rhombus. It's meant to have a more approachable syntax compared to S-expressions.
  - 3y ago
ashton314 3y ago
> Coding is a tool to get stuff done. Sure, that’s one of its roles. Racket helps me think. Maybe I’m lucky, and work on genuinely novel problems where a malleable language beats libraries. So, sure, the Racket ecosystem leaves much to be desired, but getting stuff done is only one of programming’s roles.
- namaria 3y ago
  People who use that argument are the same ones saying 'sure, I can do it in an afternoon/by tomorrow', and leave a trail of accumulating tech debt in their wake. It's a solid career move, what can I say? You get noticed for being such a sport and result oriented, and if you've got that service attitude, you get promoted/hired out of having to maintain that mess.
  - ashton314 3y ago
    No. Some? Maybe. All? No. I worked at a few companies where, when I needed to model a tricky system and build out an algorithm to do a tricky job, I turned to Racket as a draft. Once I got a POC done, we’d turn around and build it For Real™. If all you’ve ever done is work as an implementer, then yeah, this flow doesn’t make much sense. But I think for people who work as problem discoverers, this is more common than not.
patrec 3y ago
Life lesson: don't waste 7 years of your life and and personal growth on some weird fringe language, you will not get them back. It can pay off to make a serious commitment to a non-mainstream technology, but basically only if it allows you to do some very concrete things that give you a big competitive advantage and that you could not reasonably achieve otherwise. Or if you are both unusually good at predicting the next hot thing, and the timescales are short enough. Racket is not a good bet in either regard (even if it's a great language to learn certain concepts). All the lost productivity the poster is bemoaning could have gone into mastering hard and useful skills instead and these things compound.
- winny314 3y ago
  100% this. It was a risk taken and it didn't pay off.
gus_massa 3y ago
[I'm biased, so I'd focus in some parts I disagree.] > 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…)? I agree it should be improved, but I think that deploying to the package system is something that happens not very often. The idea is to keep only a safe and stable version there. > 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? It would be interesting if the author post in github a feature request for the 3 missing packages that are more painful. (3 is a good numbers to find someone else that care about one of them, more than 3 or 4 would be annoying) > 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)? Sometimes I use minimal-racket, and it's this is annoying. Most people just use the main distribution so this is not a problem. IIUC the author cares about a small footprint, so it's a special case. I use Ctr-C, but I guess there is a trick with raco pkg to do fix this automatically. > 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 can skip most of them to write effective Racket code. I use continuations only as an emergency exit inside nested fors, no fancy stuff. (I agree the fancy stuff is weird.) I think units/signatures is almost deprecated. It will be there forever to keep backward compatibility, but I expect new code to use modules instead of units. About macros: If you are programing alone just use syntax-rule. syntax-case is not so difficult unless you want to do weird stuff. I've done weird stuff in the past, but five years later I regretted it. If you are programing in a team, it's important that the macros have good error checking, because otherwise in case of an error it will expand crap that will expend to more crap and after a few rounds of crap expansion the poor soul that is using it will get a unintelligible error about code they didn't wrote. Here is where syntax-parse is useful, to ensure the initial code makes sense and expand only good code and give a good error reporting otherwise. syntax-parse is almost a separate DSL, so it's a lot to learn. (You can write the same stuff with syntax-case, but syntax-parse automates a lot of stuff.)
- winny314 3y ago
neilv 3y ago
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/ 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/ 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 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/ 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/ 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.
kagevf 3y ago
> 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 I don't know much about scheme or racket, but am aware that continuations is one of its distinguishing features. I've seen people praising syntax-case as a great take on macros. I've never heard of units/signatures, though. I know this was supposed to be a rant, but I wonder what drew the author to want to use scheme/racket in the first place?

https://web.archive.org/web/20240110183908/https://blog.winny.tech/posts/racket-frustrates-me/ https://web.archive.org/web/20240110183908/https://blog.winn...

MathMonkeyMan 3y ago

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.
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?

akkartik 3y ago

I don't use Racket much, but Python certainly frustrates me. So what I want to know is where people land when all these languages frustrate them. Builds taking too long seems like a perennial problem, for example. (Currently I work in LÖVE, but programs there use at least 100MB, so it probably won't be to OP's taste.)

proxyon 3y ago
Typescript. Kotlin. Java. I cannot imagine going back to Python, Ruby or PHP after using modern languages like these. Also, Java performance is good enough. Why did anyone ever abandon Java? It's easy to read, easy to write and pleasant enough to work with. If you need C level performance, by all means go with C, Go, Rust but Java to me is perfect, and Typescript is good enough for everything else.
- adamc 3y ago
  In part, because the Java ecosystem kept getting more complicated. Fifteen or so years ago I was a full-time Java developer, but I wouldn't know half of what I need to know today, and I'm not very interested in going that route. Java kept the language simple-ish (not really, because they have added a lot on top of it), but the stack grew rapidly, and you have to know the tooling to function in that environment. Python remains a lot simpler. It is getting more complex, but it has miles to go before it reaches Java-land.
- nightfly 3y ago
  > Why did anyone ever abandon Java Boilerplate code. Java applications (mostly picking on tomcat here) being pretty much their own world of configuration, with lots of different places to look. Slow startup time pretty much kills it for lots of things I'd wanna write. It's memory management stuff sucks, from a sysadmins perspective. Any java application I deploy takes easily multiple times more memory than anything similar in a non-JVM language.
  - mst 3y ago
    I've seen some slim running JVM stuff by developers who actually bothered to care about it - under 25Mb slim. Yes, lots of Java apps basically go "lol .... KABOOM" if you give them less than half a gig of RAM to play around in, but IMO that's a tragedy of the commons like thing within the ecosystem where common approaches mean you end up with layer upon layer of libraries none of which thought -their- RAM use was particularly egregious. At this point, it's not the runtime's fault (G1 is excellent), and while you could argue that the language design led developers to do things wrong I think it's more a culture phenomenom - I think I might consider blaming J2EE and its proponents rather than the language itself. Of course, from a sysadmin point of view, the runtime+application combination's memory usage is what matters in practice, I'm just saying the reason why you find yourself staring at the screen thinking "wait, it's using how much?!" is more complicated than "Java's memory management stuff sucks"

tryptophan 3y ago

Language ecosystem is more important than the language itself. Typing 5 lines of code because of fancy syntax is nice, but writing 20 doesn't take a significant amount of time. What does take tons of time however is figuring build systems, packaging, distribution, debugging, editor support, documentation, community, libraries, etc... I'm surprised no new languages focus on ecosystem. It is much less fun than making clever syntax I suppose.

remexre 3y ago
> I'm surprised no new languages focus on ecosystem. It is much less fun than making clever syntax I suppose. Honestly, this is a lot of the draw of Go and Rust for a lot of people; other than debugging (which I can't speak to from experience, but as I understand it, both are on par with C++), the points you hit on above are all things Go and Rust have really solid answers to compared to their contemporaries.
cogman10 3y ago
> I'm surprised no new languages focus on ecosystem. It is much less fun than making clever syntax I suppose. Most new languages that I know of have a package manager/inbuilt dependency resolution mechanism and a fairly robust module system to try and support 3rd party dependencies. Rust, Go, Dart, D. You can expect every language post 2010ish to have this.
- throwboatyface 3y ago
  Pretty funny to say package management is table stakes and use go as an example. For a long time they had nothing, then hacky workarounds, and now they have a first party hacky workaround
  - anacrolix 3y ago
    I agree. I've been using Go as my primary language since 2011. Its package management has always been fairly simple, but deficient. Go modules have made things more accessible, but it lacks serious features and actually has quite a few bugs and edge cases. Every time I use cargo I'm blown away, it's incredible. People often gloss over Go and lump it in with Rust which is giving it far too much credit.

whalesalad 3y ago

higher resident memory is not ideal, but is it a dealbreaker? Anyhoot - I think clojure is the best lisp there is right now, but for better or worse it is tied to the jvm and seems to be stagnating.

Jach 3y ago
Do you use Clojure? I'd give the title of best Lisp to Common Lisp, the Actually Lisp -- it's so Lisp it even has Lisp in its name and runs decades of Lisp code, something neither Clojure nor Racket can do any more easily than Python. I suspect many of the author's frustrations would go away if he just used CL... though he'd find new ones for sure.
- aidenn0 3y ago
  High RSS being a dealbreaker for OP rules out most lisps. ECL might be low enough, but certainly SBCL and CCL will be too high.
  - schemescape 3y ago
    Try CLISP. It uses a VM, so it's much simpler and uses less memory (but is slower, obviously).
norir 3y ago
High RSS makes me wonder how well the language is designed and implemented. Luajit gives you many of the things racket does (and can be easily extended to add any racket feature) without having crazy high RSS. Even though it may seem minor, it gives me a lot more confidence that at a minimum, luajit isn't _badly_ designed.

kaushalvivek 3y ago

I had a professor at college who mandated Racket as the mode of learning for a software engineering course. I remember how Racket just ended up taking centre stage, figuring language-specific concepts and hacks out let the larger engineering concepts fade into the background. I did not learn much in that course.

paulddraper 3y ago
Did we go to the same college? :) In seriousness, Racket is semi-commonly used in educational settings. Especially for "functional programming"-type courses.
dangrover 3y ago
Northeastern, Rice?
- stephenhuey 3y ago
  He went to IIIT Hyderabad if I found the right Samsung-associated guy of the same name on LinkedIn. I went to Rice when Racket was Scheme and definitely it got pushed hard on me, at least in the intro CS course. :) But that was back when CS was one of the smallest majors, and now it's the largest at Rice and their curriculum is quite different!
armchairhacker 3y ago
Can you give specific examples? I’m not doubting you. I’m interested in what parts of Racket could be confusing to beginners, maybe to make better courses
goda90 3y ago
My professor for "Programming Language Concepts" was a contributor to Racket and it was center stage of the class. He did his lectures in DrRacket. He did a great job building up from principles to explain things, but was also very opinionated and had very high standards for homework. It was a tough class for me.
chongli 3y ago

norir 3y ago

It is surprising to me that academics would not think that it is worth optimizing RSS for hello, world.

kazinator 3y ago

There is no situation in which your language doesn't impact your productivity to some degree, sorry. When you've put 40,000 lines into the program, and your language is suddenly impacting your productivity more than you like, you can't just drop all that and switch! Your language has you hostage. "If you don't like the dent I'm putting in your productivity, go rewrite 40,000 lines in something else. Mouhaha!"

wouldbecouldbe 3y ago

[flagged]

zitterbewegung 3y ago

I tried using racket to do something useful and totally failed each time. Even if you are a single programmer making some kind of prototype I think we have gotten beyond the stage of picking a small language. Also, doing a rewrite into an Ml style language is really strange when they should probably be trying to become more competitive with other languages by building more batteries for it or fixing fundamental problems that were outlined here.

serf 3y ago
>Even if you are a single programmer making some kind of prototype I think we have gotten beyond the stage of picking a small language. in what world does racket get classified as a 'small language'? it was one of the originals who focused on the 'batteries included' aspect for the sake of being more applicable in education.
priime0 3y ago
> Also, doing a rewrite into an Ml style language is really strange when they should probably be trying to become more competitive with other languages by building more batteries for it or fixing fundamental problems that were outlined here. From what I know, Rhombus and Racket are parallel, mutually-beneficial projects. The development of Rhombus has contributed smaller features into Racket, while showcasing Racket's capability for language development. Rhombus is, in a sense, filling in gaps that Racket may be missing.

deleted 3y ago

[deleted]

latenightcoding 3y ago

Something that I find a little concerning about Racket is that AFAIK there are no alternative implementations. (Clojure and Common Lisp have a couple). Why is that? is it too complex?

Jtsummers 3y ago
Racket itself came from PLT Scheme which was based on the Scheme standard (R5RS or R6RS at the time of Racket's diverging, can't recall which, wasn't paying much attention). It's still a fairly new language (13 years old now) and was largely Scheme compatible most of that time (still is, actually, if you stick to `#lang racket`, but not 100%). It also has no published standard, in this regard it's somewhat like Rust and others where to make an alternative implementation you've got to reverse engineer (fortunately it's open source) aspects of the current implementation. So it's not like you can just pick up R8RR (since it's on version 8, and keeping with the naming convention of Scheme standards as in R5RS) and start building something. Common Lisp also has a standard for implementers to follow, and is about 25 years older than Racket. That's given implementers a bit more time. Regarding Clojure, what's the status/quality of all the other implementations?
- alwaysbeconsing 3y ago
  I believe Racket goes back further than 13 years. I clearly recall using Dr Racket in the early 00's
  - Jtsummers 3y ago
    It was DrScheme in the 00s. They changed the name to Racket and DrRacket in 2010. https://blog.racket-lang.org/2010/06/racket.html https://blog.racket-lang.org/2010/06/racket.html https://www.racket-lang.org/new-name.html https://www.racket-lang.org/new-name.html
kazinator 3y ago
Racket is a Scheme dialect (sort of), which has multiple implementations. People might be confused by the name Racket; it was clearer when it was called PLT Scheme. Common Lisp has more than a couple of implementations, especially when we take a historic view. However, say, Steel Bank Common Lisp has only one implementation.

yard2010 3y ago

[dead]

placesalt 3y ago

There's a live coding talk by John Carmack where he uses Racket for making small programs for the Oculus: https://www.youtube.com/watch?v=ydyztGZnbNs https://www.youtube.com/watch?v=ydyztGZnbNs He seemed happy enough with the language.

zelphirkalt 3y ago

Some of the points are probably valid. But some I do not see as quite so valid: Many other deployments work similarly. Make a docker container and put it anywhere. Are Racket docker containers necessarily that much bigger than lets say Python ones or GNU Guile ones? Racket is packaged in GNU Guix btw., even, if I have had mixed experiences with the package, it should be mentioned. So someone already succeeded in packaging it in the package manager, that once was derived from Nix. > 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? This really depends on what kind of code you are writing. When I wrote some Racket programs, I used mostly built-ins or perhaps 1 or 2 dependencies. Depending on the project, maybe one needs more of those dependencies and writing them oneself would be too much work. But for simple dependencies that are easy to write oneself, I wouldn't want to use a dependency from PyPI. > 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. Hm, I don't know whether you want to. Do you want to be a capable programmer understanding more language concepts, being able to apply them perhaps in your next project or when learning your next language? Do you want to be able to express things elegantly than possible in Python for example? Do you want to know Scheme things? If not then OK, we all make our choices. I personally don't think it is good to avoid learning about something like continuations and stumble on without such knowledge as a programmer, but in more mainstream languages it probably is sufficient. However, one can also write lots of effective Racket code without going into macros. One does not have to follow the idea of having to make a language. > But then the real hard truths started to appear. I was losing a lot of productivity. The productivity losses were incremental but certainly slowed down my velocity significantly over the last seven years. Sure the language has a lot of wonderful features, but there’s more to a good programming language than well, its programming language. This is probably the most important point raised. I hope though, that people who run into any shortages with Racket consider building the thing they are missing, if they are able to, to add to the ecosystem and to avoid the next person running into the same thing lacking. If no one ever writes their own, we will only ever stick with the status quo in terms of programming languages. (And fortunately people do write their own often.)

3y ago

JimmyRuska 3y ago

Macros feel magical, this idea you can make your own language in no time so long as it's s-expression based, and make your own personalized vocabularies, expression flows, fit to purpose. Personal computing at its best! But from a working-with-other people perspective, imagine opening some code and finding random invented constructs you have to reverse engineer and step through. These days it seems everyone creates yaml or json files, and then implements some kind of declarative engine or interpreter to implement their DSL. This can be both easier to read and debug. For more complicated use cases you can tie it to a graph database that supports reasoning, instead of json/yaml Even so, is there really something that can be done with macros that can't be done, just as elegantly, with simple state machines, or object composition style in other languages?

memling 3y ago
> But from a working-with-other people perspective, imagine opening some code and finding random invented constructs you have to reverse engineer and step through This feels just like working with another API to me. Macros can be arbitrarily complicated I suppose, but is the typical usage any more complex than learning an API? I don't really know, I guess, but my experience hasn't shown this to be that challenging. I can appreciate that programming languages are ultimately codifying a particular way to think about computation, and macros express more idiosyncratic ways of thinkingabout comouting that may not be readily understandable. I do think Racket has issues, but this isn't the first one I would cite.
kagevf 3y ago
> is there really something that can be done with macros that can't be done, just as elegantly, with simple state machines My guess would be a C# using block. I think the Java equivalent is "try with resources" but I don't remember. In Common Lisp it'd be WITH-OPEN-FILE, or a similar macro made on top of UNWIND-PROTECT ... > or object composition style builder pattern comes to mind :)
kazinator 3y ago
> finding random invented constructs you have to reverse engineer and step through Like functions and procedures? I would pray that a good number of them are compile-time code transformers that execute in the comfortable development environment, so I don't have to reverse engineer and step through them on the embedded target.

soulbadguy 3y ago

Some good points, but i find the tone a bit off. I have been eyeing racket for a while now, but could never quite make the jump. Racket (the programming language) has definitely a lot of potential, but i do believe the academic side of it and the focus on the "build your own language" part might be an impediment to racket growth. If i was to suggest some stuff : - Clearly split Racket (and typed Racket) the language, evolution of scheme and Racket the PLT framework use to build and construct new languages. Racket / typed Racket should focus on more production/libraries for regular programmer - More examples/libraries/package not directly related to PL and PL teaching. Create a website solely for Racket/typed racket, with the academic part. - DrRacket always felt and looked alien to me. I can't really judge the feature set, but having vscode as the defacto IDE i think would be it more welcoming - This one is will definitively be controversial but introduce a "curly brace"/C style syntax for Racket. Something implemented at the reader level. Same semantic/runtime behavior, and a reader/printer to go between Racket and {C|rust}SyntaxedRacket. That's a lot of effort, so why do this ? I believe the world is looking for a better python. There is a lot of contender right now (julia, nim , etc... etc...). I think racket should also throw their hat in the ring.

priime0 3y ago
> Clearly split Racket (and typed Racket) the language, evolution of scheme and Racket the PLT framework use to build and construct new languages. It's very much possible to use Racket without interacting with macros and language-building features. > Racket / typed Racket should focus on more production/libraries for regular programmer Libraries are dependent on the community, which unfortunately is comprised of mostly academic folk at the moment. > DrRacket always felt and looked alien to me. I can't really judge the feature set, but having vscode as the defacto IDE i think would be it more welcoming I do agree -- if I remember correctly, DrRacket was primarily built as a pedagogic IDE, not one meant for more professional use. VSCode, however, does have the "Magic Racket" extension. > This one is will definitively be controversial but introduce a "curly brace"/C style syntax for Racket. Not necessarily C-style syntax, but you could take a look at Rhombus. It's meant to have a more approachable syntax compared to S-expressions.
- 3y ago

ashton314 3y ago

> Coding is a tool to get stuff done. Sure, that’s one of its roles. Racket helps me think. Maybe I’m lucky, and work on genuinely novel problems where a malleable language beats libraries. So, sure, the Racket ecosystem leaves much to be desired, but getting stuff done is only one of programming’s roles.

namaria 3y ago
People who use that argument are the same ones saying 'sure, I can do it in an afternoon/by tomorrow', and leave a trail of accumulating tech debt in their wake. It's a solid career move, what can I say? You get noticed for being such a sport and result oriented, and if you've got that service attitude, you get promoted/hired out of having to maintain that mess.
- ashton314 3y ago
  No. Some? Maybe. All? No. I worked at a few companies where, when I needed to model a tricky system and build out an algorithm to do a tricky job, I turned to Racket as a draft. Once I got a POC done, we’d turn around and build it For Real™. If all you’ve ever done is work as an implementer, then yeah, this flow doesn’t make much sense. But I think for people who work as problem discoverers, this is more common than not.

patrec 3y ago

Life lesson: don't waste 7 years of your life and and personal growth on some weird fringe language, you will not get them back. It can pay off to make a serious commitment to a non-mainstream technology, but basically only if it allows you to do some very concrete things that give you a big competitive advantage and that you could not reasonably achieve otherwise. Or if you are both unusually good at predicting the next hot thing, and the timescales are short enough. Racket is not a good bet in either regard (even if it's a great language to learn certain concepts). All the lost productivity the poster is bemoaning could have gone into mastering hard and useful skills instead and these things compound.

winny314 3y ago
100% this. It was a risk taken and it didn't pay off.

gus_massa 3y ago

[I'm biased, so I'd focus in some parts I disagree.] > 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…)? I agree it should be improved, but I think that deploying to the package system is something that happens not very often. The idea is to keep only a safe and stable version there. > 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? It would be interesting if the author post in github a feature request for the 3 missing packages that are more painful. (3 is a good numbers to find someone else that care about one of them, more than 3 or 4 would be annoying) > 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)? Sometimes I use minimal-racket, and it's this is annoying. Most people just use the main distribution so this is not a problem. IIUC the author cares about a small footprint, so it's a special case. I use Ctr-C, but I guess there is a trick with raco pkg to do fix this automatically. > 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 can skip most of them to write effective Racket code. I use continuations only as an emergency exit inside nested fors, no fancy stuff. (I agree the fancy stuff is weird.) I think units/signatures is almost deprecated. It will be there forever to keep backward compatibility, but I expect new code to use modules instead of units. About macros: If you are programing alone just use syntax-rule. syntax-case is not so difficult unless you want to do weird stuff. I've done weird stuff in the past, but five years later I regretted it. If you are programing in a team, it's important that the macros have good error checking, because otherwise in case of an error it will expand crap that will expend to more crap and after a few rounds of crap expansion the poor soul that is using it will get a unintelligible error about code they didn't wrote. Here is where syntax-parse is useful, to ensure the initial code makes sense and expand only good code and give a good error reporting otherwise. syntax-parse is almost a separate DSL, so it's a lot to learn. (You can write the same stuff with syntax-case, but syntax-parse automates a lot of stuff.)

winny314 3y ago

neilv 3y ago

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/ 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/ 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 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/ 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/ 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.

kagevf 3y ago

> 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 I don't know much about scheme or racket, but am aware that continuations is one of its distinguishing features. I've seen people praising syntax-case as a great take on macros. I've never heard of units/signatures, though. I know this was supposed to be a rant, but I wonder what drew the author to want to use scheme/racket in the first place?