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

421–426 of 426 posts

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

#421

Post by geokon »

kamma4434 wrote: post #411
geokon wrote: post #401

Earlier quoted context omitted.

In Clojure you typically program to interfaces/protocols and not to types The Clojure docs should be more straightforward about the interfaces that are available and targetted You can still have a problem of not knowing which is required of an argument, but its usuallt clear contextually

What I mean is that it is harder for me to reason about. In Java you also use collection interfaces, but List is a no brainer.

yeah, your overall point stands. Sometimes you can get a bit mixed up on "wait, does this take a File object or a string with the filename?". I guess my point was that because you program to interfaces this happens a bit less often than one would expect. If it can take a vector it can usually also take a list

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

#422

Post by NortySpock »

sevenzero wrote: post #51
felixgallo wrote: post #40

Earlier quoted context omitted.

what do you mean by 'security related concerns'?

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…

As others have said, the server receives a function call request and decides what to do with it. Whether or not a user or session is currently authorized to perform the action they want is something you evaluate inside the function -- but you

E.g. https://github.com/beyond-all-reason/teiserver/blob/f6ff6d68... here, we are in a function call that handles requests to send a chat message into a game lobby. We updated the flood protection timestamps above, and then determine if the user has permission to send the message, and finally if they are speaking just as a client or via the Coordinator. Then we reply the updated state back to the websocket.

This is what I found beautiful about GenServers, by the way. It's a very explicit "starting state, consume from queue, and each message handling function returns the next system state", which makes it very clear that a state transition does not occur unless you reach the bottom of the event-handling function call, and at that point, it's an atomic state transition of the entire internal state.

In summary: don't trust the client. Independently determine, server-side, in the function itself, if the function call you just received is valid given the current state, not rate limited, etc, and then from there you can choose if you want to act on it.

Disclaimer: Elixir noob, but I have been using Teiserver to learn.

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

#423

Post by igouy »

shakna wrote: post #419
igouy wrote: post #415

Earlier quoted context omitted.

> Huh. The hardware changed. The way measurements were made changed. https://benchmarksgame-team.pages.debian.net/benchmarksgame/... The Java version changed. The SBCL version changed. > side by side You'd have to say what you mean by that.

> You'd have to say what you mean by that. They appear, literally, side by side, in the list. That is, they were competitive eight years ago. They are still competitive today.

By design, the 8 year old page you linked presented Lisp measurements side-by-side against Java measurements (by excluding the other programs).

There's overlap across most of the different language implementations:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

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

#424

Post by h506001 »

__turbobrew__ wrote: post #414
h506001 wrote: post #400

Earlier quoted context omitted.

It’s had it for a long time now: https://gleam-otp.hexdocs.pm/index.html

> Not all Erlang/OTP functionality is included in this library. Some is not possible to represent in a type safe way, so it is not included. Other features are still in development, such as further process supervision strategies. It seems like they are re-implementing a half baked OTP lookalike, but they aren’t actually using Erlang/OTP under the hood which gives me pause as the Erlang/OTP implementation has been bat…

Sounds like you can’t be happy with Gleam or related libs. I’d look into it or use it before calling it “half-baked”.

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

#425

Post by mountainriver »

bullfightonmars wrote: post #251
mountainriver wrote: post #185

Earlier quoted context omitted.

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.

I use rails because it makes thousands of good choices that I never have to make. If build apps the rails way I don't have to deal with a mountain of tech debt (in the form bad or ever changing choices).

Your app will be demonstrably slower, less efficient, and less reliable than an app written in Rust

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

#426

Post by mountainriver »

FeteCommuniste wrote: post #201
mountainriver wrote: post #185

Earlier quoted context omitted.

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.

So the future of programming is asking an LLM to spit out the appropriate assembly?

Pretty close to it, at least Rust for now. I can't tell the difference between asking it to output Rust vs anything else at this point
Post reply on HN