ITA started doing everything in Lisp, but especially as the original coding founder left, started hiring people doing stuff in Perl, Python, Ruby, Java, shell, C++, PL/SQL, etc.
The core software was still Common Lisp, but lots of cruft got added, and Conway's Law kicked in mightily.
New in std library: an S3 client, an SMTP client, SSL for Postgres (enables Heroku support), better CLI support (including multicall binaries), and plenty of module updates. Plus a few minor bug fixes.
Gerbil Scheme < https://cons.io > just saw its release v0.18, with many usability and documentation upgrades, and a bunch of new functionality in the standard library. A "meta-dialect of Scheme with post-modern features", Gerbil layers a Racket-like module system (the best in the world by far) on top of Gambit Scheme (compiler that produces the fastest code), with lots of libraries as "batteries included" for production-level client/server code.
MuKn | Remote, all timezones | Full-time or contract | https://mukn.io/
_Mutual Knowledge Systems_ https://mukn.io is hiring a project manager,
a network protocol engineer, a cryptographer, and interns.
Our mission at MuKn (pronounced "moon") is to secure for each person full control on their computing devices and thereby enable universal decentralized computing. Our first customers are cryptocurrency networks and their users,
who most than anyone today care to build systems that can't be hacked.
Projects we are building include Glow https://glow-lang.org, our portable domain-specific language for Decentralized Applications (DApps), the Laconic Network https://laconic.com, a decentralized solution to indexing blockchain data, and more.
Our main language is Gerbil Scheme https://cons.io, but the ecosystems we work with often use Go (particularly for network protocols), TypeScript (particularly for web interfaces), and sometimes Haskell or Rust. We also use Agda to formalize parts of our codebase. All our code is open source.
As a project manager, you will have to herd a clowder of half-a-dozen to a dozen cats. As a network protocol engineer, your immediate tasks will involve writing code in Go. As a cryptographer, your tasks may involve Schnorr signatures or zk-SNARKs, including code in Scheme, Go or Rust. You should be willing to place nice with the other languages in our codebase.
We’re a fully remote team spread across many time zones. We like to keep meetings and policies to a minimum, and expect team members to manage their own time and communications.
Please send resumes to jobs@mukn.io. Any notable public discussion (on a mailing list, GitHub issue, etc.) where you changed your own mind or someone else’s mind would be great to see, too.
Les mathématiciens sont comme les Français: quoiqu'on leur dise, ils le traduisent dans leur propre langue, et cela devient alors quelque chose de complètement différent. — Johann Wolfgang von Goethe
I suppose the original poster could clarify whether they were interested primarily in examples of the Scheme-derivative language "Racket" being used in production, or in the system/VM/runtime "Racket" being used in production. Since Racket (the system) now makes it very easy to define new languages on top of it with the #lang keyword, it might be nice to get more clearly distinct terms for these. The way the Java world uses JVM vs. Java, e.g. you'd say that a Clojure app runs "on the JVM", but it's not in Java.
Executing fasls is cool, but they will start from a new empty image, and loading fasls is actually kind of slow, so if you use lots of libraries rather than write a trivial example, that may consume hundreds of milliseconds before the program actually starts. Then again, this supposes you compiled everything into a single .fasl (which ASDF makes easy). But that will be a big fasl for each program; if you want to load from libraries, then there's also the overhead of setting up and using ASDF itself, which can also be in the hundreds of milliseconds. I can imagine many ways to improve the situation, but none are cheap (e.g. implement a background daemon to serve ready executables and/or watch the source registry for modified source; or break compatibility with the entire ASDF setup, angrying the entire community).
I wrote cl-launch so you can use #!/usr/bin/cl with lots of options and write scripts that are either portable or implementation-specific (and trivially switch from one implementation to the other).
My current setup does not compare favorably with Emacs/slime at this point. I use screen, I call a build script in one shell REPL, I use gerbil-mode in Emacs in the other, reload'ing things that I rebuild, or restarting the M-x run-scheme when too much has changed, copy-pasting from a gerbil-scratch.ss file, or repeatedly loading a .ss file with on-going tests. This is less than satisfactory. We hope to improve the situation this year so we can use geiser or slime or something similar.
