HN user

m8s

520 karma
Posts0
Comments85
View on HN
No posts found.

I’ve been really unhappy with pretty much every Google product I’ve used except their consumer productivity tools — Gmail, Calendar, and Meet. Diving into Google Cloud has been extremely unsatisfactory

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!

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...

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.

I think one of the most important "features" of Gleam is that it intentionally has a small footprint. I agree with your main point here: that Gleam is highly discoverable. You arrive at this conclusion via "reading someone else's code", which I agree with, but I think there's a second important piece regarding discoverability as well: you can read the standard library and be fairly confident that there aren't hidden "better ways" of doing things. I really like Elixir's standard library documentation too, there are numerous examples of how to actually use each function, which is really helpful for beginners.

As an aside, I really love the citations in the third column of your website. Super cool!

Svelte 4 3 years ago

Svelte 4 reduces the Svelte package size by nearly 75% (10.6 MB down to 2.8 MB), which means less waiting on npm install. This improvement will be especially noticeable for users who are loading our interactive learning experience on learn.svelte.dev for the first time, users of the Svelte REPL, and users with limited connectivity. The majority of the remaining package size is eslint support, which necessitates distributing a CJS build, and once the eslint rewrite is completed the Svelte package size can drop by over another 50%.

Wow, that’s a pretty big reduction.

That’s fine, but that’s just your opinion. A lot of people use Elm in production and don’t have issues with it. I’m neutral on Elm. I think it’s a cool language but I don’t use it. I’m not convinced that “constant commits” signal the life of a project though.

There's more to the story in that Elm is a stable, high-quality frontend language that works as well as its creator wants it to for now. There are a lot of happy Elm users over on the Elm Slack, and it's being used in production at various companies.

There's also [Elm on the Backend](https://gotoaarhus.com/2023/sessions/2529/elm-on-the-backend), a recent talk given by the creator of Elm, about his experiments in using Elm as a full-stack language. There are some notes and a few photos, but no video as far as I'm aware.

I'm not involved in the Elm community nor do I write it for a living though, so I'm only kind of aware of what's going on over in the Elm world.

That’s surprising. In what way? I find it to be the most consistent and the most correct out of any chat software I’ve used, including IRC, Slack, Mattermost, and Microsoft Teams. They seem to just get a lot of stuff right.

The only thing that took me some time to adjust to was how overwhelming joining a new server can be. So many channels! Everything needs my attention! But after using it for a long time, I think this is actually a feature. I can mute channels and categories I’m uninterested in, but how many channels on Slack are never found due to poor discoverability?

We run both Slack and Discord at my work and the engineers vastly prefer Discord, for what it’s worth.