lpil

7 ms·

91.
by lpil 2y ago
> Wouldn't hurt anything, would it? One of Gleam's design goals is to not have multiple ways to do the same thing, so having to pick between using method chains or pipelines would work against that. > having to import librar
92.
by lpil 2y ago
It's the namespace that belongs to the core team. It couldn't be just `string` etc as that would collide with existing Erlang modules. Other Gleam libraries will use other namespaces.
93.
by lpil 2y ago
What would you say makes it much worse?
94.
by lpil 2y ago
In the early days of Elixir what you are proposing here was popular[1], but over time the community largely decided it wasn't beneficial and I rarely see it any more. [1]: https://github.com/sasa1977/exactor
95.
by lpil 2y ago
Contributions are very much welcome! Gleam is entirely a community project.
96.
by lpil 2y ago
If you error from Erlang or Elixir you will get the error as those languages construct them, even if you call that code from Gleam. The Gleam build tool attempts to print them more nicely than Erlang does by default, but it cannot add addit
97.
by lpil 2y ago
Most of the work for this has been done, the main missing piece is surfacing it in the UI, which someone will hopefully pick up soon.
98.
by lpil 2y ago
It is referenced in multiple places on the main site. The home page has a code snippet from it, though it does not go into any detail about any specific library.
99.
by lpil 2y ago
Gleam does not sacrifice OTP compatibility for type safety. It picks both.
100.
by lpil 2y ago
It uses the same primitives as Erlang, the difference is that it exposes type safe APIs instead of untyped ones which you would get from using the Erlang abstractions. It implements the same protocols and does not have any interop shortcomi
101.
by lpil 2y ago
It is production ready and has been used for numerous non-trivial projects. Experimental in this context means there is expected to be API changes and feature additions in future.
102.
by lpil 2y ago
It is not abandoned, I am the maintainer. The documentation covers the APIs of the package but not the “zen” of the wider OTP framework, for that the official OTP documentation and existing books are recommended.
103.
by lpil 2y ago
Hello! I’m the maintainer of the Gleam OTP library. It is not abandoned or an afterthought.
104.
by lpil 2y ago
I'm sorry but I don't think you're right here, I've not detected any increase in any Gleam growth metrics when Elixir type related things happen. If anything we see Elixir have a bump when big things happen in the Gleam
105.
by lpil 2y ago
I've been an Elm user since 2016, wrote my start up in Elm, and frequently collaborate with notable members of the Elm community. Gleam's approach to community and maintainership has almost nothing in common with Elm's, and d
106.
by lpil 2y ago
Thank you!
107.
by lpil 2y ago
I think you're misunderstanding here. We have very robust mechanisms for dealing with conflict and we have been successfully employing them for years. We have also consulted with moderators of much larger communities and very confident
108.
by lpil 2y ago
> but know that you're severely limiting the growth of your community and excluding people who could really contribute. Quite the opposite. By not having the usual sources of annoyance and tedium Gleam's community has grown muc
109.
by lpil 2y ago
We go quite a bit further than keeping out hate speech. For example, we have a policy of "good vibes" in the chat so we don't permit bashing other languages and will publicly ask folks to take it elsewhere if they start. It&#
110.
by lpil 2y ago
I'm glad you think I'm young! We take moderation very seriously in Gleam, and I assure you this poster has omitted much of the context here. If you have any concerns please do get in touch with the moderation team either on discor
111.
by lpil 2y ago
They're both functional and on the same runtime, but they're very different languages. I think the best way to understand the different experiences they offer is to try them both.
112.
by lpil 2y ago
I thought would be the case too originally, but now that Gleam has been known long enough to get an idea for the sort of people who are attracted to it I don't see Elixir getting types having any real impact on Gleam's uptake. Eli
113.
by lpil 2y ago
It doesn’t have multiple purposes, it has one: to enable the use of higher order functions without increasing indentation.
114.
by lpil 2y ago
Hi, I’m the lead developer of Gleam. I don’t think that Elixir’s types and Gleam’s have much in common, they will provide very different experience. Coupled with there not being much crossover from the Elixir community to the Gleam one I do
115.
by lpil 2y ago
I used xwax for many years and was always delighted by it. A fantastic bit of software!
116.
by lpil 2y ago
I'm sorry, I don't understand what point you're trying to make here, it seems unrelated to Gleam.
117.
by lpil 2y ago
Gleam doesn't have subtyping, so this drawback is impossible. Its type system is similar to OCaml, Elm, F#, etc.
118.
by lpil 2y ago
Gleam doesn't have subtyping, so the drawback described here is not possible.
119.
by lpil 2y ago
I think you may be thinking of some other language. Gleam adds no overhead to the target platform used and both the Erlang VM and JavaScript runtimes have respectable performance. The Erlang VM specifically outcompetes F# for networked serv
120.
by lpil 2y ago
I think if I were making Gleam again from scratch it'd be required, them being optional was somewhat inherited as Gleam is an ML family language. Luckily Gleam programmers do write return annotations in practice.

More ›