Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@kobenz I hated writing Orchid without feedback. I want to get to a point where I personally prefer writing my own language over using its Rust FFI.
-
@kobenz Package management is coming a bit later because it's an interop standard so I want to get it as close to perfect on first try as possible. I'll probably have some basic support for depending on git repos first, but I expect that the first 3rd party modules will use the FFI a lot so I need to support building the Rust shared objects on the package user side from the get go.
-
@lorentz but how are people supposed to install orchid's LSP without it? I suppose you'll be writing it in Orchid, right?
-
@kobenz No, a language server is tacitly out of scope for Orchid. The project definition files used to configure the language server the same way the runtime will configure the interpreter would be in scope, and they'll probably be written in Orchid eventually.
-
@kobenz I also think that distributing applications with language-specific package managers is universally a bad idea, because all behaviour from lookup to startup is OS, distro, platform and distro version specific. A copy of the language server will be bundled will the VSCode language client and other client plugins when they come about, and if there's a reason to update the language server independently I'll create an AUR package.
-
@lorentz my dude, I'm talking about code, where'd you snuffle OS off of? Unless... Wait, is Orchid a hosted language?
-
@kobenz It's an interpreted language designed for embedding in host applications written in Rust, kinda like a pure functional Lua.
-
@lorentz have you implemented TCO already?
-
@kobenz The base is call-by-name (lazy) lambda calculus so TCO / TCE is implied and central to how the language is used in practice.
-
@lorentz noice! Can't do functional without it (you can, but thou shalt not)
-
@lorentz yeah, that whole infinite data structures thingy is cool. I never liked lens though. You could take a look a Clojure for what NOT to do with Orchid
-
@lorentz Orchid seems to be following a better path than Gleam
-
@kobenz I don't like the Erlang execution model. I get why it was chosen for OTP but when I try to write it like Haskell the eagerness is in the way, when I try to write it like a procedural language the mutability is missing, and I just can't get used to the actor model. When I had to build an Erlang system for school I started with several hundred lines of functional primitives.
-
@lorentz you mean one of gleam's backend? I find atoms and overloading to be Erlang's most enticing features. Like, wtf, why don't all languages have those! I mean, Rust enums are pretty great but the boilerplate, wtf? Python gets pretty close though the fucking indentation scoping... It just shows how much effort has been put into Haskell's design ✨
-
@kobenz I have interned strings which achieve about the same performance as atoms, a bit like JS, but I'm contemplating custom syntax at least. Luckily the lexer uses a plugin architecture so I can play around with ideas easily.
I liked Erlang's arity system but Orchid has autocurry which conflicts with that. I always have trouble with pattern matching based overloads, I prefer the clarity of a single function head that contains a match expression.
I didn't know Gleam has another backend, that looks interesting.
I was really teasing myself about it a week ago, but I definitely think now that building a language server before I try to get people to try Orchid is the right call.
There is a ceiling to the quality of error reporting without editor support, and because I'm not happy with the best I could've possibly gotten, I didn't really put that much effort into it. Before I got started on the language server, the interpreter would fail with the first error.
Because with LSP the new theoretical limit of DX is the lack of type information which still isn't great but it's a problem I already live with, I'm compelled to meet that limit by perfecting error detection.
It also helps that the interpreter's startup time is 2ms so I can simply run it in thread on every keystroke to generate truly live, basically instantaneous feedback.
rant
langdev
orchid
lsp