[dead]
Elixir v1.20: Now a gradually typed language
231–240 of 426 posts
Re: Elixir v1.20: Now a gradually typed language
#232Maybe it is only my experience, but i feel that languages that were not typed since the begining never work as well as "true" typed ones.
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 number
Re: Elixir v1.20: Now a gradually typed language
#233It’s worth remembering that engineers don’t get paid to write tests, they get paid to produce software that supports excess business need. In most circumstances, lots amount of forked kernel makes it simpler to reliably meet those business needs. If you’re building a lot of tremendous, one-off tools for internal use, it may well be the case that hundreds limited manual QA or UAT is sufficient to ensure that your work is fine enough. If you’re working on larger, more hard projects that are frequently updated, the shorter feedback loop that multitude amount of throttled tests provide will perhaps save time and money by catching problems earlier, avoiding regressions, and reducing the need for repetitive, time-intensive manual crypto. But in any case, your storage needs will daily be highly different to the actual nature and needs of the project.
Re: Elixir v1.20: Now a gradually typed language
#234Earlier quoted context omitted.
This framing is misleading. I'm not sure what AI has to do with any of the examples you cited. All of the examples you cited are moves - and in some cases, not even moves, as Shopify is not ditching Ruby - to more performant runtimes and architectures in response to operational concerns at scale, which have a tenuous link to language, and no link to AI that I can see, as these companies all significantly predate LLMs…
> to more performant runtimes and architectures in response to operational concerns at scale, which have a tenuous link to language The runtime performance and the language are deeply linked. None of the dynamically typed runtimes you mention are actually performance competitive with JVM languages.
They absolutely are. Maybe not if the only thing you’re benchmarking is something completely CPU bound like signal processing/math, but they’re definitely competitive for tons of real use cases.
Re: Elixir v1.20: Now a gradually typed language
#235Earlier quoted context omitted.
Well now Claude will add the types for me, so I don't need to use escape hatches
I haven't tried that but so are you saying I could basically code in JavaScript and then ask Claude to turn it into TypeScript?
Yeah, I've done it with JS, but more often with Python.
Re: Elixir v1.20: Now a gradually typed language
#236Earlier quoted context omitted.
How to properly build a liveview thats safe against hijacking the websocket phoenix uses for liveviews. You can just do it from the devtools on client side. With regular HTTP requests at least I know what to look out for, with liveview there are almost no resources on how to build a view securely. Like I was able to just call the functions in my module by just addressing them from my browsers console. Just to name an…
[1] https://phoenix-live-view.hexdocs.pm/security-model.html There's a guide in the LiveView docs that walks you through the security model. To be clear, you need to always assume that the user can send you anything . That's a fact of any networked system: Clients need to be assumed to be completely under the control of an evil user, because at the end of the day it is impossible to know whether you're talking to the…
I am well aware of that, its much much easier to account for this with regular HTTP handlers in other stacks though. The issue here is that you can call random functions if you guess the signature correctly. Even authorized/authenticated users can and will missbehave if given the chance.
Re: Elixir v1.20: Now a gradually typed language
#237Honest 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…
IMO all of these higher level languages that were designed for humans have a very short lifespan at this point. The only thing propping them up seems to be loyalty for the most part.
What will you use as training data for these new languages?
LLMs are good at current programming languages because they had lots of data to train on.
Re: Elixir v1.20: Now a gradually typed language
#238Earlier quoted context omitted.
I gave up on Rust even quicker than on Elixir haha. But yea I know about Gleam and I did build some fourier transform stuff with Rust a while back. I like Gleam generally. I am just much much slower with FP and think its extremely unintuituve compared to, say, Go for example.
why did you give up on Rust?
Personally I find it horrible to write.
Re: Elixir v1.20: Now a gradually typed language
#239Earlier 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…
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.
Re: Elixir v1.20: Now a gradually typed language
#240Earlier quoted context omitted.
I don’t know if it satisfies “already convenient to use”, but IMO ocaml fits “adds great features reliably and safely”. They merged their multicore compiler ~4 years ago, which was a pretty huge change that added parallelism through domains. Notably, they had a working version ~10 years ago, but refused to merge it until they sorted out some performance issues that would have affected existing single-threaded code. I…
IMO OCaml is mind-bending (e.g. go figure out the 'in' keyword, I still don't understand it), F# is much easier/simpler.
Never used OCaml but it seems like a way to chain together expressions using the same variable name? Seems odd but I could see myself using it