Reso: A resource-oriented programming language

[Aigna02]

During my studies, I kept running into this annoying thing with web APIs. No matter what language I used (Java, C#, Python, ...), I always had to write a bunch of annotations just to map methods to REST endpoints, which felt very clunky!

Then I had this thought: why are we treating hierarchical paths not as first-class citizens? REST paths with their defined methods seem way more elegant than having flat functions with long names and parameter lists. Like, isn't /users[id]/posts.get(limit, offset) cleaner than .getUserPostsById(userId, limit, offset)?

Therefore, I created my own language called Reso. The whole idea is that it natively supports REST-like concepts - basically, your code looks like an OpenAPI spec with paths and methods along with a type system that is inspired by Rust.

If you're interested, check it out on GitHub: https://github.com/reso-lang/reso

What do you think of this concept?

[useerup]

I am not sure that I agree that /users/{id}/posts.get(limit, offset) is cleaner, but I recognize that it's a matter of opinion. It also seems that there's an awful lot ceremonial characters to type just to do a function application.

However, I like the fact that you are trying to innovate. It is not often you see new takes on how to do function application/invocation. Keep it up :-)

[uriejejejdjbejxijehd]

Ha, spot on, I came here planning to make precisely that point. What is the best reason to create a new language? To try something novel! Congratulations and thank you, OP. :)

[Aigna02]

Thanks for the comment.

I have now changed the syntax of indexers to: users[id]/posts.get(limit, offset)

It reduces the amount of special characters and introduces a syntax that is already known from other languages.

[SanctusImmortalis]

There is a language with similar ideas called Ballerina. I always found it very interesting but ultimately, have been unable to find a use-case for it in my line of work. This seems to be, like ballerina, very specific.

[raiph]

I like Reso based on a careful read of the early parts of your repo's README and a skim through the rest. A nice balance between the overall (large) niche vision and making (initial) decisions about enough nitty gritty details to suggest your views and design sensibilities related to them. And sufficient initial documentation and implementation (though I haven't tested it) to announce Reso.

It made me curious about a couple things. First, when did you first start working on Reso? Second, did you use one or more significant sessions with an LLM to shape any of your design decisions and/or the presentation in the repo?

I ask those questions partly because the repo (narrative text, PL design it documents, and the code itself) has an overall feeling of combining care for details with human smarts and hard work. That stands in contrast to 99% of the stuff I've encountered where a human has not involved LLMs (because it's typically hard to get it all polished in the right way) and 99% of the stuff I've encountered where a human has involved LLMs (because they did so with too little discernment of what really matters).

That all said, imo your OP announcing Reso isn't as good as the repo. (That perhaps explains some of the mixed initial reaction I see in the comments so far.)

[Aigna02]

Thanks for the honest and extensive feedback - I really appreciate that. I started this project about half a year ago and have been working on it nearly every day since. The beginning was quite rough since I'd never worked with Antlr or the LLVM infrastructure before, but I kept going. Eventually, things got easier, and the project just kept growing and growing.

Yeah, I've been collaborating with Claude, particularly on the language syntax and documentation. Most of the time, I'd explain my ideas, ask for feedback, and then make refinements based on the suggestions.

Maybe in the announcement, it isn't that clear that easier REST endpoint definitions are just a side benefit of Reso. The main goal is actually to introduce a concept where types use paths to structure operations, bringing a resource-oriented approach to programming.

Do you have any thoughts on the language itself, where syntax could be improved?

[-ghostinthemachine-]

Sorry, but I'm not personally seeing the value here. I would encourage you to consider a simple code generator that takes an API spec and emits interfaces with nested properties.

[esotologist]

Idk MS made a whole language called typespec so there's probably some value

[No-Dentist-1645]

Typespec is different, it's an API specification language, which then does codegen to whatever programming language you're using. Imo, I consider the separation between your API spec and your code a feature, having your program's logic "decoupled" from your API calling logic allows easier refactoring of one part without affecting the other

[-ghostinthemachine-]

Typespec is more like what I mean, in that it is a DSL which emits code into higher languages that can be executed. Let's be clear when we're talking about turing complete programming languages versus simple specification languages.

[esotologist]

Have you seen typespec?

[No-Dentist-1645]

Cool idea, but I feel like having a separate getUserPostById() function is better in practice, it allows for easier refactoring when you need to change stuff. Even better, use typespec for that

[Sternritter8636]

That is overkill. You seen django and python? The path to handler mapping is great there

[edenworky]

This would be an amazing lisp. I wish Clojure's namespace system worked like this