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

11–20 of 189 posts

Re: The Gleam Programming Language

#11

Post by tombert »

sfvisser wrote: post #9
tombert wrote: post #8

I remember playing with Alpaca a few years ago, and it was fun though I didn’t find the resulting code to significantly less error-prone than when I wrote regular Erlang. It’s inelegant, but I find that Erlang’s quasi-runtime-typing with pattern matching gets you pretty far and it falls into Erlang’s “let it crash” philosophy nicely. Honestly, and I realize that this might get me a bit of flack here and that’s obviou…

I don’t understand this comment, yes everything going over the wire is bits, but both endpoints need to know how to interpret this data, right? Types are a great tool to do this. They can even drive the exact wire protocol, verification of both data and protocol version. So it’s hard to see how types get in the way instead of being the ultimate toolset for shaping distributed communication protocols.

Bits get lost, if you don’t have protocol verification you get mismatched types.

Types naively used can fall apart pretty easily. Suppose you have some data being sent in three chunks. Suppose you get chunk 1 and chunk 3 but chunk 2 arrives corrupted for whatever reason. What do you do? Do you reject the entire object since it doesn’t conform to the type spec? Maybe you do, maybe you don’t, or maybe you structure the type around it to handle that.

But let’s dissect that last suggestion; suppose I do modify the type to encode that. Suddenly pretty much every field more or less just because Maybe/Optional. Once everything is Optional, you don’t really have a “type” anymore, you have a a runtime check of the type everywhere. This isn’t radically different than regular dynamic typing.

There are more elaborate type systems that do encode these things better like session types, and I should clarify that I don’t think that those get in the way. I just think that stuff like the C type system or HM type systems stop being useful, because these type systems don’t have the best way to encode the non-determinism of distributed stuff.

You can of course ameliorate this somewhat with higher level protocols like HTTP, and once you get to that level types do map pretty well and you should use them. I just have mixed feelings for low-level network stuff.

Re: The Gleam Programming Language

#12

Post by lxdlam »

I still suspect the effectiveness of plugging in a type system patch to a complete system, like typescript to javascript. We still observe so many `as any` or `as unknown as` at every corner.

Despite of the suspicion, Gleam provides a better and elegant syntax for those who are not familiar with Erlang or functional programming languages, which I loved most.

Re: The Gleam Programming Language

#13

Post by tombert »

jakelazaroff wrote: post #10
tombert wrote: post #8

I remember playing with Alpaca a few years ago, and it was fun though I didn’t find the resulting code to significantly less error-prone than when I wrote regular Erlang. It’s inelegant, but I find that Erlang’s quasi-runtime-typing with pattern matching gets you pretty far and it falls into Erlang’s “let it crash” philosophy nicely. Honestly, and I realize that this might get me a bit of flack here and that’s obviou…

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 field is corrupted, do you reject everything? Sometimes, but often Probably not, network calls are too expensive, so you encode that into the type with a Maybe. But of course any field could be corrupt so you have to encode lots of fields as Maybes. Suddenly you have reinvented dynamic typing but it’s LARPing as a static type system.

Re: The Gleam Programming Language

#14

Post by jakelazaroff »

tombert wrote: post #13
jakelazaroff wrote: post #10

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…

I think you can avoid most issues by not doing what you're describing! Ensuring data arrives uncorrupted is usually not an application-level concern, and if you use something like TCP you get that functionality for free.

Re: The Gleam Programming Language

#15

Post by eyelidlessness »

tombert wrote: post #11
sfvisser wrote: post #9

Earlier quoted context omitted.

I don’t understand this comment, yes everything going over the wire is bits, but both endpoints need to know how to interpret this data, right? Types are a great tool to do this. They can even drive the exact wire protocol, verification of both data and protocol version. So it’s hard to see how types get in the way instead of being the ultimate toolset for shaping distributed communication protocols.

Bits get lost, if you don’t have protocol verification you get mismatched types. Types naively used can fall apart pretty easily. Suppose you have some data being sent in three chunks. Suppose you get chunk 1 and chunk 3 but chunk 2 arrives corrupted for whatever reason. What do you do? Do you reject the entire object since it doesn’t conform to the type spec? Maybe you do, maybe you don’t, or maybe you structure the…

