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

Strong arrows: a new approach to gradual typing

elixir-lang.org

Post reply on HN
Print view View original

31–40 of 87 posts

Re: Strong arrows: a new approach to gradual typing

#31

Post by anonyfox »

di4na wrote: post #19
anonyfox wrote: post #3

I cannot support much in terms of money or time currently, but somehow I'd wish there are ways to speed this up. Sure, sponsoring from big corps comes with their own problems, but maybe that would be an option? There are quite some that use Elixir (or BEAM in general) out there... Idk what would be the best approach. But I am very convinced that Elixir and the wider ecosystem (not only phoenix liveview) is (or could…

Tbf. While more money to allows stability of people involved would help, it would not really speed it up that much. Typescript had ms behind it and it still took a decade. At some point the engineering, experiments and learning take time and you can hardly speed it up with more ressources.

Maybe more like different layers could do different strategies? I can't even imagine what could happen to the BEAM itself if there are the same amount of ressources put on it like in our modern JS engines that have come a loooong way. Its already an amazing piece of tech in itself, but I wonder what an army of experts could do ontop of it.

Re: Strong arrows: a new approach to gradual typing

#32

Post by josevalim »

anonyfox wrote: post #3

I cannot support much in terms of money or time currently, but somehow I'd wish there are ways to speed this up. Sure, sponsoring from big corps comes with their own problems, but maybe that would be an option? There are quite some that use Elixir (or BEAM in general) out there... Idk what would be the best approach. But I am very convinced that Elixir and the wider ecosystem (not only phoenix liveview) is (or could…

I understand many would love to have this yesterday but I strongly believe we should not speed it up. :)

This is potentially the largest change the language will ever go through and we are being very intentional and deliberate on every step and decision we make. Once we start collecting feedback from the community, it may speed up or slow down the process, but I want to make sure everyone gets plenty of time to experience and internalize the changes.

When it comes to funding, the on-going work on Elixir type system is well funded by companies like Fresha, Starfish*, Supabase, and Dashbit. However, we also want to venture into new research areas, such as existential set-theoretic types, which would allow us to type behaviours (such as GenServer) similar to how one would type first-class modules in OCaml (or Typeclasses in Haskell). If someone is interested in sponsoring research work, hit me up (github.com/josevalim), and I can put you in touch with the proper institutions.

Re: Strong arrows: a new approach to gradual typing

#33

Post by raphlinus »

yawboakye wrote: post #10

the arc of progress in software engineering bends towards static typing. in the future, our type systems will be so powerful they'll be able to do more inference so that we have to be less explicit. then people who have come to hate static type because of these explicit type declarations will know they hated the costume after all, not the person in it.

Yeah, Rich Feldman has a good talk on this, entitled Why Static Typing Came Back[1]. It makes a good argument that static typing can recover most of the advantages traditionally accounted to dynamic typing. Rapid iteration you can get from incremental compilers, being concise you can get from powerful type inference, etc. Conversely, the advantages of static typing (largely boiling down to increased reliability) cannot easily be captured by dynamically typed languages. Gradual typing, particularly successful by TypeScript, might be an interesting middle ground, or it might just be a reflection of the dynamic history of JS.

[1]: https://www.youtube.com/watch?v=Tml94je2edk

Re: Strong arrows: a new approach to gradual typing

#34

Post by jerf »

josevalim wrote: post #21
daxfohl wrote: post #12

Earlier quoted context omitted.

I read that Brex moved away from Elixir to Kotlin. If Elixir was really that great then why would a company put such a big effort to ditch it? That killed off my interest in learning it, but maybe their reasons were invalid? Genuinely curious.

You will find examples from companies moving away from Elixir, Python, JavaScript, Scala, Java, etc. I don't think there is any programming language that is "unditchable". So I'd suggest to analyze the reasons that made a company move away from X, check if they are still relevant, if they'd apply to you, and, if yes, if they are a deal breaker or something you can work around. For the Brex case, if I remember correct…

'I don't think there is any programming language that is "unditchable".'

