#Gleam 1.1.0 errors with standard library on MacOS

1 messages · Page 1 of 1 (latest)

subtle flicker
#

I'm running into a strange issue with Gleam hello world program on MacOS. I simply created the program using gleam new and every build returns the following error:

24 │ import gleam/dynamic.{Dynamic}
   │                       ^^^^^^^ Did you mean `dynamic`?

The module `gleam/dynamic` does not have a `Dynamic` value.

Does anyone have any idea what causes this or has anyone faced something similar?

empty rock
#

import gleam/dynamic.{type Dynamic}

#

Dynamic is the name of a type

subtle flicker
#

My code is very straight forward:

import gleam/io

pub fn main() {
  io.println("Hello from first_test!")
}
empty rock
#

what version of the standard library do you have in your manifest?

#

or your gleam.toml but the manifest is more important

subtle flicker
#

Ah, I see. It's 0.29.

empty rock
#

super old

#

not sure how you ended up with one that old

subtle flicker
#

Had it installed using Nix version 23.11. Just updated nixpkgs to 24.05.

empty rock
#

if you do gleam deps update it should update

#

👍

#

its always nix 😂

subtle flicker
#

lol.. nix is pretty nice when you know the technology. I'm just starting with gleam today for the first time. Looking forward to learning more about the ecosystem! 🙂

white wagon
#

I wonder if we can make the “it’s always nix” comment better in some way. I literally asked a similar question yesterday which also was related to an old version of gleam from nix cat_think

#

(I say this as someone helping to maintain these nix packages fwiw)

grim juniper
#

this really has nothing to do with nix specifically

#

it's the same as e.g. using Ubuntu 22.10

#

you'll get old packages

white wagon
#

Yeah.

subtle flicker
#

The reason I ran into this is not the NIx itself but the fact that Gleam asks you to specify the standard library in the package manager manifest unlike various other languages where standard library is just the runtime itself.
I'm not saying that it's a bad thing for Gleam, just not something that somebody like me coming from another language (I'm coming from Rust, etc.) would identify immidiately.
I did notice that my Gleam version was super old, which is why I updated my nixpkgs, but didn't realise that I would have to increment the stanard library version as well.

unique forge
subtle flicker
#

I was surprised that the newer gleam compiler didn't just execute the older standard library code.
Although, I'm guessing this is a pre 1.0 issue and now we're on a stable version the semantic version more or less should make it obvious when the change is breaking.

white wagon
unique forge
#

The stdlib v0.29 is from over a year ago, way before gleam itself was v1.0

#

How do these package managers end up giving you versions of things that are so old

empty rock
#

i think someone added gleam to stable, but only unstable is up to date

#

its not really anything to do with us we dont maintain these

unique forge
#

Yeesh

white wagon
#

I’ll check when I get back to my desk if unstable is actually on the most recent gleam (and update if it isn’t)

subtle flicker
subtle flicker
subtle flicker
white wagon
#

Unstable has 1.2.1 as of 19 hours ago. I just checked.

grim juniper
#

if i understood correctly, they were using an older stdlib version in manifest.toml

#

however the fact that they got to there in the first place could be because they were using an older gleam version which isnt compatible with newer stdlib, as mentioned

#

nixpkgs 23.11 has 1.1.0 though so it's fairly up-to-date

quaint tundra
unique forge
#

do we have an issue for this yet? is there even enough info here to make an issue