61–70 of 189 posts
thought I’d try the showcase example in Raku ( https://raku.org ), so this Gleam import gleam/io pub fn main() { io.println("hello, friend!") } becomes this Raku say “hello, friend!” well maybe you really want to have a main() so you can pass in name from the command line #!/usr/bin/env raku sub MAIN($name) { say "hello, $name!” }
Earlier quoted context omitted.
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…
How does it contradict it? Without any modification/installation you can interop with Erlang/Javascript. How is that not out of the box usability of the Erlang/JS ecosystem? Syntax isn't as seamless as Elixir, but we need a way to tell Gleam what types are being passed around. Why do you feel like a gatekeeper? Your opinion is valid, it's just that the interop statement was wrong.
Earlier quoted context omitted.
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…
How does it contradict it? Without any modification/installation you can interop with Erlang/Javascript. How is that not out of the box usability of the Erlang/JS ecosystem? Syntax isn't as seamless as Elixir, but we need a way to tell Gleam what types are being passed around. Why do you feel like a gatekeeper? Your opinion is valid, it's just that the interop statement was wrong.
It would be different if I didn't have to write bindings and Gleam integrated automatically with foreign APIs. For Erlang that's probably not possible, but for the Javascript ecosystem it could make use of Typescript signatures maybe. (it would be very hard though)
I'm now working on a real world legacy Elixir project in my day job and man oh man do I miss well defined types. Coming from Go, it makes a huge difference to my productivity when I'm able to click through fields and find usages of things, which comes down to the excellence of the Go language server. I know that the Elixir language server can infer some of this, but the language server in my experience is very fickle…
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.
Coming from Elixir, I gave Gleam a try for a couple of days over the holidays. Reasons I decided not to pursue: - No ad-hoc polymorphism (apart from function overloading IIRC) means no standard way of defining how things work. There are not many conventions yet in place so you won’t know if your library supports eg JSON deserialization for its types - Coupled with a lack of macros, this means you have to implement ev…
https://cs-syd.eu/posts/2023-08-25-ad-hoc-polymorphism-erode...
Earlier quoted context omitted.
Interesting! I don't share that view at all — I mean, everything running locally is just bits too, right? Your CPU doesn't care about monads or integers or characters or strings or functors either. But ultimately your higher level code does expect data to conform to some invariants, whether you explicitly model them or not. IMO the right approach is just to parse everything into a known type at the point of ingress,…
I know everything reduces to bits eventually, but modern CPUs and memory aren’t as “lossy” as the network is, meaning you can make more assumptions about the data being and staying intact (especially if you have ECC). Once you add distribution you have to encode for the fact that the network is terrible. You absolutely can parse at ingress, but then there are issues with that. If the data you got is 3/4 good, but one…
What the hell is really the alternative here? Do you just pretend your process can accept any kind of data, and just never do anything with it??
If you need an integer and you get a string, you just don't work. This has nothing to do with types. There's no solution here, it's just no thank you, error, panic, 500.
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 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?
One of programming languages with political agenda.