There can not exist one perfect programming language for all uses. (Sometimes people don't like that statement but I think if you seriously sit down and work the math it's pretty obvious that, as a simple for instance, Rust is not going to replace all shell scripting and shell scripting is not going to replace all Rust, and that's just an example, the principle holds in numerous dimensions in the programming language space. [1])

There are always people making bad decisions, some of those bad decisions are about which programming language to adopt for a problem.

So, yes, you'll always be able to find companies dropping some language, but it isn't necessarily the language's "fault".

I don't say this on every such article in the comments because it's kinda kicking someone while they're down, but I would assess that the clear majority of the ever-present torrent of "We switched from X to Y and look how much better Y is!" are actually long and detailed explanations of how the company in question chose the wrong technology for their problem, not how bad X is. The two major exceptions are "our tech in X predates Y existing as a valid choice, and now that it does, it's a better choice" (can't blame them for existing before the right tech, I've made that move myself in my own career) and "We did our research and X really should have worked but we got into it only to discover that it really didn't for some reason we could not have reasonably anticipated". That latter is pretty rare, IMHO, but I've seen it a couple of times. (Generally it is when a closed-source stack has a fundamental problem and you can't fix it, because it's closed source.)

(I suppose there's also "X was a good choice initially but we outgrew it", but in my very opinionated opinion even these are often... dubious. It happens, yeah, but in my personal opinion it still means the language chosen was not able to scale the solution. Only people truly suprised by their growth, which does happen, should reach for this.)

[1]: And if that still bothers you, think small shell rather than large. I'm not going to write Rust for the equivalent of "awk '{ print $3 }' myfile | sort | gzip > sorted_names.gz". However broken shell legitimately is as a programming language, you simply can not argue with that kind of bang-for-the-buck.

Re: Strong arrows: a new approach to gradual typing

#35

Post by adgjlsfhk1 »

jovial_cavalier wrote: post #22
tjrgergw wrote: post #18

"gradual typing" is exactly how I code Julia. Disclaimer: this is not how to the strengths of Julia are normally described by most people, it's just how I think about it. You might have heard that Julia solves the two language problem (easy as python, fast as C++). But exactly how does it do that? In python you don't have to care about types, but even if you were willing to care about types you wouldn't get any perfo…

Julia is slower than Python for most applications if you include the compile time (which is every time you run your program, because it's "just in time"). edit: I want to be clear - I like Julia, and I have long wanted a scripting language that was gramatically simple like python but had support for strong typing, etc. But the TTFX problem, for me, muddies the waters on the question of "which is faster, Julia or Pyth…

This is not true https://benchmarksgame-team.pages.debian.net/benchmarksgame/... shows the middle of the pack julia implementations being over 10x faster than the fastest python implementations including startup and compile time.

Re: Strong arrows: a new approach to gradual typing

#37

Post by aatd86 »

tutfbhuf wrote: post #13

When we talk about arrows in terms of functional programming, we really mean Hughes’ Arrows (or Freyd-categories) a generalization of monads. The term arrow represents a level of abstraction over computations, essentially modeling them as objects with inputs and outputs. Hughes' Arrows extend beyond the traditional notion of functors and monads in handling side effects and common computational patterns in a more stru…

And here I thought it was just about functions (arrow type) ;p

Re: Strong arrows: a new approach to gradual typing

#38

Post by Aerbil313 »

anonyfox wrote: post #3

I cannot support much in terms of money or time currently, but somehow I'd wish there are ways to speed this up. Sure, sponsoring from big corps comes with their own problems, but maybe that would be an option? There are quite some that use Elixir (or BEAM in general) out there... Idk what would be the best approach. But I am very convinced that Elixir and the wider ecosystem (not only phoenix liveview) is (or could…

I’m curious. What exactly is Elixir good for? What do you find in it more appealing than other languages?

Re: Strong arrows: a new approach to gradual typing

#39

Post by jovial_cavalier »

tjrgergw wrote: post #24
jovial_cavalier wrote: post #22

Earlier quoted context omitted.

Julia is slower than Python for most applications if you include the compile time (which is every time you run your program, because it's "just in time"). edit: I want to be clear - I like Julia, and I have long wanted a scripting language that was gramatically simple like python but had support for strong typing, etc. But the TTFX problem, for me, muddies the waters on the question of "which is faster, Julia or Pyth…

You compile your code every time you run it? Yikes. Sorry to hear that.

Is there a way to get around that in Julia? I tried to find a way to compile programs directly, and was disappointed with what was on offer.

Re: Strong arrows: a new approach to gradual typing

#40

Post by jovial_cavalier »

johnbcoughlin wrote: post #25
jovial_cavalier wrote: post #22

Earlier quoted context omitted.

Julia is slower than Python for most applications if you include the compile time (which is every time you run your program, because it's "just in time"). edit: I want to be clear - I like Julia, and I have long wanted a scripting language that was gramatically simple like python but had support for strong typing, etc. But the TTFX problem, for me, muddies the waters on the question of "which is faster, Julia or Pyth…

What does "most applications" mean?

Most code that is written is code that is run frequently and with a short runtime. Julia is not good at this.
Post reply on HN