I haven't tried Gleam yet, though. I'm interested in the focus on simplicity but a little wary because I understand they sacrificed niceties to minimize the language footprint, e.g., pattern matching in function heads. I intend to give it a shot the next time I'm greenfielding something.
Edit: pure* functional
Odd, but I believe you, lol. Elixir's list comprehensions take a `:reduce` option which makes accumulating values a bit more "familiar" and I often use over `reduce`:
for a <- list, reduce: []
acc ->
[a | acc]
end
Also tbh, I don't like reduce either. I agree with that article posted on HN a while back about devs not liking reduce. Just want to insert into my list or whatever.
https://gleam.run/frequently-asked-questions/#How-does-Gleam...
> I'd say if you know and like Rust, then Gleam should be easy to pick up
And you think that:
> a Rust programmer is more likely to prefer Gleam to Elixir
Are we maybe splitting hairs here?
This is way too strong and narrow statement. Gleam is statically typed garbage collected language, closer to OCaml than Rust. Elixir if you like dynamically typed instead.
The languages that Gleam is most like might be Standard ML, OCaml, Elm, and F#.
That is: they aren't similar languages on a technical level, but if you know Rust, you should be able to make the jump to Gleam pretty quickly.
It can take a moment to understand that things are done quite differently in the two languages due to being so different: https://gleam.run/frequently-asked-questions/#How-does-Gleam...
I think by sentiments like this, people mean if you know unions, records, and pattern matching then you'll more easily pick up another language that has unions, records, and pattern matching.
The language itself is as welcoming. Even LLMs are less cranky and output nicer code, not having to deal with React.
[1]: https://nestful.app/
[edit - this might have been ambiguous. I meant that it shows he really cares about the fine details.]
Rust is a very poor compile target as the compiler is slow and not commonly available, and the aspects of Rust that make it good for humans to write make it a poor choice for compilers to target. With humans the produced code is verified, but with a compiler the compiler is what is to be verified, so the inflexibility of Rust are largely a hindrance compared to other native compilation targets.
I really love gleam and its community and I would really really love if gleam could be more like golang though, which can help it in compiling to machine code
gleam language but with the developer experience of golang (cross portability/small binaries/fast compiled language which is fast to compile) is honestly one of my fever dreams and I would love to know if it can ever be a reality!
> cross portability/small binaries/fast compiled language which is fast to compile
You don't need native compilation to build fast single file executables for a program, there's ways one can achieve this with Gleam today. Bundling the BEAM into your Gleam application executable with something like Gleepack is one option, and this will produce smaller executables than Go will by default for many applications.
- server target: BEAM
- client target: js
Once you've covered those bases, you're kind of done.
If the server needs to do something special in an OS process... might as well let the OS mediate that interaction so that it can be fully generic, rather than trying to bend the language around whatever the unknown action might be.
From the article:
> Over the last few months Giacomo Cavalieri has entirely rewritten Gleam's Erlang code generator that has an entirely different design, and most notably, outputs a different format. Previously Gleam generated Erlang source code, now it generates Erlang abstract forms.
Source was the previous target as at the time Erlang Abstract Terms was not established as the go-to format (Core Erlang was more popular but it did not have a stable API outside of the BEAM, so Gleam's in-Rust compiler could not construct it), and due to the newness of the language having an "escape hatch" where one could abandon Gleam and eject to Erlang was highly valuable. It also meant we could use the Erlang build tool until the Gleam one was ready for use.
Ok but this footnote comes at the end of a paragraph describing how the previous transpiler implementation was inferior to the new compiler. It's ok to make these distinctions.
I was surprised to find Matt Mullenweg among the sponsors.
All I understand from the frontpage is that it's typesafe. Good I guess? Then there is something about Erlang which I never used.
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.
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.
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.
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.
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...
[0] Australian Government Publishing Service's Style Manual for Authors, Editors and Printers, ISBN: 978 0 7016 3648 7
[1] The Canadian style: a guide to writing and editing https://archive.org/details/canadianstylegui0000unse
Formally, most comma use is an issue of style, not grammar, and style guides differ on when they should and shouldn't be used. The main rule that's actually a matter of grammar is this: commas cannot be used to join two "clauses" (phrases which could be independent sentences) without a conjunction.
There's a caveat where some style guides permit using a comma without a conjunction in specific contexts, but most don't.
The lack or excess of commas doesn't upset any reasonable person in the slightest.
And almost nobody writes sentences like "I love her and she loves me back" with a comma before "and".
but talking pejorative, i was surprised. my opinion of gleam was already pretty low, but i did not expect to see post-1.0 compiler emitting text erlang source. maybe it's not that good of idea to implement compiler in language completely foreign to target ecosystem.
I think you're overthinking the cost of compiling to source, and also underestimating how common it is.
Imagine a doctor about to do surgery and opening a toy box
most BEAM languages actually settle on erlang abstract format. you'd think core erlang would be more common since it feels more like a traditional functional IR, but basically only LFE does this, because it's a moving target without any particular stability guarantees from release to release.
1: https://www.erlang.org/doc/apps/stdlib/erl_parse.html#t:abst...
2: https://www.erlang.org/doc/apps/stdlib/qlc.html#q/2
3: https://www.erlang.org/doc/apps/syntax_tools/merl.html
https://github.com/lfe/lfe/blob/387d0aa1092bdda0ca17481869e8...
https://github.com/lfe/lfe/blob/387d0aa1092bdda0ca17481869e8...