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

Elixir – HUGE Release Coming Soon

genserver.social

Post reply on HN
Print view View original

61–70 of 83 posts

Re: Elixir – HUGE Release Coming Soon

#61

Post by packetlost »

hinkley wrote: post #43
sph wrote: post #17

Earlier quoted context omitted.

IIRC José recently said he was was gonna spend some time thinking about Elixir's approach to typing, so that's probably it. My hope is a smaller runtime that works well for CLI tools. I'd love to use Elixir for small scripts I'd ordinarily use Go/Python for.

I had an idea years ago when I still had the young man’s dream about writing a programming language. It came after I took over a J2ME project that was trying to do a great deal of functionality in an 85K jarfile. That idea was that there should be a little language inside of each big language that is used to implement the self hosting aspects of the language, and then a small set of additional libraries would provide…

I like this idea. I believe Rust does something somewhat similar (though not quite) for processing compile-time procedural macros. We see somewhat similar, but external approaches in the Clojure ecosystem with Babashka and Joker (and probably a few others).

In general, I like this, but not every language actually needs it. Like, what would that even be in Python for example?

Re: Elixir – HUGE Release Coming Soon

#62

Post by hinkley »

packetlost wrote: post #61
hinkley wrote: post #43

Earlier quoted context omitted.

I had an idea years ago when I still had the young man’s dream about writing a programming language. It came after I took over a J2ME project that was trying to do a great deal of functionality in an 85K jarfile. That idea was that there should be a little language inside of each big language that is used to implement the self hosting aspects of the language, and then a small set of additional libraries would provide…

I like this idea. I believe Rust does something somewhat similar (though not quite) for processing compile-time procedural macros. We see somewhat similar, but external approaches in the Clojure ecosystem with Babashka and Joker (and probably a few others). In general, I like this, but not every language actually needs it. Like, what would that even be in Python for example?

Something for PyPy perhaps? JITs written in the host language are the original use case I was thinking of, but that’s not the sole domain where it applies.

Re: Elixir – HUGE Release Coming Soon

#64

Post by josevalim »

epolanski wrote: post #36
vasergen wrote: post #28

Earlier quoted context omitted.

static types is the main thing that keeps me from putting more time into learning / using elixir.

Me too. Every time I read statements like this from Jose "This brings another discussion point: a type system naturally restricts the amount of code we can write because, in order to prove certain properties about our code, certain styles have to be rejected." I can't but think few things: - by compilers (in this case static type checkers) laws we all know that there are valid programs that won't satisfy the type che…

The main question of the quote is: if we introduce a system that rejects a "large" amount of Elixir code, will developers adopt it? If some language features are only available for "untyped" code, will developers often forego types only to get those features? And if that happens, could we end-up "forking" the Elixir community, where part of the community uses some idioms and the other part uses others (which is a common complaint about large languages)?

The goal is not to reject types but rather to find a theory that mirrors the language as close as possible. I believe balancing these trade-offs will be essential to the adoption and success of a type system in Elixir.

Re: Elixir – HUGE Release Coming Soon

#66

Post by josevalim »

conradfr wrote: post #37
josevalim wrote: post #32

Earlier quoted context omitted.

Zero-arity functions are your externally visible module constants. :)

Sure, but I find it less readable and more verbose than your usual constants. Also you can't pattern match on a function return value IIRC. Or maybe I didn't find the right syntax, I get "invalid pattern in match" or "cannot invoke remote function inside a match" when pattern matching on function parameters. There's also solutions with macros, but why complicate something so simple :)

Those are all good points.

When we talk about macros and function parameters, however, we want to avoid spreading multiple constants across multiple modules, because they lead to compile-time dependencies (and potentially long compilation cycles), so my go-to approach has been to define a single module with all of my constants (they could be macros or not, it changes per project).

I wonder if this could be a matter of promoting certain styles rather than adding language features?

Re: Elixir – HUGE Release Coming Soon

#67

Post by packetlost »

bcrosby95 wrote: post #55
epolanski wrote: post #36

Earlier quoted context omitted.

Me too. Every time I read statements like this from Jose "This brings another discussion point: a type system naturally restricts the amount of code we can write because, in order to prove certain properties about our code, certain styles have to be rejected." I can't but think few things: - by compilers (in this case static type checkers) laws we all know that there are valid programs that won't satisfy the type che…

> I've noticed that people with a huge background in dynamic languages tend to have a natural refusal for static types. Lispers are a community with such an attitude, even the typed lisps like typed/racket seem to be born more to please people wanting typecheckers and academics than the userbase itself. I feel like it's the opposite. It seems like we have this huge wave of a push for static types. The only way I can…

As someone maintaining a moderately complex codebase in Python: static typing doesn't feel valuable until you need it. But then you really, really need it. Thank god for Mypy and type-hints.

I'd prefer something that can infer types in the simple case and have explicit types when dealing with huge complexity. Really, it comes down to having tight control around the shapes of your data, and that is incredibly valuable when you cannot keep the entire codebase/API/contract in your head. Quick navigation is a huge bonus too.

Re: Elixir – HUGE Release Coming Soon

#68

Post by freedomben »

josevalim wrote: post #64
epolanski wrote: post #36

Earlier quoted context omitted.

Me too. Every time I read statements like this from Jose "This brings another discussion point: a type system naturally restricts the amount of code we can write because, in order to prove certain properties about our code, certain styles have to be rejected." I can't but think few things: - by compilers (in this case static type checkers) laws we all know that there are valid programs that won't satisfy the type che…

The main question of the quote is: if we introduce a system that rejects a "large" amount of Elixir code, will developers adopt it? If some language features are only available for "untyped" code, will developers often forego types only to get those features? And if that happens, could we end-up "forking" the Elixir community, where part of the community uses some idioms and the other part uses others (which is a com…

I use Elixir whenever I can, and I would love a better type system (though I admittedly suck at using what Dialyzer already provides, which is extensive). I'm very excited to see where the current effort goes!

But absolutely, if new types break existing Elixir code and idioms it would result in a schism that would be devastating and disastrous to the Elixir community. I for one am really glad you are asking these questions, and FWIW I think you're doing exactly the right thing.

Re: Elixir – HUGE Release Coming Soon

#69

Post by freedomben »

epolanski wrote: post #36
vasergen wrote: post #28

Earlier quoted context omitted.

static types is the main thing that keeps me from putting more time into learning / using elixir.

Me too. Every time I read statements like this from Jose "This brings another discussion point: a type system naturally restricts the amount of code we can write because, in order to prove certain properties about our code, certain styles have to be rejected." I can't but think few things: - by compilers (in this case static type checkers) laws we all know that there are valid programs that won't satisfy the type che…

It's not satisfying to everyone, but if lack of types is hampering your desire to learn Elixir, check out Dialyzer[1]. It's certainly not perfect, but between pattern matching struct arguments and Dialyzer, I've yet to personally encounter a situation where it wasn't sufficient.

[1]: http://coolerranch.com/using-dialyzer-in-elixir/

Post reply on HN