I've been interested in Gleam, but I didn't realise it just transpiles to Erlang, I thought it compiled directly to BEAM bytecode. Bit of a turnoff to be honest, I really don't want to deal with transpilation.
Which part do you feel like would be an issue? When you run `gleam compile`, it will automatically call the Erlang compiler to finish the job.
I find it very handy that the intermediate Erlang (or JS) files are available in the build directory. It lets you easily see what form your code will take when compiled.
Also prevents lock-in if you ever need to move away from gleam.
I don't think it's the transpile part that would the issue, it's the runtime aspect. If Gleam transpiles to Erlang/Javascript that's great but once you run the program, you have to potentially deal with runtime issues specific to those environments which you might not be familiar with.
It seems that Gleam is really useful for those who are already in either the Erlang/Javascript ecosystem.
On the contrary, it's a great first BEAM language to learn because of it's simplicity - both in terms of the grammar as well as it's tooling/compiler.
For me personally, the Javascript target is the least interesting bit - the BEAM/Erlang target is where it's at for backend work. The BEAM is fascinating and full of ideas that were once ahead-of-their-time but now are really coming into their own with compute performance having caught up.
Gleam is a strongly typed language, and is unapologetically very functional. Error handling in general is quite different than it would be on a normal stack-based language/vm. In my experience, the Erlang target doesn't make debugging any harder or more difficult than you would expect for an exception-less language.
The JS target is also very interesting to me. I like erlang fine and elixir's nascent type system is promising. But the frontend (and js fullstack for that matter) currently does not have a good alternative to typescript, and the ML type system is an especially good fit for it. Elm has too much reputational baggage and rescript/reason/bucklescript/whatever squandered its momentum and is floundering.
Another layer of abstraction, another thing to go wrong, another thing to rot.
Gleam used to compile to Core Erlang (Erlang Intermediate Representation) but looks like it now compiles to pretty-printed Erlang.
https://blog.lambdaclass.com/an-interview-with-the-creator-o...
The relevant quote:
> The Gleam compiler has had a few full rewrites. The previous version compiled to BEAM bytecode via Core Erlang, which is an intermediate representation with the Erlang compiler, but the current version compiles to regular Erlang source code that has been pretty-printed. This has a few nice advantages such as providing an escape hatch for people who no longer wish to use Gleam, and enabling Erlang/Elixir/etc projects to use libraries written in Gleam without having to install the Gleam compiler.
Pretty good reasoning in my opinion.
It makes perfect sense to target erlang and not BEAM directly as allows erlang compiler to optimize the code for the newer BEAM runtime with newer fancier opcodes.
the gleam tour is also very good https://tour.gleam.run/
very very good
From the tutorial:
// Division by zero is not an error
io.debug(3.14 /. 0.0)
It prints 0
Yuck. Division by zero is an unfortunate reality but basically nobody with mathematical background thinks that just defining x/0 = 0 is a good solution.
Often in numerical computing, getting an NaN or Inf is a blessing in that it’s a hint that your algorithm is numerically buggy, in the same way that a crash or a exception would indicate a program bug.
This approach is the numeric equivalent of a program continuing on after an undefined variable, just assuming it’s 0. That was tried by scripting languages in the 90s and these days most folks think it was a bad approach.
The divide-by-zero thing is explained here[1]. The relevant bits:
> Gleam does not implicitly throw exceptions, so throwing an exception is not an option. The BEAM VM does not have a Infinity value, so that is not an option. Therefore Gleam returns 0 when dividing by zero.
> The standard library provides functions which return a Result type for division by zero which you can use if that is more suitable for your program.
You can also use Guards[2] to prevent handle a divide-by-zero situation before you attempt it.
[1] https://gleam.run/frequently-asked-questions/#why-does-divis...
I wouldn't call myself a person with a mathematical background, but there are those people who believe it's just fine. [0] I don't have enough knowledge to debate that, but it would seem to disprove "basically nobody". Zero is a convention, like NaN or Inf are conventions.
A problem that Gleam has here is that the Erlang runtime does not have NaN or Inf in its float type (or integer type for that matter). It could be represented with an atom, but that would require an atom and a float having the same type in Gleam, which is not something the type system can do (by design). The operator could, in theory, return a Result(Float, DivisionByZeroError), but that would make using it very inconvenient. Thus zero was chosen, and there is an equivalent function in the stdlib that returns a result instead, if you wish to check for division by zero.
Regardless of what happens in the language, this needs to be handled.
In python for instance, the developer needs to be prepared to catch a divide by zero exception.
In gleam, the same consideration is required but the implementation will just differ.
I don't actually see an issue here. It's a potential gotcha, but once you are aware of this feature of the language, it's no different than any other.
No.
In Python and languages with similar behavior, a division by 0 will immediately crash your program with a pretty stack trace, showing you exactly where the problem is and how the program got there.
In languages where division by 0 produces infinity, NaN, 0 or similar, your calculation just returns a nonsensical result.
Zero is even worse than inf or NaN, as you may not even realize that there was an error in the first place, as the result of your calculation is a number and not a strange-looking value.
I have no math background but every line of code I wrote that involved a division, I just wished that division by 0 results in 0, so this actually resonated with me
INTERCAL. It just skips lines if they're syntactically invalid or cause a runtime error; it just skips them and keeps going.
Yeah you can really get yourself into trouble if you make dividing by zero zero. It's a strong indication that you have done something horribly wrong in your code upstream of that point. Why would you throw away that signal?
I honestly gave gleam a serious look, considering it to build a system that might really benefit from it's concurrency model. However the lack of Macros/macro-style reflection capabilities really put me off. It makes working with SQL databases needlessly verbose. It's the same with go, though go posses the capabilities to directly unmarshal SQL rows into a structure with tags, it's far from straightforward.
This is the sentiment many have when transitioning from OOP -> FP paradigms.
That's not to say ORM's don't exist in FP, but they are not nearly as common because their concept doesn't directly translate into what you expect from a functional language.
That is to say this is not a Gleam problem, it is a FP problem, if we can even call it a problem (it's mostly just different).
There are two ways to understand your reply, one is that you're talking ORMs that provide query building as an alternative to writing raw SQL. The other is you're talking just about the deserialisation into structures.
If what you meant was the first one then, no I'm not expecting anything like that. I honestly like using a language that gets off of the way and let's me focus on what I want to build. I've done very little OOP and I've written a lot of Rust. There are many situations where I feel like r rusts verbosity is limiting my freedom but the grind of unmarshaling hashmaps into structures is way too much for me. Why shouldn't I want to use my languages typing support to help me write more maintainable code?
I can hardly get over how dart sometimes outright refuses to cast Object types to dynamic types without some syntactical voodoo.
You might be interested in looking at the Squirrel library for Gleam[1]. It kind of reverses the SQL problem in a very nice, elegant way I've found. It gets rid of some of the issues you are bringing up, which are quite valid.
Lisp and elixir, Julia are all fps with macros? Hell even Erlang has macros
I was speaking to the ORM situation, or lack-thereof the parent seemed to be expressing.
Regarding macros - Gleam has stated they are interested in adding metaprogramming, but it's not a huge priority because of the goals of the language.
Macros, and metaprogramming in general have a tendency to complicate a language, and encourages ad-hoc DSL's. One of Gleam's goals is to be dead simple to pick up, read, and contribute - metaprogramming makes that much harder.
Macros are not necessary, even if their absence is a bit of a shock at first. I used to firmly think they were necessary, but now my mind has changed on this for the most part.