Cone tond
Switching to Elixir
211–220 of 283 posts
Re: Switching to Elixir
#212I often see people say static typing slows them down and I'd really like to know why that is because for me it's the exact opposite, I really don't like not knowing what format data is in. I'd much rather have to write slightly more verbose code and have a vast number of possible errors caught at compile time instead of having things go wrong in production when someone inputs something a bit weird with nothing so muc…
I think loose typing helps to prototype faster, while static typing helps you write the correct/safe version faster. But part of doing the correct version is clarifying spec, and prototyping can help with that - so it is a weakly held opinion.
I could not disagree with this more. You are aided in prototyping by forming an early opinion on your data models. I would argue there's nothing more important in conceiving of something new than understanding the shape and relationships in your data. Typing does that.
And nothing slows a developer down more than accruing technical debt as they build. It's like having tar stuck to your shoes. You will work the fastest when you have nothing to pay back because your mental model of the application is aligned with the intention of your program.
(That said, I don't think you necessarily need a strong static type system to achieve these aims.)
Re: Switching to Elixir
#213For me the big sell of Elixir/Erlang is that it makes running "background jobs" a complete breeze with no concern for blocking IO bringing the entire server to a halt, especially in a web server context. At my last job I had to do a bunch of HTTP requests in a webhook handler and if enough happened at once, the entire site would just crash due to all the OS processes being busy. I found myself desperately wishing I w…
Meh. I don't want background jobs to be a breeze in quite this way. I want background work to live on different compute capacity than http requests, both because they have very different resources usage and because I want to have state or queues in front of background work so there's a well-defined process for retry, error handling, and back-pressure. I get it, of course, it'd be lovely if these complications didn't…
> I want background work to live on different compute capacity than http requests
The magic of Elixir/Erlang is that all of this logic can live in one codebase and you can choose when deploying your distributed cluster of Elixir/Erlang nodes which nodes run which tasks. The nodes are all aware of each other and when something happens that requires execution of that task it happens on the correct nodes because they're the only ones running those processes. Automagically.
Re: Switching to Elixir
#214Earlier quoted context omitted.
I mostly agree with you. Just wanted to add that in some languages, for example in Typescript, there are ways to say that you do not care about the type for prototyping. For example using :unknown or :any.
:unknown is great, but the problems come in the middle area; when you have lots of very tight types and are prototyping something that makes use of those things, :unknown doesn't work, and :any can be too expressive, even for your prototype.
> when you have lots of very tight types
This is true. But also I've noticed many less experienced TS devs end up writing types that are too specific and not utilizing structural typing enough. So e.g. writing some type and demanding a function accept it, when that function only actually needs one or two properties from it. Instead that function can inline or localize the part of the type it needs, and the original type can be unaware its ever being used by some other function.
And the other thing is trying to leverage the type system too much. For my style, if the types aren't making things easier to read, write, and maintain, they should be loosened and / or duplicated. I blame a lot of libraries here, it should never be puzzling to figure out how to type something so a function accepts it, yet that comes up quite often; I end up diving through these nested and overly DRY types trying to find what the heck even is this thing? That's crazy. If you need to cmd+click more than once or twice to understand what a type is, its way too abstracted.
Re: Switching to Elixir
#215Earlier quoted context omitted.
there's nothing stopping you from doing this but its a real game changer for an early stage startup to need a new service and the steps to getting that out is one file and an extra line in your config.
Don't choose Elixir if you just love setting up autoscaled k8s on AWS with redis, RabbitMQ and half a dozen shenanigans for a webapp that serves 10 users a day.
Elixir is my excuse for refusing to entertain the idea of an k8s cluster at work. Completely unnecessary.
Re: Switching to Elixir
#216Which companies have used Elixir in production, I know Brex used to use Elixir but now used Kotlin and also the Bleacher Report. Are there any more?
Based on the customer list of Oban.pro and knowledge from previous conferences there's also Nintendo (one of their online game stores uses it?), PepsiCo, Apple, Toyota...
Re: Switching to Elixir
#217Earlier quoted context omitted.
Meh. I don't want background jobs to be a breeze in quite this way. I want background work to live on different compute capacity than http requests, both because they have very different resources usage and because I want to have state or queues in front of background work so there's a well-defined process for retry, error handling, and back-pressure. I get it, of course, it'd be lovely if these complications didn't…
there's nothing stopping you from doing this but its a real game changer for an early stage startup to need a new service and the steps to getting that out is one file and an extra line in your config.
I've only used Elixir at small companies, and it definitely feels like a superpower. I don't doubt that the Googlers of the world have no need for the language and runtime, but IMHO it really helps a small company punch above its weight.
Re: Switching to Elixir
#218And still 0 successful startup has been built on top of elixir.
Why does a "startup" need to use it when giant companies already do? Nintendo, Apple, Toyota, PepsiCo...
Re: Switching to Elixir
#219Earlier quoted context omitted.
I’m a proponent of dynamic typing. I’d say the same thing. I don’t have enough working memory in my head to store the compile-time type information about every relevant variable, in addition to the actually important information about what the runtime data could be. The way that I write static-typed code is by imagining how I would write dynamic code to solve the problem, and then additionally imagining what types an…
> I don’t have enough working memory in my head to store the compile-time type information about every relevant variable Neither do I, but I know the compiler will check that for me so I don't need to hold all of that in working memory. I know my IDE will always be able to tell me the types too, and flag if anything is wrong immediately. The different points of view on this are really interesting.
In the end both approaches work well enough to keep companies in business. Companies fail not because of static or dynamic typing but because of marketing, internal fights, etc. The technical details are something that impacts very rarely.
Personally I worked in C for the first years of my career. Then the web happened and the two languages for it were Perl and Java. No more mallocs and frees, it was so great that I kind of forgot C. Then I was assigned to higher level tasks than programming and when I came back to it almost 10 years later I refreshed my Java (I kept doing Perl for my own stuff - CLI scripts and CGIs) and discovered Ruby on Rails. I realized that I could do the same web apps I was writing in Java with much less code and without having to lose my time after obvious but nearly useless details such as specifying that a given variable is a string, or number and how big, or an array of that class of objects indexed by strings (I intentionally use generic terms), etc. It's almost always clear what it is, especially if one picks good names for identifiers. There are some hiccups but not every year.
By the way, a great feature of Elixir is pattern matching in function definitions. In a pythonish pseudocode
def fib(0): 0
def fib(1): 1
def fib(n): fib(n-1) + fib(n-2)
I accept the argument that providing type information to a compiler lets it generate faster code. However none of my customers from the last 10 years care about that argument and they selected their technological stacks. Like everybody else they care about getting features done as quickly as possible. They all run their services on a single server, make enough money to pay themselves, their employees and a bunch of consultants like me.
Re: Switching to Elixir
#220Earlier quoted context omitted.
because of unification/pattern-matching you have a pretty good idea, just looking at function name + args what the shape of the data is going to be.
I'm building a static analyzer for Solidity in F# and the data shape of Solidity AST nodes overlaps frequently enough that explicitly specifying types is necessary just to get things to compile. I can't imagine building something like this in a dynamically typed language. The way I see it, static typing is like writing inline unit tests to save yourself many, many headaches later.
types aren't a substitute for tests.
let add : int -> int -> int = fun a b ->
Random.self_init ();
Random.int 100