[HN Gopher] Gleam v1.9
___________________________________________________________________
Gleam v1.9
Author : lpil
Score : 191 points
Date : 2025-03-09 11:06 UTC (10 hours ago)
(HTM) web link (gleam.run)
(TXT) w3m dump (gleam.run)
| trescenzi wrote:
| As always Gleam's lsp actions show just how much useful code
| generation can be done without the need for any gen ai so long as
| you have strong types. I continue to be amazed just how much the
| community cares about the developer experience of the language.
| giacomocava wrote:
| The language server has been improving at such a fast pace it's
| hard to keep up! Soon I'll be out of code actions to implement
| trescenzi wrote:
| Thank you for all your work on the language!
| SSLy wrote:
| Time to move to the Extend phase :^]
| giacomocava wrote:
| All the pain to get echo working was 100% worth it! What a great
| release
| spinningslate wrote:
| As a dyed-in-the-wool print debugging advocate, and a Gleam-
| curious Erlang/BEAM enthusiast, this is very interesting for
| me.
|
| Thanks for all your work, great to see how well the language
| and tooling are maturing.
| giacomocava wrote:
| print debugging is the best debugging <3 Thank you for the
| kind comment!!
| IshKebab wrote:
| Nah it's just the easiest and most reliable way. Usually
| anyway; sometimes you have extreme timing or space
| constraints and can't even use that. On microcontrollers I
| sometimes have to resort to GPIO debug outputs and I've
| worked on USB audio drivers where printf isn't an option.
| hayleighdotdev wrote:
| hello fellow print debugging enjoyer, rejoice!
| cardanome wrote:
| Thinking back on how Python 3 broke nearly all existing Python
| beginner code because they made print a function instead of a
| statement feels ironic now.
|
| Sure print being a function has slight benefits in certain
| cases but the Gleam team also makes very compelling arguments
| to implement echo as a special keyword.
|
| So what do we learn from that? Maybe don't do breaking changes
| to your language. Maybe debugging and actually printing should
| be separate things, one a statement, the other a function? I
| don't know.
| eyelidlessness wrote:
| I don't know enough about Gleam's implementation to say how
| applicable this is, but from a more general language design
| perspective... a keyword isn't inherently imbued with special
| capabilities that a function call wouldn't be. They're
| semantically interchangeable for this use case, _if the
| function can access requisite information about the
| underlying stack_.
|
| I'm not sure it's possible to extrapolate any lessons for
| Python from this Gleam language feature or the chosen syntax.
| tmountain wrote:
| Feels like Gleam is gaining a lot of steam and getting a lot of
| attention recently. It's the language that I am most excited
| about right now. It's hitting all the right notes.
| ThinkBeat wrote:
| I do not quite understand that it runs on BEAM and Javascript
| with runtime.
|
| Most of the great things I like about Elixir is tied to feature
| native to BEAM. (I think).
|
| And I would expect that BEAM has not been ported to a Javascript
| runtime?
|
| I would also expect at Gleam for Javascript can use and interact
| with Javascript libraries and what not, not possible under the
| regular version.
|
| I would also expect that it is possible to write useful code that
| mill work on both platforms. but with a lot of limitations.
|
| Do I have this completely wrong?
| FireInsight wrote:
| It's useful because you can write back-end and front-end code
| with the same language. Code sharing should work, as long as
| you don't use runtime-specific features blindly. All basic
| language features seem to work the same regardless of runtime.
| Hasnep wrote:
| Most Gleam code is backend agnostic, but code that does
| something BEAM specific like OTP or Erlang FFI is only
| available when targeting the BEAM and JS ffi is only available
| when targeting JS. You can also provide two implementations of
| a function, one for each backend if you want to target both.
| lpil wrote:
| Yup that's right, you can't use Erlang code on JS runtimes or
| JS code on Erlang runtimes. Most library code doesn't use
| either, so it's usable on both.
|
| Elixir is also quite a lovely language even when not using any
| BEAM specific functionality! I used it a lot for writing
| regular sequential programs.
| pjmlp wrote:
| Yeah this is one of the typical mistakes of guest languages,
| they start by offering something that the platform language is
| missing out on, and eventual in the pursue for greater
| mindstart try to expand elsewhere, however by doing so, they
| lose the capabilities that made the original target platform
| special, and eventually become their own thing, if they survive
| beyond the typical adoption curve.
| eyelidlessness wrote:
| I think it might help to start with a baseline assumption:
| newer high-ish level languages (or any such language looking to
| expand mindshare) will inevitably be asked "[how] can I run
| code written in this language in a browser?"
| victorbjorklund wrote:
| The benefit is you can write JS by writing the same language as
| the rest of your app. I wish I could do that with Elixir. Not
| run the app on a javascript runtime but write frontend code
| that will transpile to JS.
| ivanjermakov wrote:
| What is the point of making echo a special syntax and not just a
| function? And add another function to retrieve stack info.
| gdotdesign wrote:
| The compiler can inject information at compile time so no
| runtime reflection is necessary.
| wavemode wrote:
| Well, there's nothing stopping the language from having
| builtin functions and constants in the standard library that
| are handled specially by the compiler, the same way this echo
| keyword is. That would've had the added benefit of being
| backwards compatible (which new keywords are not).
| _danielle_ wrote:
| Gleam reserved a handful of keywords in 1.0 (including
| echo), so it isn't a new keyword.
| keeganpoppen wrote:
| that is basically just a keyword with extra steps...
| ivanjermakov wrote:
| Call site can be inlined in compile time, without special
| syntax. Full stack trace would require runtime support
| anyway.
| akudha wrote:
| As Elixir is getting its own type system, should one still pick
| Gleam over Elixir?
| hayleighdotdev wrote:
| They're kind of solving different problems. It's a bit like
| TypeScript vs Elm or PureScript: one is a type system overlaid
| onto an existing language with its own rich ecosystem and set
| of idioms, and the other is a new language that targets the
| same underlying platform but has different idioms and semantics
| for static analysis.
|
| If you already have lots of Elixir in production, or you enjoy
| Elixir's highly dynamic approach to solving problems and would
| like to get some additional safety for free then sticking with
| Elixir is a no-brainer!
|
| If you'd like a simpler language with tighter static analysis
| guarantees while still being able to dip into the wider
| ecosystem then you might prefer Gleam.
|
| Ultimately I think the two languages have very different
| philosophies and idioms, folks will naturally find themselves
| preferring one or the other ^.^
| bmitc wrote:
| I find it unfortunate. The BEAM is so influential as a VM, that
| most languages on top of it will be very similar. I don't
| really like the situation where we have Erlang, Elixir, and
| Gleam all atop the same VM, and they're all basically the same
| language. It's a split that isn't needed.
| juped wrote:
| Gleam is nothing like Erlang or Elixir (its copying of Rust
| is so slavish it even has a toml file driven build system)
| and Erlang and Elixir are not split (the only place where
| they even sorta are is rebar vs. mix).
|
| I don't particularly want to gatekeep "Rust fans who just
| want to write lots of Rust" off OTP. Let them have Gleam.
| Maybe they'll figure out how to lifetime-annotate binaries?
| tomtheelder wrote:
| Gleam and Rust are really not alike at all aside from the
| most superficial ways. A couple bits of syntax, and the use
| of toml are about all I can come up with.
| sodapopcan wrote:
| I'm not fully qualified but in a nutshell, Gleam doesn't
| support OTP out of the box. There is a separate package for it
| [0] but it doesn't offer everything, so it depends on your
| needs. If you're going to be doing heavy OTP stuff you'll need
| to stick with Elixir. If you want to transpile to JS, then
| Gleam is the better choice. Otherwise it's up to your tastes
| around type systems and syntax.
|
| [0] https://github.com/gleam-lang/otp
| maleldil wrote:
| Gleam looks like a really nice language that I haven't had a
| place to use yet. Does anyone have experience using it as a
| replacement/alternative for TypeScript for (e.g.) CLI tools?
| shepherdjerred wrote:
| What's a good way to learn Gleam? In college I would learn new
| languages/libraries/concepts through projects, but these days I
| have too many projects already.
|
| I don't expect I'll ever use Gleam at work, but the language does
| look very appealing to me and fun to use.
| mkcny wrote:
| Gleam's interactive tour is a great place to start:
| https://tour.gleam.run/
|
| There's also an Exercism track that has exercises contributed
| by Gleam's creator: https://exercism.org/tracks/gleam
| fn-mote wrote:
| I tried to find out why I would try gleam, what I would use it
| for.
|
| What I found convinced me it wasn't for me.
|
| 1. Language behavior depends on the back end. Int doesn't
| necessarily mean Int.
|
| > When running on the Erlang virtual machine ints have no maximum
| and minimum size. When running on JavaScript runtimes ints are
| represented using JavaScript's 64 bit floating point numbers.
|
| 2. If it's not an Int it's a Float. Short numeric tower. I guess
| that's ok. No BigInt with a guarantee it will not overflow? No
| exact Rational?
|
| 3. Type annotations [are optional and] "don't change how the
| program runs".
|
| Ok this sounds like Python. Supposedly there are guarantees
| indicating "if it compiles it runs" but I'm worried. How do you
| even know the inferred type of your function is what you really
| think it should be? (I'm familiar with inference gone crazy from
| Haskell.)
| roetlich wrote:
| > How do you even know the inferred type of your function is
| what you really think it should be?
|
| By adding a type annotation? Am I missing something?
| lpil wrote:
| It's not anything like Python. The language that it is most
| like is probably F# or OCaml.
|
| Python's type checkers are optional. They only verify code with
| annotations.
|
| Gleam's type checker is mandatory, so it is impossible to
| compile code without type checking being performed. Type
| inference and checking are always fully performed, and adding
| type annotations doesn't make the compiler perform any extra
| checking.
|
| > How do you even know the inferred type of your function is
| what you really think it should be? (I'm familiar with
| inference gone crazy from Haskell.)
|
| Gleam doesn't have subtyping so this is typically trivial, but
| idiomatic code has all functions annotated for clarity. You can
| also hover in your editor, or read the documentation Gleam
| generates and publishes from code automatically.
___________________________________________________________________
(page generated 2025-03-09 22:01 UTC)