> But let’s dissect that last suggestion; suppose I do modify the type to encode that. Suddenly pretty much every field more or less just because Maybe/Optional. Once everything is Optional, you don’t really have a “type” anymore, you have a a runtime check of the type everywhere. This isn’t radically different than regular dynamic typing.

Of course it’s different. You have a type that accurately reflects your domain/data model. Doing that helps to ensure you know to implement the necessary runtime checks, correctly. It can also help you avoid implementing a lot of superfluous runtime checks for conditions you don’t expect to handle (and to treat those conditions as invariant violations instead).

Re: The Gleam Programming Language

#16

Post by giacomocava »

lxdlam wrote: post #12

I still suspect the effectiveness of plugging in a type system patch to a complete system, like typescript to javascript. We still observe so many `as any` or `as unknown as` at every corner. Despite of the suspicion, Gleam provides a better and elegant syntax for those who are not familiar with Erlang or functional programming languages, which I loved most.

There’s no “unknown” or “any” in Gleam, it’s not possible to cheat the type system that way

Re: The Gleam Programming Language

#17

Post by tombert »

eyelidlessness wrote: post #15
tombert wrote: post #11

Earlier quoted context omitted.

Bits get lost, if you don’t have protocol verification you get mismatched types. Types naively used can fall apart pretty easily. Suppose you have some data being sent in three chunks. Suppose you get chunk 1 and chunk 3 but chunk 2 arrives corrupted for whatever reason. What do you do? Do you reject the entire object since it doesn’t conform to the type spec? Maybe you do, maybe you don’t, or maybe you structure the…

> But let’s dissect that last suggestion; suppose I do modify the type to encode that. Suddenly pretty much every field more or less just because Maybe/Optional. Once everything is Optional, you don’t really have a “type” anymore, you have a a runtime check of the type everywhere. This isn’t radically different than regular dynamic typing. Of course it’s different. You have a type that accurately reflects your domain…

No, it really isn’t that different. If I had a dynamic type system I would have to null check everything. If I have declare everything as a Maybe, I would have to null check everything.

For things that are invariants, that’s also trivial to check against with `if(!isValid(obj)) throw Error`.

Re: The Gleam Programming Language

#18

Post by tombert »

jakelazaroff wrote: post #14
tombert wrote: post #13

Earlier quoted context omitted.

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…

I think you can avoid most issues by not doing what you're describing! Ensuring data arrives uncorrupted is usually not an application-level concern, and if you use something like TCP you get that functionality for free.

TCP helps but only to a certain extent; it only guarantees specific ordering of bits during its session. Suppose you have to construct an object out of three separate transmissions, like some kind of multipart style thing. If one of the transmissions gets corrupted or gets errors out from TCP, then you still fall into that maybe trap.

Re: The Gleam Programming Language

#19

Post by obsoleetorr »

tombert wrote: post #18
jakelazaroff wrote: post #14

Earlier quoted context omitted.

I think you can avoid most issues by not doing what you're describing! Ensuring data arrives uncorrupted is usually not an application-level concern, and if you use something like TCP you get that functionality for free.

TCP helps but only to a certain extent; it only guarantees specific ordering of bits during its session. Suppose you have to construct an object out of three separate transmissions, like some kind of multipart style thing. If one of the transmissions gets corrupted or gets errors out from TCP, then you still fall into that maybe trap.

so you need transactions?

I get what your saying, but can't you have the same issue if instead you have 3 local threads that you need to get the objects from, one can throw an exception and you only receive 2, same problem

Re: The Gleam Programming Language

#20

Post by the-grump »

tombert wrote: post #17
eyelidlessness wrote: post #15

Earlier quoted context omitted.

> But let’s dissect that last suggestion; suppose I do modify the type to encode that. Suddenly pretty much every field more or less just because Maybe/Optional. Once everything is Optional, you don’t really have a “type” anymore, you have a a runtime check of the type everywhere. This isn’t radically different than regular dynamic typing. Of course it’s different. You have a type that accurately reflects your domain…

No, it really isn’t that different. If I had a dynamic type system I would have to null check everything. If I have declare everything as a Maybe, I would have to null check everything. For things that are invariants, that’s also trivial to check against with `if(!isValid(obj)) throw Error`.

You missed the entire point of the strong static typing.
Post reply on HN