5 ms·

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 h

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.

rtorr 2y ago
Also prevents lock-in if you ever need to move away from gleam.
pan69 2y ago
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.
- Alupis 2y ago
  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.
  - giraffe_lady 2y ago
    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.
    - oDot 2y ago
      Very much so! I've created Vleam[0] to convert an existing vue webapp[1] and so far it's a joy. [0]: https://github.com/vleam/vleam https://github.com/vleam/vleam [1]: https://blog.nestful.app/p/why-i-rewrote-nestful-in-gleam https://blog.nestful.app/p/why-i-rewrote-nestful-in-gleam
cedws 2y ago
Another layer of abstraction, another thing to go wrong, another thing to rot.
- deleted 2y ago
  [deleted]
- Ndymium 2y ago
  But, you need a runtime. If Gleam had its own runtime, that would be another layer in a similar vein. Here Gleam is using Erlang (or a JS runtime) which is bound to be more supported and have a longer lifetime than something they cooked up themselves. Besides, Gleam's original aim was basically "Erlang but static types", so the choice of Erlang as runtime was always there.

rtorr 2y ago

Also prevents lock-in if you ever need to move away from gleam.

pan69 2y ago

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.

Alupis 2y ago
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.
- giraffe_lady 2y ago
  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.
  - oDot 2y ago
    Very much so! I've created Vleam[0] to convert an existing vue webapp[1] and so far it's a joy. [0]: https://github.com/vleam/vleam https://github.com/vleam/vleam [1]: https://blog.nestful.app/p/why-i-rewrote-nestful-in-gleam https://blog.nestful.app/p/why-i-rewrote-nestful-in-gleam

cedws 2y ago

Another layer of abstraction, another thing to go wrong, another thing to rot.

deleted 2y ago
[deleted]
Ndymium 2y ago
But, you need a runtime. If Gleam had its own runtime, that would be another layer in a similar vein. Here Gleam is using Erlang (or a JS runtime) which is bound to be more supported and have a longer lifetime than something they cooked up themselves. Besides, Gleam's original aim was basically "Erlang but static types", so the choice of Erlang as runtime was always there.