What would make a backend language appealing to you?

Request Feedback
1

Hello!

I’ve spent the last few years making a programming language called Gleam. It runs on the Erlang virtual machine and has a type system very much inspired by Elm.

My goal has been largely to bring many Elm like characteristics (ease of refactoring, safety, guiding API design) to the Erlang VM, and largely Erlang + Elixir people have been interested in the results!

I’m now wondering whether we (Gleam + Erlang + Elixir users) have something we could offer the Elm community in exchange.

As Elm users, what would make a backend language attractive to you? Are there specific features, libraries, or integrations that would make you want to try out Gleam? (Or Elixir, etc). Or are your backend needs satisfied already?

Thanks,
Louis

21 Likes
2

Having proper basic types for one.

For example documentation of Gleam Int/Float is quite scarce, and I can’t find information about whether Gleam has implemented these properly or whether Gleam is copying the awful Int/Float distinction from Elm.

For example:

  • What are the limits of Int? What happens when you go over the limits?
  • Is it possible to create Int which is not an integer (e.g. NaN, +Infinity, -Infinity, 12.34)
  • Are functions like round implemented both as Float -> Int and Float -> Float?

p.s. At least Gleam seems to use proper UTF-8 String and doesn’t copy Elm String.

1 Like
3

I am very interested in Gleam - I currently use Elixir for my backends, but I’d prefer a static-typed option with some of the same nicenesses that Elm offers in terms of a helpful compiler and friendly error messages.

The main things I would need to move to Gleam would be:

  • A web framework/HTTP server that also does websockets (like Phoenix, but I can live without most of the routing and HTML templating stuff)
  • A nice way to encode and decode JSON into Gleam types
  • A nice way to interact with SQL databases

Edit:

Oh, and also:

9 Likes
4

Firstly wanted to say that I’ve been following your Gleam work with excitement, so thank you!

I actually have Gleam installed right now to test out, just haven’t had the time to get to it beyond

pub fn hello_world() -> String {
  "Hello, from hex_server!"
}

but it’s still open in a VSCode window right now :smiley:

As primarily a front end dev, back end has been hard to get into because so many back end languages do implicit imports (F#, Elixir, etc) and general implicit code. The other part is error messages. I’ve tried a bit of Nim, Elixir, Haskell, and many others but nothing has compared to Elm’s error messages for me.

Hopefully I can get to writing some Gleam this week(end) and let you know if there’s anything that would help me.

Edit:
Also the Elm compiler is amazingly simple for getting started with the only steps you need being

  • install the compile
  • elm install some/package
  • elm reactor or elm make Main.elm

After that it can get more complicated but that’s up to the dev on how complicated they want to get.

2 Likes
5

Great feedback everyone, thank you.

Int has no limits in Gleam + Erlang. You can go as large as you want.

No, this is not possible. If it were possible this would be considered a bug and would be fixed.

Yes, there are no type classes or similar, unlike in Elm.

Sounds like we’re interested in similar things.

Would a tool that generated Elm types and JSON decoders from Gleam be a big deal or is that not so important?

This is something I’m working on at the moment, so hopefully we’ll have a similar experience :slight_smile:

1 Like
6

Would a tool that generated Elm types and JSON decoders from Gleam be a big deal or is that not so important?

The big pain for me with e.g. an Elixir backend isn’t so much writing the Elm encoders and decoders, it’s the fact that Elixir doesn’t have a nice way to handle Elm data structures such as custom types/union types/tagged unions. It’s the mental overhead of converting Elm custom types to JSON objects/arrays to Elixir tagged tuples and back again that’s a bit wearisome (especially when a database is involved and it’s actually Elm → JSON → Elixir → Ecto → SQL → Ecto → Elixir → JSON → Elm).

I think that because Gleam supports custom types in a very similar way to Elm, it will be much less of a bother. That said, a tool that could look at Elm types/encoders/decoders and translate them to Gleam (or vice versa) might certainly be a time-saver in many situations.

3 Likes
7

I tend to use Erlang/Elixir’s tag tuples and atoms like custom types in Elm, is there something that could be added to make them work better?

type Role
  = Teacher
  | Student
  | Other(String)

@type role() ::
  :teacher
  | :student
  | {:other, String.t()}
2 Likes
8

Yes, I do it that way too… I guess my frustration is more just that there’s no type safety on the Elixir end, so even when you go to the effort of defining tagged tuple types, those type annotations don’t really do anything, except occasionally produce cryptic Dialyzer errors :slight_smile:

1 Like
9

Would love Elm syntax + concurrency on the back-end.

4 Likes
10

In my case what I would be looking for is stuff I can demploy as Lambda functions and has good AWS
API integration.

2 Likes
11

I’ve been working on a little CI-server side project with Elm, Elixir and Gleam (handling all of the code for running jobs, hopefully expanding to cover more eventually) and so far, the experience has been great!

I haven’t found anything lacking in the core language. My wish list is an assortment of library and tooling features. A lot of them boil down to “make the cool things about the BEAM more accessible and type-safe”. It’s also worth mentioning for context that I don’t have a lot of previous practical experience with Erlang and Elixir.

An OTP package is something I look forward to. Right now I’ve just copied gleam-lang/otp into my project and slightly modified it to suit my needs, but It’ll be nice to use shared code for that.

Hot code replacement is a really interesting feature of the platform, but I’ve always heard it’s a bit of a minefield due to new messages landing in old code and vice-versa. I wonder if having strong-types and version-aware tooling could detect breaking message changes on upgrades, or provide better tools to manage those transitions, like enforcing code paths for unrecognized messages?

In the work I’ve done so far, I think I would get more value out of Gleam by extending it’s use into the Ecto data layer of the project rather than the HTTP request management bits. I think the type safety provides more value when it comes to persisting data, although I recognize that an HTTP server is probably useful in a wider range of projects.

The thing that would get me excited to work with a HTTP server in gleam would be a nice API that supported HTTP/2, in particular, push support. I’m probably an outlier here, but I have been thinking for a while about an API approach that might be a good compromise between GraphQL and REST, but it would require push, and I haven’t found a back-end language I enjoy working with enough to get around to experimenting with it!

I also have a vague notion that there are some nice tools for inspecting analyzing running Erlang/Elixir systems - I suspect they could be used directly with Gleam since the generated Erlang is fairly readable, but something Gleam-aware would be really quite nice.

Regardless of whether or not any or all of those things get built, I suspect I’ll continue to use and enjoy Gleam in the future. It’s off to an excellent start! Thanks for all the hard work!

2 Likes
12

Gleam doesn’t have ML syntax I’m afraid. Have you checked out Haskell, PureScript, OCaml, or ReasonML? I think they would all fit that nicely!

Gleam is all about the Erlang VM, and it’s not a great fit for AWS Lambda. I’d probably look at a compile-to-JavaScript language such as PureScript or OCaml using Bucklescript. Or Go if you’re interested in imperitive languages.

Apologies, that library is not as mature as I’d like it to be. It’s a really fun thing to work on and I think we have some really good solutions to typed actors but I keep getting delayed by compiler work. Lots to do :slight_smile:

Hot code loading is a really interesting area, and I think it would be possible to use types in order to make them safer, but some complex R&D work needs to be done here.

Without some kind of special support for them hot code upgrades completely destroy any notion of type safety as it means that code is mutable and extremely dynamic. Seeing as hot code loading is very rarely used in production (I would argue you probably shouldn’t use it unless you have a really specific business requirement) Gleam has opted to have no official support for it so that we can focus on higher value features.

One thing I am very interested in is type-safe database querying. I believe I now have a robust approach (inspired by type safe database query libraries in F# and Rust), I just need the time to experiment with implementations. Once we have that it’ll be a huge boost to Gleam’s appeal as a backend language.

Peter Saxton, the creator of Elixir’s HTTP2 server, is working on a pure Gleam web server and framework called Lean and Midas. He’s stated that HTTP2 isn’t a goal for the project, but perhaps you could persuade him otherwise. :slight_smile:

Thank you

1 Like
13

IMO Gleam is worth at least a brief look if your idea of the ideal backend language is Elm + concurrency. The syntax is different, but to me writing Gleam still feels a lot like Elm.

No need for apologies. I had to change maybe 5-6 lines of code to fit my use case. It wasn’t bad at all, and I learned a decent amount along the way. I fully recognize that it’s early days for the language and priorities mean some things have to wait.

2 Likes
14

I like the direction you are going with Gleam. I love Elixir, but wish it had some of the ergonomics of Elm. Specifically, union types and a strong (dare I say, dogmatic) type system. I like the pattern matching of Elixir. That’s one thing that Elm doesn’t do.

The toughest part is that I want a vibrant, growing ecosystem. I admire the challenge you are taking on. Building a community around a new language is a bit of a chicken-and-egg scenario. You need the community to get lots of users, but you need lots of users to have a community.

5 Likes
15

I like the pattern matching of Elixir, that’s one thing that Elm doesn’t do

I’m confused by this statement, can you expand on it? Maybe an example of something possible in Elixir and not in Elm?

1 Like
16

Hi! Gleam looks very promising to me!

One thing I love in Elm and I cannot find in another backend language is the built-in Architecture and the very clear and opinionated path between the toy app (with Browser.sandbox) and the fully-fledged application. It made the acculturation less scary for the total beginner I was.

I don’t know how it can transpose to Gleam but it’s definitely a concept that worths an investigation. Picking a language and having to choose between 4-5 frameworks doing too much or not enough is something that repeatedly made me give up my learning effort…

3 Likes
17

Could you give an example here? :slight_smile:

That’s a really good bit of info, thank you!

Have you tried Ruby’s Rails, Python’s Django or Elixir’s Phoenix? They’re very opinionated and convention based backend web frameworks that for me have fit that TEA-like niche. I would be interested in knowing if there’s something that could be improved from your point of view.

18

I haven’t found a backend language that I’m happy with. I have tried many languages (Ruby, Python, JS, Rust, Nim, Haskell, Ocaml, Elixir, Go) but I don’t quite like them for different reasons e.g. slow compilation, hard to learn, bad error handling, no/unsound type system, poor tooling, unnecessary complexity, very little documentation, etc.

I have been following Gleam and for me it looks very attractive for building web backends. I would have liked an ML syntax, but no big deal. I have high hopes.

Specific things I would love to see in the near future:

  • A web framework
  • Authentication library
  • JWTs
  • GraphQL server
  • Postgres client
  • Date time library

Thanks

1 Like
19

Elixir can pattern match on args in function heads, which is something I miss in Elm.

def my_func(%{"foo" => foo}), do: ...
def my_func(%{"bar" => bar}), do: ...
20

Hello @lpil this isn’t answering your question but is more of a bit of feedback, hopefully helpful. I got interested and went to the link you provided, which is the github page, which in turn links to https://gleam.run/
Scouring through that I was trying to answer the question “is this a pure functional language” and I cannot really do that (quickly) from either of those two places. I was really interested to see how you were going to do, for example, database access. I ended up taking a look at the example-url-shorterner, which has the following:

fn get_link(id) {
  case db.get(id) {
    Ok(link) ->
      Response(200, [], link)

    Error(_) ->
      Response(404, [], html.not_found())
  }
}

So that seems to me as if there are side-effects in the language so it isn’t pure. In addition I looked at the ‘Try’ section of the language tour (https://gleam.run/tour/try.html) and it shows:

case parse_int("123") {
    Error(e) -> io.println("That wasn't an Int")
      Ok(i) -> io.println("We parsed the Int")
}

That looks like it’s definitely an impure language. So I guess I’m suggesting that this information up-front would be handy, perhaps in the ‘Gleam principles’, or even if the ‘Hello Gleam’ program actually printed “hello world” to the screen, that’s what I was expecting when I went to that section, and the fact that it didn’t do that, made me think “oh, maybe it’s a pure language”. I guess I also thought that because you were posting on the Elm discourse and saying “very much inspired by Elm”.

So obviously that’s a pretty minor point, and you cannot have all the language design choices up-front in the main blurb. However, and I mean this as wholly constructive feedback, I’m still kind of lacking the whole point of the language. From the blurb, the whole raison d’etre for the language is simply that you wanted a statically typed language that targets the erlang BEAM. Is that correct? If not, that’s the impression I got. All of the other design choices, are basically “just” your personal preference (again, that’s they way it comes across, I’m not saying that’s the reality). So I suppose in summary, what I’m saying is the website is lacking a ‘vision’. In particular, if that was your goal, explaining why you didn’t re-target an existing functional language would go a long way to explaining the why of Gleam.

Note, I’m specifically saying the ‘website’, I’m not saying your project lacks a vision, just that it isn’t conveyed well on your webpage. At the moment, I’m having a hard time figuring out why I might be interested in Gleam, in particular why might I be interested in Gleam over more mature, funded, supported languages such as F#, Kotlin, or O’Caml which (from what I have understood) are similar in that they are impure strictly evaluated functional languages with static type systems and type inference.

In very marketing terms, what is the unique selling point?

2 Likes