I hear so much good stuff about Elixir and Phoenix (often from fly.io blogs) but I've always dismissed it for the lack of type support. Is there a TypeScript equivalent on the horizon? Or is it not so much of an issue?
Glad to see that some people are doing a more serious job than me :)
(also, it's a small world – I know Giuseppe Castagna, wasn't aware that he was working on typing Elixir)
I will say that editor support for static languages is categorically better due to the language server being able to more completely reason about the state of your code. That’s the one drawback.
For example doing "1" + 2 would give you an error.
OCaml takes it a step further with numbers where `+` only works on integers. You need to do `+.` to add floats. This lets it be statically typed without having to actually specify any types.
Again, a little out of my depth in terms of rock solid explanations.
I wasn't meaning to imply everything is perfect, though. For example equality operators take anything. I believe there may be changes coming around there.
https://thinkingelixir.com/elixir-in-the-type-system-quadran....
You omitted the caveat: the program will behave in unexpected ways sometimes. What else do you do to ensure correctness?
ie The minimum bar for modern software is not "it compiles, ship it".
I think the fact that most functions are "pure" / "static" is really helping with refactorings.
This topic has come up quite a few times on HN, but it seems like it’s generally people who haven’t ever used Clojure or another similar immutable functional language that worry about this.
IMO, Elixir and Clojure hit the sweet spot between a language like Ruby and one with an ML-inspired type system.
Elixir has great support for pattern matching, guards, documentation, testing and being a functional language all help negate the problems of a dynamic language.
Really they are a perfectly regular form of type hinting--as is pattern matching in function heads--when being used for no other purpose than to ensure the correct type is passed at runtime.
I know from Elm that it does change how things feel. I could see an upside. But coming from a dynamic life I can't quite grok considering it a requirement.
It really depends on your definition of your massive. Discord seems to have a few hundreds to a thousand employees in total. I am from a typical tech company. So I could estimate that their total engineers count is probably just a couple of hundreds, which is about our director/senior director's team size.
In our definition of massive, we could have even hundreds of ppl to touch the same portion of the code base frequently. We regularly have to deal with code which are about 10 years old and it's a moving target. You have to deliver quickly with migration requirement in mind. Also we frequently collaborate with the other teams and you have to be able to understand others' code quickly.
Typing is critical as you don't have time to deal with the constant stream of the new projects to dig deeper in to the objects. And you really want to have some understanding of the code in the first glance. We also want to offload lots of the things to compiler and ide as much as possible.
It doesn't have to be full on static typing like Java, type annotation in python/ruby already helped a lot
massive as in the top 10% of tech companies in the entire globe
> Discord seems to have a few hundreds to a thousand employees in total
quote: WhatsApp scaled to 1B users with only 50 engineers [1]
But are you talking about the size or the impact of the project? I am in the fintech space and the complexity and cruft is just incredible thick. We just needs so many ppl to do the dirty work. There is no way for you to shrink the code base fundamentally
> quote: WhatsApp scaled to 1B users with only 50 engineers [1]
Again, are we talking about the size or the impact? Are you saying all the projects for in faang can be handled like this? Meta currently have about 70k engineers. What do you think that all those people are doing?
justifying the salary of middle managers.
at my current job the number of employees has increased 30x in just 5 years.
there's no important single task we couldn't do when we were 1/30th of now, 2.5x would have been the perfect number to make all of us work no more than 3 days/week, now we are just working on more tasks that are basically DOA or scratch the itches of higher ups who want their name on something when they meet with other higher ups but are useless. Moreover, more often than not, they are a minor variation of something that already existed for a long time, works better, serves a real business purpose and it's written in legacy languages because it just works (I'm sure many of us have attended the and now with AI! BS meeting).
We also know Facebook's 70k employees are there so that many of them won't end up working somewhere else and help the competition (see the Silicon Valley No-poaching Case).
I'm an advocate for not burning up your employees and hire more than you need so everyone can relax, I'm a union representative (on of the) in the company I work for (yes, my country is highly unionized and thanks god it is) so I deeply support the needs of the workers against the absurd demands of the companies, but at some point too many people becomes a burden and severely hinders communication, it basically creates a layers of bureaucracy that resembles much more politics than the job you were hired for, ending up stressing people more, creating harmful frictions, complicated workflows, absurd chains of indirection and countless authorization requests that in the end reduce everyone's output, regardless of the commitment of the single employee.
Also, larger companies get a lot more slack taxation wise and receives a lot more cuts from the government, because unemployment makes us look bad.
That's just ridiculous if you think this applies to all projects. We have incredible amount legal, tax, sanction etc in the code. Have you seen how complex real world financial and legal system can be, do you know how much work to translate those into code? And keeps updating it?
And to just to interface with other financial system worldwide, we have to keep the old system in place, at same time upgrade as the industry move forward. It's a also a big challenge. Despite the above and we had to ship fast, we are actually still SHORT on people. Our engineer to manager ratio is also high. The world is a complex place, sometimes you just have to deal with it.
Again, why do you think 50 man team applies to all projects? What is it so hard to believe that some complexity cannot be reduced?
> We also know Facebook's 70k employees are there so that many of them won't end up working somewhere else and help the competition
You get this from the TV show. Have you actually worked in the companies at Meta caliber? Do you really think most faang employees just do nothing everyday?
you're taking it personally.
I work for a > 30k employees company, not based in the US.
All I'm saying is companies optimize for what's better for them, so at some point you'll have on payroll thousands of people you don't need for your core business because they solve a lot of non-core functions. such as dealing with authorities or devise a strategy to reduce the pool of talents competition can pick from. HR, accounting and legal departments will also increase in size a lot consequentially. so their massive size doesn't says much about the complexity of the tech problem they are solving.
the fact that Discord runs on Elixir at that scale is remarkable, regardless of how many people work at Discord.
YMMV very large project have been written in Erlang/Elixir without static typing and they've been wildly successfull
i.e WhatsApp (based on Ejabberd), Ericsson network switches, RabbitMQ, CouchDB and a lot more, you can read about some of them here https://www.erlang-solutions.com/blog/which-companies-are-us...
as a less knows example, an entire insurance company in my country with > 1 million customers