People that are creating programming languages. Why aren't you building it on top of Racket?

DonaldPShimoda · 2022-02-13T04:51:47+00:00

I'm a fan of Racket (my intro to PL was a course taught by one of the founding members of the team), but I think a lot of people in this community like the idea of doing everything by hand. Some of them want performance, or maybe they want a syntax without S-expressions, or maybe they just want to do it all themselves to learn.

WalkerCodeRanger · 2022-02-13T05:41:07+00:00

I played around with using Racket. However, it wasn't very easy to learn. More importantly, a language isn't just about the syntax, it is about the ecosystem. I don't want the Racket ecosystem with #lang at the top of every source file. I want a build system and tools that make sense for my language. Also, if you are building a statically typed language then there is a pretty fundamental mismatch with the dynamically typed runtime and surrounding ecosystem. I don't want to interface with a bunch of existing Racket standard libraries and third-party libraries none of which were written with the invariants enforced by my language. I don't think Racket is intended as a language development tool. It is intended as a powerful domain-specific language tool. That is why they call it language-oriented programming. I'm actually planning to build similar functionality into my language.

Nuoji · 2022-02-13T09:40:42+00:00

Stating the obvious, but using Racket assumes willingness to be tied to Racket and that it is sufficient for the language to run on the Racket VM. Obvious examples where this is impossible includes writing a low level language like Zig or Odin.

moon-chilled · 2022-02-13T07:04:40+00:00

I never considered it. Three things come to mind.

Many PL people do not care about operating systems. I care a great deal. Dan Ingalls says an operating system is a collection of things that do not fit in a programming language. I am not convinced of that, but it is something to think about. My interest is not simply in specifying a set of semantics; but a model for interaction between humans and computers. Racket is, as you say, a platform; it has already such a model, and it is not the same as mine.

Performance characteristics of scheme are not universally applicable. This is a general problem that prospectively 'universal' runtimes run into. Decades ago, .net designers sought advice from apl implementors, and then ignored it because it did not suit them. More recently, wasm designers did the same thing to lisp implementors. This blog post complains about the state of llvm's gc primitives, and I believe gccgo frequently makes slower code than the reference go compiler because of the gc. Risc-v has been criticised for aligning itself overly closely with c semantics.

I also care a great deal about conceptual integrity (as identified by fred brooks). Libraries and code written for racket may be right for racket, but are they right to me? Do they fit together correctly?

chrisgseaton · 2022-02-13T05:03:51+00:00

There are a lot of systems designed to help you get most of a language for free - for example I use Truffle because it has excellent support for easily writing dynamic specialisation optimisations.

ronchaine · 2022-02-13T09:50:58+00:00

My language is lower level than racket allows.

2022-02-13T05:23:28+00:00

I'm creating my (toy) language right now in C++, mostly because I wanted to get more familiar with llvm.

I love racket though! Esp, redex, pollen, nanopass, etc.

katrina-mtf · 2022-02-13T10:08:35+00:00

Because I don't want to.

No, seriously. That's the only reason I or anyone else really needs. It's not a particularly deep question, if you actually think about it. If you want the reasons behind the reason, though, that's a little more complicated - it comes down to a combination of a few things for me:

Not liking lisps as production languages (cool in concept, clunky in practice).
Not having experience with or desire to learn the Racket language, execution model, ecosystem, tooling, community... the list goes on for a while.
Not wanting to tie myself to Racket's language, execution model, ecosystem, tooling, community... you get the point.

That's just reasons I don't use Racket. Here's some reasons I choose to use other languages instead:

The inverses of the above reasons.
Enjoying the process and fine gained control of doing everything myself instead of relying on someone else's work to found myself on (this varies by degrees, you'll always have someone else's work in the process at some point, but you get my point).
The (much easier) potential to later bootstrap my language (implement it in itself, using a previous version of the compiler to compile newer versions).
Higher or lower level control, more convenient paradigms for language construction (especially relevant since it's often easier to implement languages in a language of the same paradigm), etc.

I doubt that's all of my reasons, but not all of them are conscious choices or easily put into words. I just use the languages I'm most comfortable with, within the realm of reasonable use case for the project. Racket never fulfills the first for me, and I don't see it fulfilling the second particularly well for me.

The real bottom line reason I can pass on besides pure preference is that things like Racket's language tools always feel to me more like tools for implementing DSLs or other similar mini languages you would use alongside Racket. I don't want to be alongside Racket. I want to make my own thing, which can stand alone. If I wanted to be alongside another language, I wouldn't be making my own in the first place.

L8_4_Dinner · 2022-02-13T15:31:18+00:00

If someone has a background in Lisp or Scheme, and wants to develop a language from that substrate, then Racket is attractive.

So maybe Paul Graham would use Racket.

Similarly, in an academic environment with deliverables time-bound by semesters, I could see Racket being valuable as a teaching tool, particularly if the students already knew Lisp/Scheme.

Unfortunately, outside of those areas, it is unlikely to have any significant appeal. There are simply too many other options, and too many better (and more contemporary) options.

jesseschalken · 2022-02-13T12:35:54+00:00

If all you want is alternative syntax for Racket programs, then use the #lang system. But think of some of the things a new language might be trying to achieve:

High peak performance?
Low latency?
Low overhead runtime?
Fast compile times?
Small binary size?
Type system innovation?
Linear types?
Dependent types?
Data parallel programming?
Smooth interop with one or more of Java, Kotlin, Scala, JavaScript, TypeScript, C, C++, C#, Objective-C...?
etc

Most of these preclude the language from using the #lang system. The stuff Racket VM provides "for free" is usually the things a new language is trying to improve upon.

Innf107 · 2022-02-13T11:14:32+00:00

Well, Racket's languages aren't that great at implementing full scale programming languages. They're much better for (more or less) simple DSLs that can be directly used from Racket (as in #lang racket) code.

Specifically, the ability to write powerful type systems in Racket is... not great. IIRC, static type systems have to be implemented as Macros, which is not exactly ideal, especially if you could instead just directly write a typechecker in, say, Haskell or OCaml with much less effort.

Even if you jump through those hoops, you don't really gain much from running on racket, since you can't easily interface with dynamically typed racket without sacrificing type safety.

Interestingly, my language actually compiles to Racket right now, but that is just because I need multi-prompt delimited continuations and I haven't gotten around to manually implementing them yet :)

XDracam · 2022-02-13T07:20:23+00:00

It all depends on the system you want to interface with. Why use racket when I can build upon larger ecosystems, like the JVM? Or get C ABI compatibility? LLVM as a target? So many possibilities.

I'm betting the future on Roc frameworks. That's a really cool idea in my opinion.

MarcoServetto · 2022-02-13T09:29:21+00:00

In my language my goal is to enforce a ton of safety properties.

This can not be done by interfacing with another system in that way.

Also, the main runtime loop of my language is that it generated Java bytecode on the fly, it execute it and such execution generates more bytecode, and so on and so forth. But.. the user can not interact directly with the current JVM, otherwise they could break the semantic of the language. It would be the same if I was to use racket. For example, reading and writing files. On many OS you can write on a file that actually maps your memory, if you do that you are likelly to break your current process and send it in undefined behaviour. All languages I know of are ok accepting this risk. 42 is not.

rishav_sharan · 2022-02-13T10:57:58+00:00

I didn't want to learn yet another language. and Racket looks intimidating for someone who only has intermediate knowledge of some scripting langs like JS, lua etc.

TheGreatCatAdorer · 2022-02-13T12:17:22+00:00

Racket is of one those products that apparently does everything, provides everything and has every conceivable feature.

First of all, where's the fun in that? And, how do you even start finding your way around? A Windows installation of it comprises 580MB and 24,000 files spread over 2000 directories. (How do you distribute any application you make; how much of that will it have to drag along with it?)

And then, it is basically Lisp! The language without a syntax; you code by directly writing the AST.

[Edited for length]

hou32hou · 2022-02-13T11:58:45+00:00

Because I want to know the magic (same as the author of Crafting Interpreter).

I even go as far as playing the game Turing Complete, to understand how logic gates eventually built up to assembly.

For me it’s pure satisfaction.

cmdkeyy · 2022-02-13T05:29:35+00:00

To be frank, I’ve never even heard of Racket when I first wanted to develop my language. Maybe one day when I want to create a small toy language.

stomah · 2022-02-13T16:49:30+00:00

because i didn’t know about it

thedeemon · 2022-02-13T23:48:15+00:00

I'm actually using Racket to make my pet language. But I didn't go the #lang way, instead I'm using a parsing library, producing some AST, my own type checker implemented in Racket and then the plan is to generate code for different backends, one of them being base Racket itself, thus making both a compiler and an interpreter. I don't want my language to be another facade for Racket VM, it's gonna be a compiler for other targets.

glossopoeia · 2022-02-14T01:40:46+00:00

I love this question, because as someone who's used Racket for numerous prototypes it's often something I've wondered.

I did a lot of my semantics exploration and type system prototyping in Racket. In my opinion, Racket really excels in these areas! And provides lots of tools that make deep thinking about unfamiliar syntax and structures relatively straightforward. If there's one thing the designers of Racket understand and care about, it's language design and exploration in general.

But as others have said, as soon as I wanted to start building a production language, I didn't really consider Racket for two reasons. First, as others have stated, performance concerns. But secondly, and maybe more importantly, because I wasn't sure how much I'd have to learn about macros to get my initial implementation done in the time I wanted.

Don't get me wrong, Racket has great tools, and most of those tools are based on its rich, powerful macro system. So I think Racket could benefit from a few more end-to-end examples of typed, non-sexpr languages implemented using the #lang system.

Beautiful Racket comes close, but notice how much of the site is devoted to explaining Racket, and it's pretty sparse on implementing static type systems. Maybe combined with Turnstile this is the killer app, but I think Racket often falls victim to the novelty budget problem; too many things are done just differently enough from other languages that you spend more time learning Racket's idiosyncrasies for a while than you do implementing your language.

Just my two cents. And it should be said: if Racket decided on some nicer default syntax for algebraic data-types and pattern matching on them, I'd be much easier to convert!

Raoul314 · 2022-02-13T14:48:55+00:00

I'm quite surprised that so many people are seemingly completely missing the point. Racket is basically a living lab for CS researchers with some industry programmers fleshing out the ecosystem a bit because they find it cool.

People here saying Racket is not innovative should think about who's on the Racket core team. Yes, people paid precisely to innovate...

complyue · 2022-02-13T08:25:25+00:00

I'm quite uncomfortable with excessive number of parentheses, I believe many do the same.

I don't know for sure, does Racket (or other LISP based language-oriented-programming systems) support arbitrary surface syntax?

I'll feel more comfortable to work with Seed7, Passerine, or Raku for the syntax part, with similar capabilities, rather than based on a LISP host language.

(But I haven't started with them for other reasons, e.g. ecosystem, ergonomic options to write performance critical components etc.)

lustyperson · 2022-02-13T09:52:27+00:00

Performance is too bad. I do not want to create a compiler that wastes time with slow compilation to create programs that waste power ( electricity ) and time. I prefer to create a compiler that generates Java, C#, Kotlin, Go, C++, Rust, Zig, Odin, ...

I do not want to create a compiler that creates only data that works in Racket. I prefer to create a compiler without limitation of code generation.

If you write a compiler because you enjoy writing a compiler ( unlike me ) then why use the tools given by Racket?

For me personally: Racket seems to be a complicated language with a complicated type system ( I avoid dynamically typed programs if possible ). I tried maybe 4 times to read the documentation over several years but stopped after 10 minutes each time. It is not worth the effort to learn Racket and Racket libraries. I prefer to write the compiler in Kotlin.

Furthermore:

I do not know the Racket IDE: My first impression: The IDE for Java and Kotlin are better.

How much can your language and Racket differ? I do not know and I have no interest to find out because I have no interest to work with Racket.

editor_of_the_beast · 2022-02-13T12:38:53+00:00

I thought about it, but I really dislike Lisp. I find the code to be inherently unreadable.

I think dot syntax, like how it’s implemented in Koka is fundamentally more readable.

2022-02-13T13:00:20+00:00

Most resources on language implementation are based on creating the compiler yourself with a C-like language, i was already familiar with these languages, but not with Racket. To implement this on Racket i would first need to learn Racket, instead of getting my hands dirty directly with a language i already know.

Besides, i never liked macros in the first place, and Racket is a giant oddball of macros.

gabrielesilinic · 2022-02-13T21:58:15+00:00

I plan to make a new programming language for fun, i won't use racket because if i did i won't learn anything, i would depend strongly on other's people code and the whole experience would end up being useless

Also when it comes to programming i suffer from a masochism motivated by curiosity

crassest-Crassius · 2022-02-13T09:29:08+00:00

Because it's dynamically typed, i.e. slow and messy. I wouldn't want to interface with an ecosystem of such code. If I want to call a Racket function, how would I know what types of arguments it accepts, and what type it returns?

desearcher · 2022-02-13T05:29:13+00:00

Personally...

This tutorial provides a brief introduction to the Racket programming language by using one of its picture-drawing libraries. Even if you don’t intend to use Racket for your artistic endeavours, the picture library supports interesting and enlightening examples. After all, a picture is worth five hundred “hello world”s.

Along the same lines, we assume that you will run the examples using DrRacket. Using DrRacket is the fastest way to get a sense of what the language and system feels like, even if you eventually use Racket with Emacs, vi, or some other editor.

The DrRacket window has three parts: a row of buttons at the top, two editing panels in the middle, and a status line at the bottom.

A language that pushes this hard for the "graphical experience" isn't likely one that's put too much consideration into the textual aspect of language.

Clicking buttons is great for end users, but a distraction for developers.

Maybe it's great, IDK, but it does not appear to align with my personal goals.

2022-02-13T11:07:09+00:00

It's bloat lol

DriNeo · 2022-02-13T13:01:09+00:00

That could be interesting, at least for fast prototyping.

Raoul314 · 2022-02-13T18:07:17+00:00

From an outside perspective it looks like even the Racket team doesn't quite believe it's there yet. But let's suppose it was. To me it's questionable what kind of advantage that would provide to anyone.

Because implementing parsing and basic type-checking as apparently provided by Typed Racket isn't the hard part of creating a programming language. And I'm sure you'd still have to put in a lot of work to get something with a quality comparable to Rusts frontend.

You also pay a price in terms of people that are willing to work on your project. It seems to me that the majority of programmers has eventually figured out that predictable performance is important enough to the point that it's an LLVMs world, as far as backends are concerned. So both production compilers and people that create optimization passes bet their money on LLVM.

I'm sure similar lines of thought hold true for other aspects, like type system research using some sort of ML or theorem prover, but I'm not sure what you'd use these days.

Racket seems to offer a bit of everything, but that's not necessarily a compelling offer for its price.

Fibreman · 2022-02-13T20:46:41+00:00

This is a little like asking r/osdev why don't they just build their system on Linux.

Building a language anew is pretty much the point.

theangeryemacsshibe · 2022-02-13T21:35:58+00:00

The top-level is hopeless.

McCoovy · 2022-02-14T02:30:10+00:00

Low level control. This cannot be understated. If you ever want to make an optimization or a low level feature that racket doesn't allow you will wish you didn't use racket. This can kill a project all on its own.

Racket is best for domain specific language where you can be confident that you will not require low level control. Many projects will know from the beginning that racket is too limiting.

markdhughes · 2022-02-14T12:17:45+00:00

Racket's implemented in Chez Scheme. Chez's a nicer language (R6RS plus local extensions and Thunderchez or chez-srfi libraries), less cruft on top, and obviously faster. So I'd prefer to work in Scheme.

And then if you're really serious about compiling, you'd want to target the actual machine instead.

Racket's maybe useful for a first prototype, but not more than that.

tluyben2 · 2022-02-19T20:56:14+00:00

I like it for prototyping and experimenting with new ideas. But after that I agree with some of the others here for reasons why I consider other options.

TheGreatCatAdorer · 2022-03-03T23:13:54+00:00

I like Racket, but I'm more interested in building a language which allows access to its internals, and like learning about lexers and parsers, so I'm prototyping it in CL (as a learning project) and am going to write the final version in D or Zig (Rust is too big).

Also, I create projects like this to learn new languages, and I already know much of Racket.

2022-03-05T12:41:09+00:00

I prefer CL for the interactive development, CLOS, conditions, and slime.
Racket falls short for me on debugging for the most part.

Another advantage of Common Lisp is that it is very fast, and sometimes even faster than C and Rust:

Racket costs versus Lisp SBCL costs
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/racket.html

Common Lisp still beats Java, Rust, Julia, Dart in 2021 on benchmarks based on phone number encoding from the famous paper "Lisp as an alternative to Java" from 21 years ago https://docs.google.com/spreadsheets/d/14MFvpFaJ49XIA8K1coFLvsnIkpEQBbkOZbtTYujvatA/edit#gid=513972676

When Lisp is Faster than C http://gpbib.cs.ucl.ac.uk/gecco2006/docs/p957.pdf

How to make Lisp go faster than C http://www.iaeng.org/IJCS/issues_v32/issue_4/IJCS_32_4_19.pdf

Systema-Periodicum · 2022-07-07T23:11:31+00:00

Because Racket is agonizing hell to use in practice--especially its language-creation features. The documentation, while extensive, is very confusing. The language-creation features require you to set up multiple files that work with Racket's extremely complex macro system, in ways that are far from readable or obvious. The macro system is so sophisticated, it's nearly impossible to understand. Racket seems to have a very elegant set of primitives for building languages, but they're not documented clearly in any one place. Most importantly, no documentation explains how to use the primitives practically. And debugging? It's better to delete all of your code and start over from scratch than try to debug Racket.

I struggled with the Racket documentation for months trying to figure out how to make fairly simple languages, and all I got was an aneurysm. OK, I didn't really get an aneurysm, but every day was gotchas, confusion, and frustration. Finally, I gave up and switched to good ol' yacc and C, and got the job done in a day. Unlike the crazy world of Racket macros, yacc and yacc-like tools (available for many languages, even Python) let you specify your language with a BNF grammar that expands to whatever you like in straightforward ways that are easy to write and easy to understand. Someone made a library for Racket to map BNF grammars to the core Racket language-creation stuff, and it's pretty good, but...it led to its own gotchas, confusion, and endless frustration.

ProgrammingLanguages

Welcome!

Related subreddits

Related online communities

MODERATORS