upvote
Gleam is not ostensibly intended for building user interfaces.
reply
I still don't know what gleam is for tbh. I like it conceptually. But interop with for instance elixir libraries is not as seamless as you'd like.
reply
I use it mostly for web APIs / services, it's great for that!

Interop is not seamless since Elixir does not have the same static type system, but it is possible and that does help sometimes. When resizing images for example, I fall back to Elixir's bindings to libvips. I've also used Oban from Gleam in the past.

reply
It's a general purpose programming language, like OCaml, Python, or Scheme. It's not intended for any specific business domain.
reply
Then, why is JavaScript a compilation target? If you're not using it on the client-side, then why not stay exclusive to the BEAM?
reply
JavaScript is useful in lots of places, and even if one compile target is especially good for in-browser user interfaces that doesn't mean that language is specifically intended for user interface development.
reply
deleted
reply
You can do a lot more with JavaScript than building UIs.
reply
Yeah. I know. I use it every day. That doesn't answer my question. Why would I want to write something in Gleam if I want it to run in a JavaScript engine? When would that ever make sense? Could you please just engage with me in good faith?

Multiple compilation targets require increased implementation complexity so you would think they would have a good reason for when you would compile to one target or the other. I couldn't find any information about it on their website, so I was hoping you would actually respond with something helpful rather than... that.

reply
So, you started by making a pointed comment about that the language has no string interpolation when it's ostensibly for building UIs, so I'm not sure why you're surprised you're getting responses like mine or the one from lpil. Gleam is not ostensibly meant for building UIs just because it targets JS, and while you don't get string interpolation in the way you might get in other languages you can go pretty far with the <> syntax.

To answer your question about why you would use Gleam when you're running code in a JS engine, it's the same about any language that compiles down to another, such as Clojure, and you can take your pick of those reasons: preference, syntax, pragmatism, etc. I'm not sure what kind of answer you're looking for beyond that.

reply
I'm looking for the intention behind it. They chose two compilation targets. That made things harder. They had a reason. That's what I'm asking about.

None of your reasons ("preference, syntax, pragmatism") fully explain the situation without more context. Whose preference? What syntax are users even seeing? Why is it pragmatic?

Compilation targets are generally chosen based on performance characteristics and where the code is actually expected to be run. If you're not expecting the code to run on the client, then there's no reason to use JavaScript. V8 performance is better when single-threaded, but then why use the actor model?

When I go to the ClojureScript website, they have a whole section about why they chose JavaScript as a compilation target[0]. Notably, it mentions the word "client" multiple times.

[0] https://clojurescript.org/about/rationale

reply
It's a general purpose language (as mentioned several times) and compiling to js eg. for lustre webapps (elm-ish). I've contributed to the js compiler once only and can't find a way to use more gleam at my job but I'd say having failsafe actor based erlang backend + ssr + rich strongly typed reactive frontend all in one language is really cool.

It seems your stuck on js-only for ui and somehow rejecting compile to js. If you don't wanna use it fine but I'm not sure what you're looking for in this thread...

reply
deleted
reply
gleam is very much a language of "no" which if you like that, cool, if not, also cool :)
reply