Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
Gren: The friendly, fullstack, functional future?
962 Plays2 years ago
Time to put another new #programming language - and its creator - under the spotlight, as we talk to Robin Heggelund Hansen, the creator of Gren. Gren is a Norwegian word meaning 'branch', which is appropriate for a language that started as a fork from its roots in Elm.
With Gren, Robin's trying to create a safe, sane, #fullstack language that puts the power and elegance of functional programming working seamlessly on the server and the browser. But how and why do you do that? What design choices to do make, how much time do you spend on adding new features vs. improving the developer's experience of the existing ones? And most importantly...how do you pronounce Gren correctly? 😅
Gren Website: https://gren-lang.org
Gren Zulip: https://gren.zulipchat.com/
Gren package site: https://packages.gren-lang.org/
Example projects written in Gren: https://github.com/gren-lang/example-projects
Gren on Mastodon: https://fosstodon.org/@gren_lang
Gren on Twitter: https://twitter.com/gren_lang
Gren language proposal on parameterized modules: https://github.com/gren-lang/compiler/issues/81
Elm Website: https://elm-lang.org/
Robin on Mastodon: https://snabelen.no/@robinheghan
Kris on Twitter: https://twitter.com/krisajenkins
Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/
Kris on Mastodon: https://mastodon.social/@krisajenkins
Recommended
Transcript
Introduction to GREN
00:00:00
Speaker
Hello, you're listening to Developer Voices, and today we're going to put another new programming language under our spotlight. This time it's the term of GREN. That's G-R-E-N, GREN. It's a language that's trying to take the biggest, most important ideas from functional programming, and then make them as accessible as possible. But which ideas do you take?
00:00:22
Speaker
And what does it mean to try and make them accessible to more developers? And how do you do that?
Meet Robin Heglund Hansen
00:00:28
Speaker
Joining me to discuss all of that is the creator of Gren, Robin Heglund Hansen. He started the project a few years back for that most noble of reasons. He really, really wanted it to exist. So he started with a fork of Elm, if you've heard of that front-end language. And he set about reshaping it in a few different ways and expanding its scope so it works on the back end as well as the front end.
00:00:52
Speaker
We talk about all the directions he's trying to take it, where he's looking to be in the future of Gren, and how he's trying to build up a sustainable community around it so that it doesn't just rely on him being the benevolent dictator for life.
What is GREN's Goal?
00:01:06
Speaker
I really hope he succeeds. It's certainly an interesting journey to be on. So let's join him and hear all about it. I'm your host, Chris Jenkins. This is Developer Voices, and today's voice is Robin Heglund Hanson.
00:01:32
Speaker
I'm joined today by Robin Heglund Hanson. Robin, how are you? Hello, thanks. I'm fine. Good. Yeah, I'm good. The sun is shining for once in England today, so I'm happy. Oh, brilliant. We're having an extremely hot summer.
00:01:50
Speaker
I'm recording this from the basement, so I'm able to focus and function. Function is the word of the day. Look at that for a segue. Since we last met, you've been creating a functional programming language, right?
Managing Side Effects with GREN
00:02:10
Speaker
That's right, yeah. It's called the GREN. I love the pronunciation. You'll have to forgive me if I call it GREN. That's fine, that's fine. It's a Norwegian word, so I'm thinking that if I'm not pronouncing it correctly, then it doesn't stand a chance. But yeah, GREN is fine. I do occasionally slip up as well.
00:02:39
Speaker
But tell us about Gren. What's the elevator pitch? The elevator pitch. OK, so I would say that Gren is a simple language that tries to help you write maintainable, readable and well-functioning applications.
00:03:00
Speaker
Okay. And that doesn't really mean anything. So, Gren is a statically typed language. And it tries very hard to use that static typing to guide you to write robust applications.
00:03:18
Speaker
Another way of thinking of it is that we're trying to take the really good ideas of Haskell and making it simple if you're not one for complexity. Yeah, I think a bit more approachable.
00:03:34
Speaker
I'm a huge fan of Haskell, and I think it's the way programming should go long term. But I've got to admit, it's not accessible. I wouldn't recommend it to anyone as their first or even second programming language. I think it took me three tries, I think, to learn Haskell until I finally
Making Functional Programming Approachable
00:03:53
Speaker
got over the
00:03:56
Speaker
got over the initial complexity and the inherent fear I got from, I think I bought this book, which was way too thick. And so every time I approached it, it was still there. Yeah, that's a danger these days, because generally by e-books and you can't tell what you're letting yourself in for. Yeah, that's a good point. Okay, so a more accessible thing in the spirit of Haskell.
00:04:24
Speaker
Yeah, well, I think if you like Haskell, I think you will look at the GREN and think this is not Haskell. But it has the ML syntax, so it looks similar from afar. And it has tried to stay away from all the
00:04:47
Speaker
from all the difficult concepts, I think. Never once do we mention the M word, for instance. I have put a little subtitle on the video version of this. It tries to make it approachable in a way, but it's a very limited subset of Haskell.
Extending Elm to the Backend
00:05:16
Speaker
Okay, so if you're taking the subset, what do you think the big ideas are that you're taking? Well, for me, the it's different for a lot of people, I guess, but the most important parts of it for me is the fact that is the fact that the type system is used to check
00:05:39
Speaker
Many things which in many programs are completely unmanaged. So you will have, for instance, Grian doesn't have exceptions. That has to be represented as part of the type system.
00:05:52
Speaker
And so while we do have exceptions as a concept, you can't define your own and you can certainly not throw them. You instead have to module that as part of the type system. And the byproduct of that is that the compiler will catch errors that you probably should handle.
00:06:11
Speaker
And another big thing about it is that side effects are also treated the same way. So if you want to perform a side effect like reading from disk or sending something over HTTP, that has to be modelled as part of the type system. So you can't accidentally inherit unpredictable functions into your case, right?
00:06:35
Speaker
Exactly. And it also gives you the sense of control that if you're going to import a third-party league package, if it hasn't specified a side effect in this type system, then you know that whatever it does, it will remain local to this program. That's one of those things. I mean, we often talk about it in terms of correctness, but I'm surprised it doesn't get more headway in security.
00:07:04
Speaker
Yeah, and that's one of the things that we're trying to push a little bit in GRAM, especially on the backend side. So we have this concept of applications and packages, and those are two different things.
00:07:22
Speaker
Packages, in order to perform certain things like reading from disk, reading a file, for instance, or performing a network request, you first have to obtain a value that represents a permission to do such an action. But those permissions are only handed to applications.
00:07:42
Speaker
So as a package author, there is no way for you to simply perform or even, there's no way for you to perform a file IO unless you retrieve a special value from the application. And that way the application author has full control over what parts of the system can perform which side effects.
00:08:11
Speaker
So I can no longer write a library that claims to left pad strings, but also runs a crypto mining bot at the same time. Yes. Yes. Unfortunately, Chris, you lose that ability. Damn, that was going to be mine. You can't do that. But again, it will be very apparent in the type system that you gain that ability, right? Yeah. Yeah. And so and I, you know, the hope is that like,
00:08:39
Speaker
The trade-off we're making here is that the application author has to do an extra bit of bookkeeping. But at the same time, it becomes very apparent what code that you're calling can do. And so this is different from Haskell, and it's different from L, which Graeme shares a lot of.
00:09:01
Speaker
history with, whereby those languages expose this IO type in the elements called task. And if you can see a task in the types of a function, then you know that this can perform one or really many kinds of side effects if it wants to. And side effects can be anything.
00:09:28
Speaker
Uh, but then again, we're trying to kind of like limit the powers of the, um, the IO. So you're going more granular on the. Yeah. Because Haskell always had that, I think because they invented it before they realized how powerful it was and Elm had it as a kind of way of simplifying this all down. But you're saying it's worth the complexity to break it into different kinds of side effects.
00:09:56
Speaker
I think so. Especially for the sort of, this is my hypothesis. It's still very early. We are releasing 0.3 in about a week. So I've been doing this for about a year and a half. So it's relatively new, right? But yeah, that's my working hypothesis
Balancing Development and Community Feedback
00:10:18
Speaker
that that extra bookkeeping will be worth it if you want that level of control.
00:10:25
Speaker
Tell me a bit about how you got started on this, because I've checked it out briefly, and I've played around with some of the demos. It seems you share more than just inspiration with Elm. Yeah. How'd you learn that? It's no secret, really, that Gran started his life as a fork of Elm. But I consider that mostly to be an implementation detail, because it's not a goal of the Gran project to
00:10:55
Speaker
remain compatible in any way, shape, or form with Elm. For the first release, one of the first things we did was which parts of Elm syntax don't we like for some reason, and then remove or add to that. So that already from the first release, we were incompatible with Elm.
00:11:20
Speaker
Right. Deliberately, you're cutting ties and not trying to... Yes, deliberately. It's important to note here that before I started working on GREN, I've contributed to Elm, the standard library, and written some packages of my own. I worked professionally in Elm, and I like both the language
00:11:45
Speaker
Evan, who created language and the community a lot, and I have a deep respect for them. When I decided to create Gren, it was very important for me to not... That Gren wouldn't become something that stole attention from the Elm community in any way. It has been an explicit design goal from the beginning to not be compatible with Elm, to not make it easy to just take an Elm package and convert it to Gren.
00:12:15
Speaker
Okay, but why? What wasn't, because I know you were hugely into Elm, what was Elm not doing for you? So it's not like, so if I were to create, if I were deciding that, you know, I'm going to create a single page application for the browser, I would still reach for Elm.
00:12:36
Speaker
I think Elm really is. If that's the thing you're going to create, I don't think you will find any better experience out there than Elm. Now you can do the same thing as Ingrid Elm because we are a fork, right, at the moment. But Elm really, really... Yeah, Elm
How Does GREN Differ from Elm?
00:12:53
Speaker
is the nicest thing to use when writing those kinds of applications. You put that ahead of... Oh, sorry. But I mean, if you were talking to a general audience, you would recommend that ahead of, say, TypeScript and React?
00:13:06
Speaker
Yes, definitely. Good, we've got the controversial quote in there. The main thing missing for me is that you can't really make other things in Elm. Elm is very suited for one thing, and if you want to do something else, you're fighting this uphill battle.
00:13:31
Speaker
Yeah, it's very much focused on single-page web apps. It's not a general purpose programming language. Yeah, so I have used it for it. I have written a compiler for a toy language in Elm, but you are fighting this uphill battle constantly, and it's worth it because you really love the language and the semantics. So really, the trigger for me was I want
00:13:59
Speaker
I want Elm. I want the security it provides. I want the convenience. I want the... I want Elm. I really like it. I want the semantics it has. But I want it for backend applications. Because at some point, I started doing backend development. And I feel that backend development
00:14:28
Speaker
could really use all the features that Elm has, all the benefits it has. But there really isn't a good contender there, I think. Yeah. So you weren't tempted to go with something like Haskell or PureScript.
00:14:41
Speaker
I wasn't. It's funny. That's the question I get the most. Why not use pure script or why not use Haskell? I think we touched a little bit on it.
00:14:58
Speaker
Partly because it was the first to do a lot of these things, partly because it's also focused on being a research language. Haskell has a lot of complexity and a lot of terms and concepts that are not inherently approachable. They're not
00:15:21
Speaker
intuitive, I guess. And there's nothing inherently wrong with that. I enjoy programming languages. I can spend the summer learning a new programming language because I like the challenge and I like, you know, yeah. But most of the people that I work with don't. Most of the people that I work with are treating programming as a job and not a passion.
00:15:52
Speaker
And they've learned one programming language, why should they learn another? And then I can say it has all these benefits, but if they take one look at the best teaching book for Haskell and they run for the hills, I essentially won't be able to work on it professionally, at least not in the sort of projects that I work on right now. So the problem with Haskell and PureScript is their complexity.
00:16:18
Speaker
And that is a benefit for some. You can be very flexible in Haskell. You can model things in a lot of different ways. And that's very cool if you're into that. But if all you want to do is get something done in the safest and best way as possible, the complexity of PureScript and Haskell kind of get in the way, I think. I think that's fair. And I think
00:16:43
Speaker
The thing about Elm is it did such a great job of being accessible and predictable and reliable that when people were getting started programming, sometimes I would say, well, you know, if you want a job, get JavaScript or Python, but if you want to learn how to actually program without banging your head against the table, Elm is so friendly. It's going to help you. Do you think you've managed to capture that accessible friendliness in Gren?
00:17:12
Speaker
That's a tough benchmark. It's definitely a design goal to keep that friendliness, to keep those benefits that make the language so approachable. But I've also gotten a lot of respect for the amount of work that takes.
00:17:41
Speaker
And you need to keep this in the back of your head. I want this thing because that would make this backend thing easier to do. And then you can implement that. But actually making that easy to understand, intuitive, and have error messages to say, oh, I think you did this because of your experience with JavaScript. But in GRAND, you should do this. Those kinds of error messages are an incredible amount of work.
00:18:08
Speaker
So am I succeeding in this?
The Role of Community in GREN's Development
00:18:11
Speaker
I don't know, but I hope to continue that, continue in those design footsteps to keep it approachable and yeah. Do you have any idea of how much, how your workload breaks down with this? How much are you understanding the code base you've originally forked versus developing new features versus making them usable, user-friendly features?
00:18:39
Speaker
Well, that's difficult to, it's difficult to answer. So the grand wasn't this. It wasn't this an apple fell from a tree and I have a sudden realization that I was going to make a new programming image. A lot of these ideas and thoughts have happened over a very long period of time. So as you said, I was very into Elm and I've been very into Elm for my god.
00:19:08
Speaker
six or seven years, I think. And I've been working with it full-time in certain respects. And so a lot of the things that I know I want in Gren are things that I've thought about for the last several years.
GREN's Package Management
00:19:23
Speaker
Yeah.
00:19:24
Speaker
And so now there is this, I think now what I'm doing is I have this idea, I know roughly how it should work and I know that this idea is better than other ideas for certain reasons. So I think a lot of the time that goes into Grand right now is figuring out the precise implementation details and actually talking with other people and getting their first impressions and taking that into account when doing things.
00:19:50
Speaker
Um, but this is also like a hobby project. So I spent maybe, I, I, I spent anywhere from one hour to five hours a week actually implementing things. And then the rest of the time I'm spending 30 minutes or one hour before I fall asleep and like churning through like how should it actually work and one of the challenges here. Yeah. What they call in their closure world hammock time.
00:20:19
Speaker
Hammock time, yes. Yeah. Well, you're just kicking back and thinking. Yeah. So there's a lot of that and probably a lot more than actual implementation. I would assume. Yeah. One thing we haven't said here, so the people won't know Elm is, was it purely like a front end compiles down to JavaScript language? I'm assuming that's still the case for Gren that you're running on the browser and running on node.
Expanding GREN's Capabilities
00:20:45
Speaker
Is it going to stay like that for the foreseeable?
00:20:50
Speaker
Maybe. Currently, like so, we've inherited the JavaScript code generation from the Elm compiler. And it works. And it's not the most important thing to tweak right now. Also, the Elm compiler is written with JavaScript as an explicit target of mine. So, there's a lot of things the Elm compiler simply doesn't do because it
00:21:13
Speaker
doesn't really have to when targeting JavaScript. So to target something other than JavaScript would be a huge amount of work. Because the compiler simply isn't written with that in mind. And so I've been focusing on trying to add what I like to think of the missing features to the language. And once that is done, I'm going to
00:21:41
Speaker
take some hammock time and evaluate should this target that assembly or something else. Yeah, that'd be an obvious next place to go, right? Yeah. Yeah, yeah. Okay, so what is your feature list? My feature list. So
00:21:59
Speaker
So in GRAM02, which came out in January, I believe, we supported compiling to different platforms. So now you can target the browser platform.
00:22:13
Speaker
which essentially just provides you APIs that allow you to write browser single-page applications, essentially what Elm already provides. But you can also say, I'm going to target node, in which case you get some node-specific APIs. And you can also say, I'm going to target neither of those platforms, in which case you're limited to this cross-platform API that works in both worlds.
00:22:42
Speaker
So that's what you can do now. So you can write node applications or browser applications, or you can write packages that can be pulled into both types of projects. And then what I've been focusing on now for the last six months is testing and debugging.
00:22:59
Speaker
So for a couple of months ago, I released the GREN test framework. So you can now pull in local meaning on-disk projects that you can test before you do a release, for instance.
Challenges in Feature Development
00:23:16
Speaker
And when the next release comes out, GREN will create source maps.
00:23:25
Speaker
which is a way of teaching the browser or Node.js how the generated JavaScript output relates to the original source files. So in the debugger, in the Chrome DevTools or whatnot, you can actually debug GRAM source code instead of the generated JavaScript. Yeah, it throws a JavaScript error, but it points you to where your code actually has some meaning.
00:23:47
Speaker
Exactly. Not to mention you can actually step through grand code line by line. That really helps. So that's like the immediate thing that I'm
GREN's Roadmap
00:24:02
Speaker
working on. And the next thing is working on what we're calling parametric modules or what is known in OCaml as functors. Okay. So it's a way of saying that I have a module
00:24:18
Speaker
And this module requires some abstract module as input, and then it will give you a concrete implementation of that module in return.
00:24:36
Speaker
So, for instance, I can create a dictionary module for a dictionary type. And I can say that in order to actually realize this module, in order to import this module,
00:24:53
Speaker
you need to give this module another module as input. It's kind of like a higher-order module thing going on. And that module has to have a type alias and a compare function, for instance. And then using that, the compiler can kind of generate a dict implementation for you that is specialized for strings.
00:25:23
Speaker
or integers or whatever type you want to have. How is that going to differ from just having type variables on the regular module?
00:25:40
Speaker
The normal way to solve things like this in other languages would be interfaces or type classes or protocols or whatnot. The difference here is that instead of doing runtime polymorphism, we're essentially generating a new module for you ahead of time.
00:26:01
Speaker
Ah. So we're essentially creating you a specialized dict module for every type you want to use it with instead of creating this runtime dictionary of types and matching implementations. So is that more efficient when it finally gets to runtime?
00:26:19
Speaker
It can be. From a performance standpoint, the benefit here is that the compiler will at any one time know exactly what functions and types are involved. So the compiler can optimize around that.
00:26:36
Speaker
Whether we actually make use of that in the code generation depends, because since we're also targeting browsers, I have to consider code size as well. But you can do that. The compiler can in fact know exactly what types are involved, instead of knowing that there is some dynamic thing here that I will figure out at runtime.
00:26:57
Speaker
Yeah, because the generated types of JavaScript for a lot of these things is at runtime looking up in a hidden parameter dictionary itself, which particular implementation it should be using for this single function call. And that always feels kind of inefficient.
00:27:16
Speaker
Of course, the JavaScript runtime is specialized in this, so it's relatively fast. From a code generation standpoint, that's the benefit you get. You know exactly what function you're going to call, so you can optimize around that. From a user standpoint, I think the main benefit is that it's
00:27:40
Speaker
It's simpler because as a user, you also know the types involved, right? Because you have to say that this is a string dictionary. And so you also know exactly what types are involved. And the error messages you get can potentially be a lot more concrete than saying you're supposed to send in a comparable, but you've sent in not comparable.
00:28:02
Speaker
Right, yeah. So we can be a lot more concrete in the feedback we give to the user. Yeah, in Haskell world, it's great that you can be super abstract, but sometimes your error messages are super abstract. Yeah. And that's, again, that's in trying to keep with the tradition of being very approachable.
Envisioning GREN's Future
00:28:23
Speaker
And I think that this will help us do that.
00:28:30
Speaker
But another benefit that I think some people probably see as a downside is that it's very hard to be super abstract with this. And I think that because you have to, as part of importing the module, you have to specify the exact type you're going to use. And if you want like three dictionaries over three different types, you have to import the module three times.
00:28:54
Speaker
So there is some boilerplate involved. And if you are going to have a parametric module that takes in the parametric module that takes in, like that sort of hierarchy will be very difficult to module. And that lack of flexibility in certain ways.
00:29:14
Speaker
is, I think, a feature. Because some people will see that lack of flexibility and think, ah, this language is limiting. I can't do exactly what I want. But the effect of that is that you don't go too crazy on the abstractions. And so I think the net result is that little pushback will keep you dealing with concrete things.
00:29:43
Speaker
overall is easier, I think. That comes back then to who is your target audience? Because it sounds like you're not trying to capture Haskell people. You've said you're not trying to capture the Elm market. Are you trying to capture the TypeScript people? I think there has been this thing said about
00:30:12
Speaker
I don't know how to say it. I get this impression that a lot of people think that Haskell is like a stepping stone to learn Haskell. Elm is a stepping stone to learn Haskell. Because Elm is so simple that you can learn Elm very easily. And once you learn Elm, you will start to notice all that it's so simple.
00:30:35
Speaker
that you can't do these crazy abstractions. And that's when you will take the next step and go to Haskell. And Elm is certainly simple to learn, but I also feel like the beauty of Elm is that things never get too crazy, that when you pull in the third-party library, you don't have to wrap your hand around why use this abstraction, why use this thing. And I think for a lot of people who don't value
00:31:09
Speaker
I think sometimes you just want to get things done. And so having a simple world is just really good for that. Yeah. Yeah, I think that's how I think I'm just going to stop there because it quickly becomes like, ah, these
00:31:24
Speaker
complexity-loving people. I don't have anything against that. But personally, I just enjoy simple languages that don't go too crazy on things. There is a place for that. I can enjoy dealing with language that has a lot of... I can enjoy working in Haskell, but not for work. For work, I just want to get things done without too much discussion and without too much experimentation. There's, I love puzzles. There's also no shame in shipping.
00:31:54
Speaker
Oh, there's actually when I'm thinking, actually, now that I have time to think about this more, there's another benefit to the parametric module approach. And that is that there is some more flexibility in how to implement certain interface. So in Haskell, if you want to implement, again, we're going back to a dictionary example, I'm going to have a dictionary, that dictionary is going to be sorted over some key. Yeah.
00:32:23
Speaker
And if you are writing something where it's a benefit to know the sort order and make use of that, then that can be pretty good. But sometimes maybe you want strings to be sorted in the reverse order, for some example. And if you want that, then you would kind of have to create a wrapper type in Haskell, and then you would have to implement a new comparison operator on that wrapped type.
00:32:53
Speaker
You have to do that because you can't have two implementations of the same type class. It's the same in Java, it's the same in Go. You can't have conflicting implementations of some interface. Whereas with the parametric modules approach, you can create a new module, and that module can have functions that work on strings without wrapping it at all. It's the module that you're sending in,
00:33:21
Speaker
as the input, not a type. If you wanted a dictionary that's sorted strings in reverse order for some reason, you could just create a new module. That module references the normal string type, and the comparison operation would just be like a reverse compare. You can use string at the keys, and then you can take the strings out and use them with any other string for a function without unwrapping and wrapping to make that happen.
00:33:46
Speaker
And you can use both in the single top-level module without them conflicting. Exactly, yeah. Yeah, OK. OK. So that is another benefit of it.
00:33:59
Speaker
OK, if that's your feature list for for Gren for the near future, I get to ask about my feature list because there are a couple of things that bothered me about Elm. I'm wondering if you're going to address. The first is Interop with JavaScript. Every now and then you want to do something from JavaScript. And Elm was always every new release had a new way of dealing with that.
00:34:25
Speaker
which was usually a breaking change that was undocumented, because if I can say this, Evan always punted the design question of Interop. Do you have an answer? So it's a tricky thing. So I get that, you know, for certain things, you don't want to recreate the wheel, reinvent the wheel by
00:34:54
Speaker
If you want to use a 3D library, you don't want to invent physics and 3D game creation just to be able to use some functionality in Elm or Grem. And that's quite relevant. But the problem we have is that one of the biggest benefits, I think, of Elm and of Grem is that there are no exceptions to the guarantees it provides. There is no mutability in Grem.
00:35:23
Speaker
none. You cannot even. There is no escape hatch from that. There is no other way, like, there are no exceptions and there are no escape patches for that. There is managed side effects and there are no other way of dealing with side effects. If you simply call JavaScript from anywhere, then you can have mutation. You can have exceptions. You can't, like, and so having
00:35:47
Speaker
having interrupt which essentially just lets you call JavaScript from anywhere Breaks the guarantees of language. Yeah, and that is something I'm super careful about maintaining like that for me Like the complexity of the language is one thing but also like the guarantees Yeah, you're able to count on those guarantees are if you don't have that then you might as well in my opinion use pure script, right so
00:36:14
Speaker
The trick is having a form of interop, which allows you to do the things that would be too much of an ordeal if you were to rewrite or port the library. That at the same time doesn't break the guarantees. And I've been thinking about it. I know that the current system of using ports can work in certain cases, but it's very difficult in other cases.
00:36:41
Speaker
And I've been thinking a little bit on how that could possibly be improved. But at the same time, it's a difficult question. And it's not the most important thing right now. So I'll say this. I agree with you that it could be better. But it's also not easy. Yeah, that's fair. It's not in the near future.
00:37:10
Speaker
I will probably look at it at some point, but not right. Okay. Okay. Let me just quickly ask you then as an aside, what, cause pure scripts answer to this is you define the types of the JavaScript functions you want and you define the side effects it has and we will believe you and it's up to you to get it right. What do you think of that approach? So that's, I believe that's how
00:37:38
Speaker
Elm worked in Sero 18, Sero 17. There was one release that took that away and everyone lost their minds. Me included. Yeah, there were a lot. I get that. Because there were a lot of people who had production code that relied on that thing we did as well. And it was non-trivial to work around it.
00:38:05
Speaker
What we discovered when we refactored a way out of that was that we did, in fact, have a lot of side effects. Not a lot, but we had side effects and we had mutations in the program that we didn't actually realize that we had. And so by writing ourselves out of it, we actually fixed a few bugs in the process.
00:38:33
Speaker
I think it was a race conditioner or something like that. That API never went away. It was just restricted to the core packages. As the author of Gren, there I did it again, Gren. As the author of Gren, I used that API constantly, and even I mess up every now and again.
00:39:03
Speaker
So I think that's one way to go. I hope to find something better than that. Because it's a bit too easy to introduce. And one thing is in your own applications. I have no problem with people breaking the world in their own application. The trick is how to limit it to applications.
00:39:31
Speaker
Rather than libraries that get published. Yeah, yeah, cuz the The problem like so I remember another thing that was removed in Elm Sarah 18 I believe was custom operators Which I think it was Sarah 18 and I know a lot of I know a few people left the community because of that because they had Written packages that made a lot of use of them and now suddenly that the rewrite everything to get it to work
00:40:02
Speaker
And I remember we discussed it because I was a member of the core team at the time. And one of the reasons for removing custom operators was that there was one package that did something, and it was the only package that did that thing. And it had this specific operator, and it didn't have a function implementation of it, so you had to use the operator. And I think the operator had five strange characters
00:40:31
Speaker
the operator was like, it was a big, entirely cryptic operator. And I think like if you read code that included that stuff, it was like, this is not what I think Elm should look like. Yeah, yeah. So so it's, yeah, I don't, I don't mind how people write their own applications. The problem is when you have a package that implements something very important, and you're kind of like playing by that packages rules.
00:41:01
Speaker
And so like the thing that I think would be a shame is that if I allowed some limited form of JavaScript interop and that bleeds into a package and then that package introduces mutations or side effects or anything, I would kind of feel like a big point of the ground language was lost. Yeah.
00:41:23
Speaker
If you get my meaning. Yeah, absolutely. Because in practice, a language is both its language and its libraries. So the guarantees that you're trying to offer have to extend the library ecosystem. That comes across to my other wish list feature from Elm, which was package management was always very locked down. And if you wanted to use a package as a corporation,
00:41:50
Speaker
If you had a package that you want to reuse across several projects, that was painful under Elm's package manager. Are you addressing that at all? I have, actually. So I felt the same pain, I think. I wrote a third-party package tool, I guess, for Elm that was called Elm Git install.
00:42:13
Speaker
which allowed you to import code from private git repositories, and it was a complete hack, but it worked well enough. In Gren, the first release had to have its own, like I couldn't rely on the own package manager, obviously, and so the solution I ended up with is that when you reference a package in Gren JSON, it will actually
00:42:41
Speaker
it will actually turn that package reference into a GitHub URL, and it will simply call your local Git installation on that GitHub URL. So the package managing in GRAM is simply using Git. And if you point that to a private GitHub repository, as long as you have access to that, that will work. And then I haven't gotten syntax
00:43:10
Speaker
Yeah, it does the job at least. There is, I haven't added syntax for referencing something other than GitHub, but there's no reason other than laziness for that. So if someone comes along and says, I would love to import stuff from GitLab, then I'll...
00:43:29
Speaker
Let's fix that. If someone gives me a syntax and everyone agrees that, yeah, this will be great, then that can be added very quickly. You make that sound desperately simple, everyone agreeing on syntax. Yeah. Wave that one away. So, yeah, so it's essentially just a Git-based package manager system, and then I have this
00:43:57
Speaker
for core packages to enforce those rules we just talked about, about not using certain private APIs of the compiler. If you try to download a core package, then it will validate the signing key of the last commit to make sure you're not trying to include a fork of the core library that does a lot of mutation or something like that.
00:44:24
Speaker
But other than that, it's just a pure Git-based package management system. That sounds pretty appealing to me. That would have solved a few headaches in my previous life. Yeah.
00:44:39
Speaker
Yeah, no, when I did this professionally, we only had like 90% of our dependencies were private dependencies that the corporation didn't want to get to be public. So we had this problem a lot as well. Yeah. Yeah. Even for like personal projects, I've had reusable libraries that just weren't in a state where I wanted to share them with the world. Even though it wasn't private, it was just like, I don't let people into my bedroom unless I have to.
00:45:08
Speaker
Yeah, yeah. And also, it's also when like, so when I'm creating new packages for Grand, I also have them private until it's ready to show it off, right? And being able to actually test that without doing magic is pretty good. So you've hinted on this in your easy hand waving of syntax, but what's the development process? Is there a community around it? Is there a team? Is it just you on your own?
00:45:38
Speaker
It's mostly just me, at least to work on it regularly. I have, there is a sullip for Gren, whichever one can join, and I try my best to write down all the language changes and API change, well, not necessarily API things, but I tried to write down all changes to the language as a proposal.
00:46:07
Speaker
And then I'll link it to the Caleb and then ask for feedback. Um, the grand community isn't that big right now. So mostly people just read it and gives me a thumbs up or something. Um, uh, and you know, I, since it's, since we're at this early state and I'm the de facto benevolent dictator, I do sometime ignore feedback, but I try very hard to share.
00:46:33
Speaker
all upcoming features and syncs and exchanges to get as much feedback as I can and take that into the development process. But when it comes, but there are, people have proposed things and people have implemented those changes after some feedback from me. And there are people right now working on some major APIs
00:46:59
Speaker
that they mostly do on their own and then check back with me every once in a while and then we get those things merged. I don't know if you've ever been angered by this, Chris, but in Elm, there is this limitation when updating records that the record you're updating has to be like a local variable. It can't be any expression. I don't think I've encountered that.
00:47:28
Speaker
No. Well, that is a limitation. And I'm not going to go through like the reason for why that is the case, but I've always, well, not always, but I've disagreed with that design choice in the past. So someone came into the sullip and say, I want to remove this limitation. I said, fine. And he did a pull request and then he got merged in time for gran02, for instance. Cool.
00:47:57
Speaker
So language change, I'm open for language changes as long as they don't break with like the core principles of the language, which is simplicity and having a very strict set of guarantees. But also on the API front, there is someone right now working on both the WebSocket API and a backend HTTP server API. Oh, nice. That's another thing I remember Elm being a little bit all over the place where there was WebSocket.
00:48:23
Speaker
Yeah, yeah, it exists as a language. It really suits like the whole architecture really suits the idea of real time streaming web sockets. Yeah. So, uh, yeah, I agree. Uh, so, and that's probably also one of the bigger changes from Elm is the development model. Um, I try to be very open on suggestions and contributions from others. So, um,
00:48:52
Speaker
And there's also very, there is a six month release cadence thing going on. So yeah, in general, more open for contributions than the elements. Which isn't like, I just have to say that right now. I don't necessarily disagree with the way the own project is run, but there are trade-offs being made and I'm choosing a different path.
00:49:18
Speaker
uh, with, uh, with the positives and negatives that are involved in that. I, do you know, I will, I'll allow myself to be a bit controversial there. I think the thing about Elm is it had a great design consistency because most of the development was kept in the head of one person who had great design chops. The downside of that was the speed of development kind of waxed and waned depending on what his life was doing. Yeah.
00:49:47
Speaker
And do you think in the future that Gren won't be entirely tied to Robin Hanson? I hope so. God, I hope so. So that's a strange... So I have a son who's turning three now. And the thing that happens when that happens to you,
00:50:15
Speaker
which is mostly good. But what happens to you as a person is you start thinking 10, 20, 30 years down the line. And I'm doing Graeme right now because I need something like this to exist and no one really stepped up to do that. And so I felt like if I'm not going to do it, it's just not going to happen. But I also have enough ideas for other things
00:50:44
Speaker
that I hope to be able to do someday in the future. Like maybe I spend 10 years on Gran. Wow, saying that out loud. But okay, let's say I spend 10 years on Gran. I hope to be able to like pass the torch to someone else. But at the very least, until Gran reaches 1.0, until we have a community around it that are like,
00:51:15
Speaker
Until we have a sense of what Guillen is and isn't, then I think it's best served by this single person development model. But yeah, in the future, I hope to change that. I don't expect or want to be in this role forever. I've got an Evelyn dictator until you can abdicate to a democracy.
00:51:42
Speaker
Yeah, yeah. I had a little bit of time in the university and I had this professor who once said that the ideal form of government is dictatorship and where in place of elections you have public execution. So that's not like
00:52:12
Speaker
Dictatorship is the most efficient way and the most consistent way of running a government, but at some point you have to come to the conclusion that the dictator has to go. Maybe we'll apply that more to software models than to running the highest-sized paper. Yeah, we can very quickly go into a completely different category of podcast on that one.
00:52:39
Speaker
So yeah, but I'm like, I am looking into size. I think like SIG, the language, it's called SIG, I think so. Had a very interest. Yeah. Yeah. Well, ZIG for a US audience. Yeah. I think they've had Andrew Kelly, I believe is the name of the creator of that one. I think they've had a very interesting
00:53:06
Speaker
approach where Andrew Kelly has been doing this in spare time and the language has evolved in a very consistent way. And now recently he formed the SIG Foundation, they have board members and they like gradually, my impression is at least that it's gradually becoming a more democratized process. But I think like if you worked, yeah. So I'll be exploring that in the future, but at least until we reach one hour, which is probably going to be me,
00:53:37
Speaker
with, but with an open mind for external contributions. Okay. Tell me a bit about that road to Wanda. Oh, you've talked about some of the features, but where are you trying to get to? Where will Grenby five years from now? So like, there's the parametric modules thing, and then I'm going to take a long hard look at the, at the core packages. And like, so there is
00:54:06
Speaker
It's a funny thing. If you look through the Elm core package, which Gren has inherited, you will find this module that is called, I think it's just called process. And if you read the documentation, it kind of hints that Elm is aiming for this Erlang style concurrency thing, but that it isn't finished. So it's like, watch this space, more will come, right? And then nothing happened to it.
00:54:35
Speaker
So one of the things to look at after the parametric modules thing is just go through the packages, find the clues hidden there, and then try to complete the language in a way. And then another thing to explore, and that is something I think which will just be a continuous evolution thing, is to add
00:54:58
Speaker
missing APIs. There is this mailing list entry, an email, I guess, that I think you can find if you Google for it, but at once, like long ago, maybe in 2016, I think, Elm decided, or Evan decided that Elm is going to be
00:55:26
Speaker
you won't be able to just use interrupt wherever you want. The thing you mentioned earlier, there was a point in time where that was decided. And then people would ask, well, how do you support things like WebSockets? And how do you support other browser APIs as they appear? And the answer at that time was, well, if you think about it, there really aren't that many web APIs. So creating this immutable version of that API should be entirely possible.
00:55:57
Speaker
and expose that to the ecosystem. And I think that's part of the reason why Alma stalled a bit, because that is a lot of work. And finding people you trust to delegate that work to isn't necessarily easy. But I also think that's necessary if you want all the capabilities of the VAD platform or the Node platform, but at the same time remain or retain these
00:56:29
Speaker
immutable managed side effects guarantees. And where I'm going with this is that another thing to continuously work with on the road to 1.0 is to find people who are willing to implement those APIs and help them through the process and together create a community.
00:56:50
Speaker
Yeah. So that's another important thing to do. Just add APIs. And then it's going to be tricky to know exactly when to stop, for instance. But for Node, Node has a built-in standard library that gives you a lot of the building blocks you need to further build anything on top of it, really.
00:57:12
Speaker
And so one of the things that I want to have before 1.0 is to support as many of those built-in APIs that Node has. Yeah. If someone wanted to contribute to that effort, what are they actually doing? Are they writing Gren? Are they writing JavaScript? Are they writing, I think, the compilers written in Haskell? What skills do you need to be that person?
00:57:39
Speaker
Good question. I think just to track back a little bit, I think, honestly, I would be very happy if people just wrote Gren and told me about the things they liked and didn't like. That would, first of all, be hugely helpful. And another thing that's hugely helpful is, like I mentioned that I
00:57:59
Speaker
publish language proposals to the Grand Solip and getting detailed feedback on that would be nice. If you want to help the project along, you don't actually need to develop things for it. Just giving your thoughts is a very valid way of contributing. Like I said, there is someone right now working on HTTP server API.
00:58:24
Speaker
And I know he would love to get feedback on the current design. So that's one way of contributing. Just, you know, provide your expertise and give feedback on the things that are in the works right now. And if you want to contribute with code, then it's really up to you. I would love help with the core library, which means you would be writing mostly GRIM. But if you wanted to
00:58:53
Speaker
add support for Web API, there will be some JavaScript involved. Nothing too difficult. But there is the Interop API you mentioned earlier. It's still not very well documented, and it will crash if you look at it in a strange way. So there is some arcane lore you need to know in order to contribute JavaScript to your project.
00:59:17
Speaker
but entirely possible. And if you want to help out in the compiler, there are many things to do there. And yeah, that would require Haskell knowledge. So at this stage of development, you can help in pretty much any way or form you like. Okay, then we should probably end on how you just, rather than becoming a contributor, we should end on how you become a user. So I know you start with npm install gren-lang.
00:59:46
Speaker
Yeah. What should I do after that? So I think it's, I don't, I think it's, um, yes. Oh, well, I guess if, uh, there is an attempt at documenting the language, uh, at our website, so there's a, there's a link to a book.
01:00:10
Speaker
It's mostly unfinished. And if people would love to help out on that, I'd welcome it. But you get some documentation of the language there. And at this moment in time, the language is still resembling Elm, even though it's not 100% compatible. So if you find Elm resource, you can learn a lot there as well.
01:00:30
Speaker
And then we have a packages website that contains documentation for the core package and most of the official packages. And if you develop a package, you can also register it at the site and get documentation uploaded there and get the word out, essentially. Cool.
01:00:54
Speaker
And that sounds like another fun thing to add to my to-do list of things to play with. I might try porting some of my old untouched Elm code and see how that works out. Well, I would love to have remote data on the ground. That's my one claim to fame in the functional programming world. Yes, yes. Cool. That gives me a project for the next few weeks. Robin, thank you very much for joining us. Oh, no worries. Thank you for having me.
01:01:24
Speaker
Thank you, Robert. So, an accessible, safe, functional language that's targeting all the places it needs to take you. I think there are a few people vying to be the leaders in that space, but I also think whoever wins, you and I win, right? We're the richer for it. Or maybe it's not a competition at all. Maybe it's just this rich pool of ideas that are going to take us swimming to a better software future.
01:01:52
Speaker
Regardless, we'll be back next week with more wonderful ideas floating in that pool, so now might be the right time to hit subscribe or like or rate or share and let the algorithms know that you want to know when we're back. In the meantime, if you want to try writing some Gren, there's a link to Grenlang.org in the show notes.
01:02:13
Speaker
There's also a link to some example Gren projects, which is a great way to see what it would be like to write Gren in practice. And I'll also put a link to elmlang.org in the show notes too, in case you want to kick the tires on Elm. And that should be more than enough food for thought until next week, so I'll sign off. I've been your host, Chris Jenkins. This has been Developer Voices with Robin Hedlund Hanson. Thanks for listening.