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

151–160 of 189 posts

Re: The Gleam Programming Language

#151

Post by yellowapple »

self_awareness wrote: post #141
lpil wrote: post #138

Earlier quoted context omitted.

How you behave in community spaces is 100% related to the project. I agree, that would be very silly. I don't think you can compare not tolerating racists to mandating a particular car colour.

SQLite promotes Christian values but I don't think that they have a problem that a satanist is using their software. It depends on your definition of racism I guess.

I don't think Gleam has a problem if Kenneth Copeland is using their software, either. The problem arises when you mistreat community members in community spaces; I can't speak for DRH, but I'm reasonably sure if someone waltzed into SQLite's forum denigrating the devs and their religious beliefs, there wouldn't be much hesitation in removing that person from said forum.

Re: The Gleam Programming Language

#152

Post by qwertfisch »

__jonas wrote: post #144
qwertfisch wrote: post #135

As with many languages that compile to a VM, I always ask myself: that’s all nice, but how do I interact with anything OUTSIDE of my program? Can I do networking? Can I do system calls to my OS? Display graphics and sound? Can I import a C library that will do all that and call its functions? And if so, how? I just can’t see it from any documentation. Yes, I can call functions from other BEAM-based languages, but the…

If you mean specifically on the BEAM (ignoring JS runtimes), the two options are ports and NIFs, both of which unfortunately have their drawbacks. The Erlang docs on this are here: https://www.erlang.org/doc/system/overview.html

Thank you for the docs and explanation.

Re: The Gleam Programming Language

#153

Post by DrNefario »

tinfoilhatter wrote: post #145
okkdev wrote: post #143

Earlier quoted context omitted.

Unpopular opinion like... being racist?

Ah yes, because not automatically supporting grifts like the BLM movement (which enriched the founders and did very little for the black community at large), makes someone a racist - I totally forgot!

Black Lives Matter is objectively not a grift. There is an argument to be made regarding "BLM Global Network", but calling them BLM is like saying all vegans support PETA.

Regardless, that's irrelevant to the discussion at hand. You don't have to change your beliefs to be part of the Gleam community, you just have to not be an asshole about them. If you're the kind of person that starts an argument any time BLM is mentioned, is it understandable why they wouldn't want you in their community?

Re: The Gleam Programming Language

#154

Post by self_awareness »

yellowapple wrote: post #151
self_awareness wrote: post #141

Earlier quoted context omitted.

SQLite promotes Christian values but I don't think that they have a problem that a satanist is using their software. It depends on your definition of racism I guess.

I don't think Gleam has a problem if Kenneth Copeland is using their software, either. The problem arises when you mistreat community members in community spaces; I can't speak for DRH, but I'm reasonably sure if someone waltzed into SQLite's forum denigrating the devs and their religious beliefs, there wouldn't be much hesitation in removing that person from said forum.

> I don't think Gleam has a problem if Kenneth Copeland is using their software, either.

I wouldn't be so sure. In leftist projects, there are countless of examples why someone is not welcome based on their personal beliefs, and because of this I'm cautiously suspicious about Gleam.

If I'm wrong then the Internet is a better place than I think it is, which would be a good thing. If I'm right, then at least I'll dodge another bullet. Either way I win I guess.

Re: The Gleam Programming Language

#155

Post by self_awareness »

DrNefario wrote: post #153
tinfoilhatter wrote: post #145

Earlier quoted context omitted.

Ah yes, because not automatically supporting grifts like the BLM movement (which enriched the founders and did very little for the black community at large), makes someone a racist - I totally forgot!

Black Lives Matter is objectively not a grift. There is an argument to be made regarding "BLM Global Network", but calling them BLM is like saying all vegans support PETA. Regardless, that's irrelevant to the discussion at hand. You don't have to change your beliefs to be part of the Gleam community, you just have to not be an asshole about them. If you're the kind of person that starts an argument any time BLM is me…

> Black Lives Matter is objectively not a grift.

There we go again. I think that you people would gain if you'd read what does it mean if something is objective and also the meaning of "subjective". Either you live in social bubbles or you're intentionally ignoring anything that's not in line with your ideology. I'm actually not surprised this is the case, since you're not allowing people outside of your bubbles in your community spaces. You cherish diversity, yet in reality you're the most ideologically closed social group that I know. Letting people in only if it's easy for you is very far from "welcoming".

