The two feel very different. Elixir is introducing gradual set-theoretic typing (https://hexdocs.pm/elixir/1.18.4/gradual-set-theoretic-types...) while Gleam has a static Hindley-Milner style type system.

To me, Gleam feels like if Elm’s type system met Rust’s syntax. I really like it. But I also really liked Elixir too, I just can’t live without Gleam’s type system anymore.

What are the options for GenServer, GenStage, Tasks, Supervisors in gleam?

provided by gleam_otp https://hexdocs.pm/gleam_otp/

It’s a good lesson. We found PMF with a shared google sheet and a bit of data processing behind the scenes. The level of polish I’d come to expect as an engineer at an enterprise company was astronomically higher than what was actually needed for our customers to give us their dollars.

That reminds me, there’s a really great survival game called The Long Dark in which you survive a plane crash in something like the arctic circle and must survive. If anyone is into survival games, definitely check this one out!

It's an extremely captivating game with an unparalleled atmosphere.

Before I started playing the game, I saw in passing an in-game video of a well-stocked gas station. Lights were lit and shelves were stocked. It was made like an in-game advertisement of some sort.

Later, when I started to play the game, I recalled the video, and decided to reach the gas station and set up my base there. Imagine the food! The warm indoor temperatures! Brand new clothes!

After a perilous journey I reached the gas station. For some reason I was expecting the lights to be on and warmth, but of course I was greeted by a half-broken gas station, no lights of course, shelves were almost empty and cold indoors.

But it was a good base, lots of loot.

Was that the Quonset hut surrounded by wolves? I think on the broken highway map?

Yes, Quonset Garage on the Coastal Highway.

It was maybe this video, or a clip of it: https://www.youtube.com/watch?v=gs2IYnNBVhQ

Two quite different things!

Elixir’s use: https://hexdocs.pm/elixir/main/alias-require-and-import.html...

Gleam’s use: https://tour.gleam.run/advanced-features/use/

Erika wrote “Using use in Gleam” in part because I didn’t understand how to use `use`, so I feel at least a little bit qualified to answer this.

I find that `use` is quite effective when needed. This is the part referenced in her article where I find `use` particularly helpful. Something like:

    fn outer() -> Result(success, failure) {
      result.map(parse_id(), fn(id) {
        ... // More code that uses the id
      })
    }

Becomes:

    fn outer() -> Result(success, failure) {
      use id <- result.map(parse_id())
      ... // More code that uses the id
    }

In more concrete terms, I’m building an application with Gleam and Wisp that uses Wisp’s `require_form`. The type signature for `require_form` is:

    pub fn require_form(
      request: Request(Connection),
      next: fn(FormData) -> Response(Body),
    ) -> Response(Body)

But I get to use it like this:

    use form <- wisp.require_form(req)

I’m not sure if I have the appropriate nomenclature here, and I consider myself a beginner of writing strongly typed functional languages, but when I use `use`, I get to invoke the callback with the value on the left side of the arrow.

As Erika so thoughtfully put it:

> The key is to use `use` when it allows you to highlight the happy path of your code … A use expression is syntax sugar, and it’s always possible to write Gleam code without it, though maybe not as clearly.

You can see more here [1] if you want, but note that there are a lot of structural changes in this codebase while I learn and figure out how to best use Gleam and Wisp :)

1. https://github.com/usepriceflow/app/blob/main/src/app/web/ad...

Awesome video, and definitely captures some of the super powers of targeting the BEAM! Thanks for sharing

Congrats to the community, Gleam is a really awesome language! This is such exciting news!

Hands up if you’ve still got ColdFusion powering critical apps in production to this day

Yup. I support a largeish legacy application for a federal government agency running on ColdFusion. The idea of rewriting it in another language is a tough sell as long as it's still supported by Adobe. I'm realistic about its past, present and future but I also still love using it every day.

I was watching all these "I used to CF" replies and wondering if anyone else was going to admit to having running applications. :-)

I still support a few sites and continue to update one large app written in it.

It doesn’t really matter what can be done natively versus in a browser. For many folks, apps are the internet. This take is very developer-centric but it doesn’t account for the real world. Many people prefer using apps, especially middle-age to older demographics. That’s what our analytics say at least.

> For many folks, apps are the internet.

It's a shame a duopoly controls one of the most important functions of modern society. Controls it, taxes it, prevents you from having a direct relationship with your customers ...

Egregious anti-trust.

Agree 100%, which is why I wrote "In these cases it's often a lot easier to just build a Progressive Web App for Android (Google let's you put PWAs directly in the Play Store), and wrap that with a thin native wrapper for iOS."

In other words, these browser-tech-based apps show up in the app stores like any other app.

The experience of said apps just doesn’t hold a candle to RN or native apps. People can tell the difference, for all but your sort of back office type apps you’ll want native views.

Completely disagree. For one, there are tons of native apps that are essentially of these "back office-type" styles. Think banking apps, most airline and hotel membership apps, real estate apps, etc. It's not hard (or I guess not harder than native) to make these apps look great using web technologies.

If you really do need the "slickness" of native apps, I wholeheartedly agree, go native, and use the native frameworks to do so.

The reason I don't like React Native much is that it occupies a "weird middle ground" - if you need the benefits of native, it's usually easier with less headaches to just go native (and big companies have announced ditching React Native due to this reason), but if you want to go cross-platform, there are other technologies that work better IMO.

Sounds like you sort of agree, given you agree with my back office caveat. Sure it's some percent, maybe even a third of apps that could get by with that, but it's far from the majority.

I can point to a ton of RN apps that have incredible UX and surprisingly nice animations/interactivity, with what I'd argue is much easier to work with codebases. Maybe I'm biased, but the Uniswap app is really nicely done with all sorts of native views. They shipped the Android version of their app in just a few months, sharing 95% of the code with iOS.

Maybe it's a cultural thing the in parts of the world where iPhones are common?

I Androidland I mostly see websites pushing user to use apps, and users not using the apps because they're functionally identical to the website except they ceaselessly spam you with irrelevant notifications. Like the google app store feels cheap like a bargain bin, I don't think anyone expects to find anything serious in there.

My perspective, from watching local (German) politics, is that business owners and the heads of government offices are who demand apps. They appear to think that to be hip and up-to-date, you need to have an app. (Possibly because that gives them an avenue to later spam people with notifications, though I would be surprised if they think that far.)

True, but the nice thing is now PWAs can be in the app store and indistinguishable from apps.