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

241–250 of 426 posts

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

#241

Post by neya »

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…

If you use Phoenix, using types at the data model level using changesets and then trickling them down all the way to the UI is a very good compromise. As changesets provide type validations out of the box too.

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

#242

Post by toast0 »

klibertp wrote: post #151
sevenzero wrote: post #34

Earlier quoted context omitted.

The confusing state riddling here happens in the background as your whole app basically is a state. The thing that really throws me off with Elixir is having to handle (possibly) hundreds of thousands of processes. Doing this correctly seemed impossible to learn for me.

> Elixir is having to handle (possibly) hundreds of thousands of processes OMG, why? Why would you ever have so many processes? All of them at the same time? Are you going to animate a 3D scene and run a process for each vertex, or something? No, I mean, if you're WhatsApp - across all nodes - then somehow maybe yes? At scale. But in normal code, slicing workloads too thinly is counterproductive, and having even tens…

> No, I mean, if you're WhatsApp - across all nodes - then somehow maybe yes?

I mean, we had one process per client connection (which is 100% the way to go) and depending on the era, hundreds of thousands or millions of connections per chat node. I don't think we ever really summed the number of processes over a cluster.

Other than client processes, there weren't that many processes per node; like you say, it doesn't make sense to spread too thin.

There's a lot of client connections and so a lot of client processes, but it ends up being pretty simple to work with them. They all do the same thing... wait for a message, process the message, wait some more. Some of the messages are tricky to process (like the user just logged in again over here, so please transfer the state)

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

#243

Post by toast0 »

sevenzero wrote: post #239
klibertp wrote: post #151

Earlier quoted context omitted.

> Elixir is having to handle (possibly) hundreds of thousands of processes OMG, why? Why would you ever have so many processes? All of them at the same time? Are you going to animate a 3D scene and run a process for each vertex, or something? No, I mean, if you're WhatsApp - across all nodes - then somehow maybe yes? At scale. But in normal code, slicing workloads too thinly is counterproductive, and having even tens…

I learned it for almost a full year by trying to build a live chat app. I went through Elixir in Action and the official guides and yet those questions were never really answered. I never said I want hundreds of thousands of processes, but thats definitely a thing you need to account for. Errors are often simply swallowed.

> Errors are often simply swallowed.

That's a choice, but it's not idiomatic.

You're expected to write things like...

    ok = thing_that_might_not_work().