You're accusing the parent of being an asshole, yet you dismiss his arguments based on false "objectivity". And because of your "objectivity", which is clearly subjective, you reinforce the argument that parent is not welcome in your community. How is this welcoming?

I mean I know the answer.

Re: The Gleam Programming Language

#156

Post by worthless-trash »

brandonpollack2 wrote: post #87
worthless-trash wrote: post #5

Earlier quoted context omitted.

I rarely serialise every type in my gleam code, My quick back of the napkin math is less than 5%.

But 100 percent of projects writing the same stuff

I don't think anyone is serializing exactly the same stuff that i'm doing.

Re: The Gleam Programming Language

#157

Post by sureglymop »

packetlost wrote: post #117
smweber wrote: post #111

I’m trying Gleam out right now, and having most recently been writing Go, I’m really loving: - No nil, instead Option and Result - ADTs - Pattern matching + destructuring - Immutable everything by default - `use` syntactic sugar (weird at first, but once you’re used to it it’s pretty elegant) - LSP server works great for such a young language But most of all I think the overall simplicity of the language is really wh…

The use <- syntax is even more crazy when you realize that it's a programmer-friendly way of doing continuation-passing style.

I prefer kotlins trailing lambdas, which do mostly the same. But the way they are written allows code to almost look like JSON/some declarative DSL.

But use is nicer to avoid callback hell and all the indentations/scoping.

Re: The Gleam Programming Language

#158

Post by instig007 »

ngruhn wrote: post #66
pkos98 wrote: post #27

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…

I'm a bit torn on ad-hoc polymorphism. You can definitely do cool things with it. But, as others have pointed out, it does reduce type safety: https://cs-syd.eu/posts/2023-08-25-ad-hoc-polymorphism-erode...

The article provides a contrived example and doesn't prove that ad-hoc polymorphism reduces type-safety. Even when `Maybe [a]` is being folded via `Foldable f` the claimed type-safety isn't reduced, it's the context of the folding that's being changed from `[a]` to `Maybe a`, and everything is type-safe. Secondly, if you really want to distinguish between the empty list and disabled allow-lists within your type-system you do define your own data type with that representation, and you don't declare it foldable, because the folding algebra doesn't make sense for any practical use-case of the disabled allow-lists. The language actually provides you with the means to reduce evaluation contexts your types can be part of.

Re: The Gleam Programming Language

#159

Post by instig007 »

tombert wrote: post #24
the-grump wrote: post #20

Earlier quoted context omitted.

You missed the entire point of the strong static typing.

I don’t think I did. I am one of the very few people who have had paying jobs doing Scala, Haskell, and F#. I have also had paying jobs doing Clojure and Erlang: dynamic languages commonly used for distributed apps. I like HM type systems a lot. I’ve given talks on type systems, I was working on trying to extend type systems to deal with these particular problems in grad school. This isn’t meant to a statements on ty…

You're conflating types with the encoding/decoding problem. Maybe your paying jobs didn't provide you with enough room to distinguish between these two problems. Types can be encoded optimally with a minimally-required bits representation (for instance: https://hackage.haskell.org/package/flat), or they can be encoded redundantly with all default/recovery/omission information, and what you actually do with that encoding on the wire in a distributed system with or without versioning is up to you and it doesn't depend on the specific type system of your language, but the strong type system offers you unmatched precision both at program boundaries where encoding happens, and in business logic. Once you've got that `Maybe a` you can () in exactly one place at the program's boundary, and then proceed as if your data has always been provided without omission. And then you can combine () with `Alternative f` to deal with your distributed systems' silly payloads in a versioned manner. What's your dynamic language's null-checking equivalent for it?

Re: The Gleam Programming Language

#160

Post by instig007 »

tombert wrote: post #130
folex wrote: post #49

Earlier quoted context omitted.

> ends up being the same checks you would be doing with a dynamic language Sure thing. Unless dev forgets to do (some of) these checks, or some code downstream changes and upstream checks become gibberish or insufficient.

I know everyone says that this is a huge issue, and I am sure you can point to an example, but I haven’t found that types prevented a lot of issues like this any better than something like Erlang’s assertion-based system.

When you say "any better than" are you referring to the runtive vs comptime difference?
Post reply on HN