Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Gleam Programming Language

gleam.run

Post reply on HN
Print view View original

71–80 of 189 posts

Re: The Gleam Programming Language

#71

Post by wink »

Ndymium wrote: post #38
behnamoh wrote: post #28

I'd rather them stick with ONE: JS or BEAM. Everytime a project claims it can do multiple things at once, it can't do either very well. It's confusing too. Is Gleam suitable for distributed computing like Elixir/Erlang on BEAM? Would that answer change if I compile it to JS?

Gleam is technically as suitable for distributed computing as Erlang: since it compiles to Erlang, it can do anything that Erlang can. You can use Erlang and Elixir libraries and write FFI code to do things that would be unergonomic to do in Gleam. Sure the experience is different and if you want to embrace the guarantees of static typing, then the APIs will look different, like gleam_otp. If you compile it to JS, th…

Same here, I've only been using it for a bit and have 100% been ignoring the JS part and the only time where I felt I needed to think about it for a moment was when I was writing a patch for someone else's code that did not ignore it, so basically when contributing to a library you might have to do extra work.

Of course I can't say if anyone ever made any decisions based on the other target that would have repercussions for me only using the BEAM.

Re: The Gleam Programming Language

#72

Post by lpil »

heliumtera wrote: post #69

One of the best things about erlang/elixir is the repl driven development/manual testing. Gleam has no `interpreted` story, right? Something like clojure, common lisp, etc. I think this matters because debugging on beam is not THAT great, there are tools in erlang/elixir to facilitate debugging, like inspect() or dbg(). If anyone has experience in this language, what is the mindset with gleam? How you guys debug?

You can use all the BEAM debuggers and tracing tools, and Gleam has a print debugging keyword.

Unfortunately there is not yet a plugin for the BEAM debuggers for them to use Gleam syntax.

Re: The Gleam Programming Language

#73

Post by lpil »

pkos98 wrote: post #47
hayleighdotdev wrote: post #43

Earlier quoted context omitted.

> Gleam doesn’t have access to most of the Erlang / Elixir ecosystem out of the box. Gleam has access to the entire ecosystem out of the box, because all languages on the BEAM interoperate with one another. For example, here's a function inside the module for gleam_otp's static supervisor: @external(erlang, "supervisor", "start_link") fn erlang_start_link( module: Atom, args: #(ErlangStartFlags, List(ErlangChildSpec)…

Isn’t this the proof of my point - How does the need of writing „@external“ annotations by hand not contradict the point of being „out of the box“ usable? Hayleigh, when I asked on the discord about how to solve my JSON problem in order to get structured logging working, you replied that I’m the first one to ask about this. Now reading this: > It's ok if you don't vibe with Gleam – no ad-hoc poly and no macros are us…

This is the same as Elixir, you need to specify what Erlang function to use in that language if you want to use Erlang code. The only difference is that Gleam has a more verbose syntax for it.

Re: The Gleam Programming Language

#74

Post by wink »

pjmlp wrote: post #58
misiek08 wrote: post #44

Earlier quoted context omitted.

It’s funny how we avoid the technologies we can’t complain about much. Seeing an Elixir projects on production I always wonder „why we are not using it more often”. More talking about Elixir here. For Elixir I saw a simple distributed job scheduler - it was dead simple in code and was ripped, because it didn’t require maintenance for ~8 years just working without issue and people who knew anything about it left compa…

The way many of us get work assignments is: - Have to deploy product XYZ (because we don't write everything from scratch) - Need to extend said product - Use one of the official SDKs, because we aren't yak shaving for new platforms Thus that is how we end up using the languages we kind of complain about. To be fair, languages like Elixir and Gleam do exist, because too many complain about Erlang, which me with my Pro…

I think the problem is that there is Erlang, the syntax, then Erlang, the features, and then there's OTP. It's a bit much all in one if you might have not done FP before, and then only with C-like syntax languages (e.g. Java).

When I joined an Erlang project I also had some aha moments with the syntax and how stuff is structured, and I found Elixir much nicer to work with (without any real Ruby experience). I don't want to say Erlang is not modern enough, but some things felt like they were around half the work (and more enjoyable) with some Elixir libraries (vastly bigger ecosystem than pure Erlang), for example handling XML.

It might be a bit simplistic, but I don't think you really lose anything meaningful when using Gleam or Elixir over pure Erlang. Just like you don't lose anything when using Clojure or Kotlin over pure Java.

Re: The Gleam Programming Language

#77

Post by lpil »

phplovesong wrote: post #42

Gleam is nice. However it is still very lacking in the stdlib. You will need lots of dependencies to build something usable. I kind of wish Gleam could target something like Go, then you would have the option to go native without a "heavy" VM like the BEAM.

In a world with package management there’s no practical difference between the core modules being in one package or multiple packages.
Post reply on HN