RacketCon Is Saturday
con.racket-lang.org
con.racket-lang.org
ALOE = Scheme + Smalltalk + Types
https://github.com/dharmatech/2026-09-02-aloe-racket
Prototype is in Racket.
Here's a video demo of the code completion in vscode:
(my-account 'balance)
(my-account 'withdraw 10)We can also create objects that handle deposits as well as withdrawals, and thus we can represent simple bank accounts. Here is a procedure that returns a “bank-account object” with a specified initial balance:
(define (make-account balance)
(define (withdraw amount)
(if (>= balance amount)
(begin (set! balance
(- balance amount))
balance)
"Insufficient funds"))
(define (deposit amount)
(set! balance (+ balance amount))
balance)
(define (dispatch m)
(cond ((eq? m 'withdraw) withdraw)
((eq? m 'deposit) deposit)
(else (error "Unknown request:
MAKE-ACCOUNT" m))))
dispatch)
3.1.1 Local State Variables
https://sarabander.github.io/sicp/html/3_002e1.xhtml#g_t3_00...
Closures indeed! A key concept of Scheme that distinguished it from most Lisps at the time:
(LAMBDA ( <identifier list> ) <body> )
Lambda-expressions evaluate to procedures. Unlike most LISP systems, SCHEME does not consider a lambda-expression (an s-expression whose car is the atom LAMBDA) to be a procedure. A lambda-expression only evaluates to a procedure. A lambda-expression should be thought of as a partial description of a procedure; a procedure and a description of it are conceptually distinct objects. A lambda-expression must be “closed” (associated with an environment) to produce a procedure object. Evaluation of a lambda-expression performs such a closure operation.
The resulting procedure takes as many arguments as there are identifiers in the identifier list of the lambda-expression. When the procedure is eventually invoked, the intuitive effect is that the evaluation of the procedure call is equivalent to the evaluation of the <body> in an environment consisting of (a) the environment in which the lambda-expression had been evaluated to produce the procedure, plus (b) the pairing of the identifiers of the <identifier list> with the arguments supplied to the procedure. The pairings (b) take precedence over the environment (a), and to prevent confusion no identifier may appear twice in the <identifier list>. The net effect is to implement ALGOL-style lexical scoping [Naur], and to “solve the funarg problem” [Moses].
THE REVISED REPORT ON SCHEME: A DIALECT OF LISP
B.1. Kernel Magic Forms
https://research.scheme.org/lambda-papers/lambda-papers-revi...
Moar:
3.2 The Environment Model of Evaluation
https://sarabander.github.io/sicp/html/3_002e2.xhtml#g_t3_00...
Here's a video demo of the code completion in vscode:
You can exchange the order, like on Dylan and Julia, however note how both declare them as if they were regular functions in non-OOP languages.
In SICP, for instance, they use a lot of utility functions to change it for readability sake:
(define (make-register name)
(let ((contents '*unassigned*))
(define (dispatch message)
(cond ((eq? message 'get) contents)
((eq? message 'set)
(lambda (value)
(set! contents value)))
(else
(error "Unknown request:
REGISTER"
message))))
dispatch))
(define (get-contents register)
(register 'get))
(define (set-contents! register value)
((register 'set) value))However. "Send, not apply" - sigh.. how shall I put it.. let's try this - eyes_rolling_so_hard_they_fall_out_of_sockets.png
Thank you!
https://bjolang.koketteriet.se/
It uses local HM inference and traits instead of OO, and the concurrency is based on concurrentML. The design process was mostly about what I dont like about other languages and what I think racket and OCaml does correctly. All default data structures are immutable (using an RRB tree, a champ, b+trees and linked lists) with pretty fast implementations.
Speed wise it is about the same as c# without spans and ref structs, since that is what it compiles to.
Every function that touches IO is compiles in a sync and async variant, so writing "bjoroutines" is most of the time the same as writing regular code.
The GitHub page is borked, since they removed Org mode support a day ago, but the manual and reference can be found on the web page.
The colour situation is ok, but us still a bit rough wrt higher order functions.
https://news.microsoft.com/source/2001/10/22/massive-industr...
I am not around the MSFT Partner CDs with the .NET Framework 1.0 release, however I remember there was a Scheme compiler as part of the original samples.
So maybe target MSIL directly.
For delimited continuations I only managed to find mostly extremely inefficient ways of doing it. CPS transformations on dotnet are, at least if kept to be useful as delcc, slow as molasses.
Which is ultimately why I chose to compile to c# to use asyncmethodbuilder do do the state machine translation for me.
https://www.jot.fm/issues/issue_2004_10/article4
I thought otherwise given my recollection of the samples, and that the platform supports C++, thus quite flexible on the opcodes.
Now I am generating two bodies for every defun that touches any suspending function, using asyncmethodbuilder, meaning I don't get any of the runtimeasync benefits coming in dotnet11.
Hopefully they'll give us a new asyncmethodbuilder that is somewhat more constrained but guarantees runtime async.
I'm curious: as a fan of Elixir and a language designer myself, what is the value of Racket and other esoteric languages, today, as (industry?) coalesces around AI tools and certain popular languages?
--------------------------
I think the Lisp family of languages are still the productivity boost they always were, especially with a good REPL. They can be as fast and safe as Rust and more expressive than JavaScript doing front end work. The deep support for macros and more really let you mold a program to fit the problem domain. Frontier models are reported to work as effectively with Lisp as any other language, and you can have much more succinct (token efficient) code while having more meaningful abstractions for readability by humans. I expect the two should go very well together. Plus you're dealing with a single language without the complexity of something like Rust or inconsistencies of JavaScript.
I wonder what the status of Carp is -- a Lisp with a borrow checker:
https://github.com/carp-lang/Carp
And I'm not a React developer, but from what I know of it, it struck me as something a Lisp hacker would come up with.
I'm curious: does anyone really care about Racket anymore? In general, does anyone really care about esoteric languages anymore?
With AI, we have converged on a set of languages. For the web, it's JavaScript or TypeScript. For backend, it's Go and Rust. Pretty much nothing else can get picked by AI if you start a new project. If you even like a language like Elixir, there seems to be less and less incentive to use it in production when AI can replicate a lot of its features in Rust for one-tenth of the cost and 10 times the speed of Elixir.
I'm saying this as someone who is designing a programming language, and for me, it's just a lot of fun, but I also know I should not hope for my language to take off anytime soon.
--------------------------
I think the Lisp family of languages are still the productivity boost they always were, especially with a good REPL. They can be as fast and safe as Rust and more expressive than JavaScript doing front end work. The deep support for macros and more really let you mold a program to fit the problem domain. Frontier models are reported to work as effectively with Lisp as any other language, and you can have much more succinct (token efficient) code while having more meaningful abstractions for readability by humans. I expect the two should go very well together. Plus you're dealing with a single language without the complexity of something like Rust or inconsistencies of JavaScript.
Also, I wish your comment wasn't downvoted to oblivion. I'd hope there are other useful responses that people won't be able to view.
Absolutely agree. I’d take a guess that a decent chunk, if not majority of “business” applications probably still exist in either Django or Spring Boot. Should all of those be rewritten now “just ‘cause”?
The answer is "yes". Obviously people still care. No need to resurrect a dead bad post.
Meanwhile, behnamoh's post was essentially dismissing the idea that we should discuss non-AI topics in the age of AI. His mention of his hobby project doesn't redeem a garbage comment.
I think you misconstrued behnamoh's comment, as he was literally asking a question about the role for Racket, not "essentially dismissing the idea that we should discuss non-AI topics".
https://survey.stackoverflow.co/2026/technology/data/languag...
"Which programming, scripting, and markup languages have you done extensive development work in over the past year, which do you want to work with over the next year, and which have you used AI tools or AI agents to work with? Select all that apply in each row."
For "which have you used AI tools or AI agents to work with", Rust and Go were only selected by ~11% of respondents. Whereas the usual functional languages were at ~1% or ~2%. I'd say the OP has a good point, but there is far less Rust and Go development with AI than he supposes.
Respondents
Percent
JavaScript 5,419 38.4%
Python 5,495 39.0%
Bash/Shell 4,038 28.6%
TypeScript 4,293 30.4%
Rust 1,602 11.4%
Go 1,524 10.8%
Lisp 133 0.9%
Elixir 257 1.8%
Haskell 127 0.9%
Scala 199 1.4%
OCaml 96 0.7% Java 2,052 14.6%
C# 2,277 16.2%
C++ 1,595 11.3%
C 1,120 7.9%
Call it "vibe coding by tiller". Ha.
Also, I think of metalinguistic abstraction as something deeper than macros. At least not limited to macros:
"An important advantage of making the evaluator accessible as a Lisp program is that we can implement alternative evaluation rules by describing these as modifications to the evaluator program."
As AI programming tools improve, we will have the second coming from what 4 GLs, RUP, CASE tools, and Japan's Fifth Generation Computer Systems were trying to achieve, each on its own way as the next evolution on programming abstractions.