(Well, that's what it looks like in Erlang anyway). If there's an error, it doesn't match, so it crashes. You don't have to check for success, but it's easy to, and 'let it crash' is the mantra, so yeah. Then you watch for crashes, and fix them with hot loading, and pretty soon you have a reliable system.

Let it crash ends up not quite working, so you end up catching a lot of errors, but you should be logging them, not swallowing them...

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

#244

Post by sevenzero »

arcanemachiner wrote: post #148
sevenzero wrote: post #8

Earlier quoted context omitted.

Yea I've posted there twice as far as I remember. You will absolutely get help, whether you understand the answers is a whole different story. Elixirs community is great. Its just hard to learn because it's not yet widely adopted, there are no (non senior) roles for it and it's a lot of work understanding all the BEAM concepts. A thing just being interesting isn't enough motivation for me to learn, I need a bigger go…

I haven't dug into this for a while, bit you should be able to define a catch-all event to return a respond to non-compliant requests . It should be built-in to some degree IMO, but I think it's not an unsolved problem.

This will not work if a attacker guesses a function signature correctly as the catch all block usually is at the bottom of the module. If you use atoms in the function signature, attackers can just guess them, even if you never intended that function to be reachable from frontend code.

That being said, I am not forced to use liveview, its just that most ressources nowadays use it.

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

#245

Post by steve_adams_86 »

neya wrote: post #241
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…

If you use Phoenix, using types at the data model level using changesets and then trickling them down all the way to the UI is a very good compromise. As changesets provide type validations out of the box too.

Do changesets incur a runtime cost?

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

#246

Post by zxter »

cubefox wrote: post #171
isityettime wrote: post #75

Earlier quoted context omitted.

> I love everything about Elixir, but Elixir constantly makes me doubt myself like no other language. My brain isnt made for functional stuff, but this makes me want to try again. I experienced this really painfully when I was in college and took a kind of "survey of programming paradigms" course and tried Haskell for the first time. I'd been programming for years by then, and I couldn't believe how helpless I was at…

> But I don't think it's about the brain not being suited, I think it's that contrast of your experience level in imperative languages vs. the fact that when working in a pure functional style, you start out as a newbie again. When I was in university, the introductory class was about Java, and an advanced class in the next semester was about Haskell. There were many imperative/functional newbies in both classes, but…

Cookbooks are imperative, sure. But not every book is a cookbook.

Religious texts, philosophy, ethics, and even self-improvement books often don't provide a procedure to follow. They teach things like how to handle conflict, how to act fairly, how to navigate difficult situations, or how to reason about competing values.

People then take those ideas and apply them across many different situations in their daily lives. In a sense, they build a toolbox of reusable mental functions rather than memorizing a single algorithm.

That's also why many people finish a self-improvement book feeling like they didn't get much out of it. They were expecting a recipe. Instead, they absorbed a collection of abstractions that only reveal their value when applied later in real situations.

The fact that cookbooks are imperative mainly shows that procedural tasks are naturally expressed procedurally. It's not obvious that this generalizes to human reasoning as a whole.

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

#247

Post by mikepurvis »

dnautics wrote: post #182
teleforce wrote: post #163

Honest question, in the era of vibe and AI assisted coding is there any advantages of using untyped programming languages, apart from the fact that non-typed languages has more traning data for the LLM? This probably controversial, but personally I consider untyped languages as technical debts that need to be fixed sooner or later, and the OP article is partly addressing this very issue. Rewriting critical software i…

> is there any advantages of using untyped programming language without any evidence, i claim the corpus might have higher quality variable names and conventions that are "human crutches" around not having types. LLM knowledge in your non public codebase must be strictly local, and so checking on details and identities of types incurs a cost for the LLM to go fetch that info. if the LLM can "just know" (guess with ve…

Rather than having the LLM and human devs all guessing from verbose variable names, can't they both use a language server that observes the code and can surface that kind of structure info cheaply?

Part of the point of types is enforcing more of the contract at various code boundaries (function, module, etc), and that enforcement is specifically so that you don't have to keep the whole codebase in your head / context window in order to be able to work on it.

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

#248

Post by bluepnume »

galaxyLogic wrote: post #188
meghprkh wrote: post #172

Earlier quoted context omitted.

Not necessarily. Since the word "typed" language is not well-defined. For example, typescript is a fantastic language for marshalling data and UI state since it uses substructural typing instead of nominal typing. Libraries like kysely / other ORM libraries are great examples too and easy to use, whereas in fully typed languages like Rust you would end up having to use a macro library like sqlx or having to define st…

As I understand it TypeScript does not enforce types at runtime. Am I correct? If so that would signify to me it is not a "typed language", like say Java for instance. Types in TypeScript are more like "annotations" for docujmenting the program. Am I correct?

[dead]

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

#249

Post by xlii »

losvedir wrote: post #88

Oooh, here we go! As a professional Elixir developer for... 10-ish years now, I've been super excited about types coming. I'm very excited that the beginnings have started to land here. That said, I would love to know how the state of what's in v1.20 compares to un-spec'ed dialyzer. I was under the impression that dyalizer's "success typing" approach (not flagging a function if there are some combination of parameter…

Dialyzer fails to successfully report errors when there are circular dependencies. Circular dependencies are nigh unavoidable in Elixir (IIRC bootstrapped Phoenix has 3 or 4) and outside of interfering with Dialyzer it impacts on compilation performance and stability (compilation races causing non deterministic compilation)

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

#250

Post by koito17 »

awepofiwaop wrote: post #232
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.

The issue with TS is that it's not really a type system, it's mostly just comments with a linter bolted on. It tries, but it's fundamentally broken in too many ways. Here's just one very simple example, there are many more. I've checked all the strict mode options and this appears to still "typecheck". var x: {a: number} = {a: 1}; var y: {a: number|string} = x; y.a = 'FAIL'; var n: number = x.a; // not actually a num…

Two things to note:

1. TypeScript doesn't aim to have a sound type system. i.e. there may be things the type system accepts that are actually unsafe.

2. this is more of an issue with mutation. If those properties were marked `readonly`, then the assignment of y.a wouldn't work at all. You can also encapsulate mutation behind functions with your intended types.

I tend to write TypeScript in a "functional" or "immutable" way, and in this case, most soundness issues come from things like array index access, which can't really be solved without dependent types anyway.

With that said, TypeScript still gets one quite far *despite* soundness not being a goal of the type system. The problem is that writing imperative, mutable code will make you go through (intentionally!) unsound covariance of types. Similar issues exist for code with side effects, since TypeScript has no way to encode effects in the type system. This is why some language communities settle on ideas like "functional core, imperative shell", where the ultimate goal is absolute minimum amount of code involved in side effects and mutation, while everything else is designed to be easy to test (and, ideally, expressible with a sound subset of your type system).

Post reply on HN