Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elixir v1.20: Now a gradually typed language

elixir-lang.org

Post reply on HN
Print view View original

351–360 of 426 posts

Re: Elixir v1.20: Now a gradually typed language

#351

Post by sodapopcan »

chamomeal wrote: post #297
sodapopcan wrote: post #160

Earlier quoted context omitted.

I keep getting baited by these comments so this is the last one I'll respond to, lol. Elixir is always been sort of a "typed dynamic language" due to how baked in pattern matching is. Any good Elixir developer has always been thinking about types anyway, it's almost impossible not to.

That’s a good point! And I suppose you don’t have willy-nilly reassignment of properties like you do in ruby/php/js.

Also, as I kept forgetting to mention, there are no overloaded operators (`+` only works on numbers, for example... unfortunately it does work on both ints and floats but that's another story). The one pain point is that comparriason operators works across all types, but the compiler has already been warning against doing that for at least a year now.

Re: Elixir v1.20: Now a gradually typed language

#353

Post by neya »

nesarkvechnep wrote: post #325
neya wrote: post #307

Earlier quoted context omitted.

This was the only out of box solution when Elixir didn't support types. So, if you really did Elixir professionally for 6 years, you'd know that by now. > Bad APIs, bad UIs because someone coupled themselves to the database structure and can't escape. If you don't commit yourself to the database structures you defined at the time of application creation, then it just reflects poor planning and architecture overall as…

The disagreement is on Ecto schemas used to represent databases tables from the persistence layer to the UI. Of course, use changesets to normalise user input but using the same schemas everywhere is a sign of immaturity as a developer. You really sound like someone who only does CRUD services. Real world is often more complex.

> Real world is often more complex.

Which is why you architect before-hand with a paradigm of your choice, like DDD (Domain Driven Design) using proper contexts (which Phoenix supports) beforehand. That is the sign of a mature developer, not the other way around.

If your datatype for a column evolves over time to completely different types, it's just an excuse for poor planning and architecture. Eg. A string turning into an integer. That just sounds like someone junior would do with MongoDb.

> You really sound like someone who only does CRUD services.

You throw this like an insult, but in reality most applications can be simplified to just CRUD services. Chat interfaces? CRUD. Social Media? CRUD. Banking? CRUD.

Re: Elixir v1.20: Now a gradually typed language

#354

Post by waffletower »

kensai wrote: post #174
replwoacause wrote: post #169

Earlier quoted context omitted.

I've used untyped languages extensively, and even built my own, and the errors I get at runtime are almost never type-based, and that's even more true now that LLMs can pump out code. For all the additional ceremony types add, I can't say I've personally realized their benefit.

This reminds me of the analogy of the smoking grandpa. I had a grandpa that was chainsmoking his whole life and managed to reach 90 and died of other causes. This does not mean smoking is "relatively safe".

This analogy is absolutely absurd and inappropriate on multiple levels. It reflects a parochial mindset that can't fathom contexts where dynamic type systems can be advantageous, such as a breadth of data processing applications. My favorite irony is how dynamic languages excel at concise translation between opposing type systems -- a very common data processing scenario.

Re: Elixir v1.20: Now a gradually typed language

#355

Post by neya »

SuddsMcDuff wrote: post #316
neya wrote: post #307

Earlier quoted context omitted.

This was the only out of box solution when Elixir didn't support types. So, if you really did Elixir professionally for 6 years, you'd know that by now. > Bad APIs, bad UIs because someone coupled themselves to the database structure and can't escape. If you don't commit yourself to the database structures you defined at the time of application creation, then it just reflects poor planning and architecture overall as…

> If you don't commit yourself to the database structures you defined at the time of application creation, then it just reflects poor planning No it reflects the reality that requirements and applications evolve over time. You sound like someone who's never supported an application for more than 5 minutes.

> You sound like someone who's never supported an application for more than 5 minutes.

If your application requirements change every 5 minutes, then you prove my point - you suck at architecting and should honestly just give your job away to someone more competent.

Re: Elixir v1.20: Now a gradually typed language

#356

Post by neya »

bbkane wrote: post #311
neya wrote: post #307

Earlier quoted context omitted.

This was the only out of box solution when Elixir didn't support types. So, if you really did Elixir professionally for 6 years, you'd know that by now. > Bad APIs, bad UIs because someone coupled themselves to the database structure and can't escape. If you don't commit yourself to the database structures you defined at the time of application creation, then it just reflects poor planning and architecture overall as…

I haven't used Elixer but tt's generally a good idea for the UI to have a different data model than the database (even if it means you initially type almost the same thing twice and have to write a tedious translation layer). This lets you evolve each part independently and use the "native" types frontend vs backend, which happens surprisingly frequently as the app grows

> but tt's generally a good idea for the UI to have a different data model than the database

You're not wrong and most other comments are responding this from some sort of UI library perspective, like React / Svelte. However, if you're using even the barebones scaffolded UI using LiveViews from Phoenix, you don't have to do any of these. Phoenix will wire up the form to the changesets by default. Which is what I'm referring to.

Re: Elixir v1.20: Now a gradually typed language

#357

Post by __turbobrew__ »

lo_zamoyski wrote: post #178
yeetosaurusrex wrote: post #177

I wanted to use functional programming in actual projects and Elixir's lack of static types almost stopped me from picking it up initially. I tried it out and, although I do miss static types sometimes, immutability and not having to deal with inheritance and other OO abstractions has made the trade-off worth it for me. Yes some people do claim that pattern matching makes up for the lack of static types. I don't agre…

You might find Gleam[0] a better fit. [0] https://gleam.run/

I may be wrong, but last time I checked there was not a statically typed OTP implementation which is kindof a bummer. I think Gleam is the ideal implementation on top of the BEAM but it does just seem pretty immature.

Re: Elixir v1.20: Now a gradually typed language

#358

Post by ken-kost »

sethammons wrote: post #298
abrookewood wrote: post #206

Earlier quoted context omitted.

Honestly, I think you're framing this incorrectly. Twitter, Airbnd and Shopify all managed to get massive using Ruby on Rails. Maybe that was part of the reason why? I.e. they were able to move fast and developers were happy. I don't use Rails, so don't have any skin in the game. But who cares if you have to do a re-write once you get to that size?

Having been at a several places that have gone from framework-makes-us-fast to too-massive-for-the-framework, engineering velocity works as a function of how much mental context is needed and how many people/teams have to collaborate. As orgs grow, the only way to maintain velocity is to reduce mental context. Humans have to reason about their systems. In the half a dozen engineering orgs I have worked, each and ever…

> Elixir, I still had to know my whole call chain to know what I could do with my incoming parameters. The more call sites, the more mental context.

but the call chain doesn't have to be long, i.e. it could be just 2 or 3 places; that fits inside my head. less is more

Re: Elixir v1.20: Now a gradually typed language

#359

Post by awepofiwaop »

siwatanejo wrote: post #195
c-hendricks wrote: post #110

Earlier quoted context omitted.

Conversely, TypeScript is my favourite type system because it has to support the wild things people did in untyped languages.

Haha, it is actually my least favorite statically typed lang for this very reason.

I agree. The sheer amount of flexibility it provides makes it both hard to use/read and also not particularly safe/sound. No other type system in existence allows you to be as incoherent as TS.

Re: Elixir v1.20: Now a gradually typed language

#360

Post by bcrosby95 »

neya wrote: post #307
nesarkvechnep wrote: post #301

Earlier quoted context omitted.

Yeah, one of the worst practices. I've been working with Elixir professionally for 6 years now and I still see this sh*t everywhere. Bad APIs, bad UIs because someone coupled themselves to the database structure and can't escape. List of memberships? Keep them as a list with the same fields as the junction table. Top-level APIs taking maps with string keys as "params" so they can very easily be cast for a changeset.

This was the only out of box solution when Elixir didn't support types. So, if you really did Elixir professionally for 6 years, you'd know that by now. > Bad APIs, bad UIs because someone coupled themselves to the database structure and can't escape. If you don't commit yourself to the database structures you defined at the time of application creation, then it just reflects poor planning and architecture overall as…

Sometimes types are worse than the alternative.

I obviously don't know your specific use case, but in my experience having the database schema reflect throughout a project means its either very small or the design is going to run into problems.

It also sounds like a potential security nightmare. We have a policy of never sending domain objects across the wire so nothing accidentally gets sent. APIs must strictly whitelist data structures.

The way this can work in something like an Elixir or Clojure: you have gradual types in most of the core code, but you translate it just before you hit the view layer (e.g. templates).

The great thing about dynamically typed languages is you don't have to declare a new type for each view. You just select out the data you need and expose it for the view. In Clojure this is as simple as a select-keys.

Post reply on HN