111–120 of 139 posts
Earlier quoted context omitted.
+1 for distillery, very convenient... https://github.com/bitwalker/distillery
Once `mix release` was added natively to Elixir in 1.9, I haven't found the need to use distillery anymore. Is there still a use case?
Earlier quoted context omitted.
I have assumed BEAM has similar latency to Go and is garbage collected? Here is some benchmarks where Erlang beats Go in throughput: https://timyang.net/programming/c-erlang-java-performance/ https://stressgrid.com/blog/benchmarking_go_vs_node_vs_elixi...
That first link is from 2009. A lot's changed since then, so I didn't read it. And maybe I missed something in the second link, but Go showed very similar I/O performance to Elixir, while consuming a boatload less CPU doing it. That's what I'm after. Open to being told I missed something, though.
The Bean keep using CPU even with no work to be done, so avoid context changes. We can't compare about CPU values.
Earlier quoted context omitted.
> 1. Ecto is simply the best DB library I've encountered in any language. I'd almost recommend learning Elixir just to be able to use Ecto. It's interesting, people always talk about Phoenix, which is nice, but Ecto is really special. I often recommend it to anyone who is feeling burned by Active Record implementations.
I thought so too, at first, but now I'm really down on it. Ecto Changesets work fine for flat data, but when you have to deal with nested data, it becomes a nightmare, because you have to use these special functions to read and update the data. Doing that in a nested context just gets really clunky, especially coming from Clojure, where I would just do something trivial, like (assoc-in changeset [:children 1 :title]…
https://ekarak.com/2020/05/16/of-elixir-phoenix-and-analogie...
I learned Elixir a few weeks ago as a quarantine self-improvement project and pretty much loved it. There are some warts, as in any language. As someone who's primarily worked in Go and Java in the past and has also been learning Rust I don't super love the optional typing thing, and I end up missing higher-level data constructs like interfaces and traits. But there are some great language features, like guards and p…
> 1. Ecto is simply the best DB library I've encountered in any language. I'd almost recommend learning Elixir just to be able to use Ecto. It's interesting, people always talk about Phoenix, which is nice, but Ecto is really special. I often recommend it to anyone who is feeling burned by Active Record implementations.
I learned Elixir a few weeks ago as a quarantine self-improvement project and pretty much loved it. There are some warts, as in any language. As someone who's primarily worked in Go and Java in the past and has also been learning Rust I don't super love the optional typing thing, and I end up missing higher-level data constructs like interfaces and traits. But there are some great language features, like guards and p…
Interesting. I really like Python and SqlAlchemy. Changing objects in the database via changesets and applying them on top of eachother feels kinda alien, when I can't do object.property = something. The thing that confuses me most about Phoenix and Elixir is how do I actually deploy the application to production? I have my own server where I can run whatever I want (running Ubuntu), so what do I have to do to get my…
By the way how do you deploy Python code? There isn't a standard AFAIK.
Finally, check how systemd handles rabbitmq. It's an Erlang application and you could run and stop your application in the same way.
Earlier quoted context omitted.
That’s all true, but I think a Typescript-like system would work really well here. Typescript is very tolerant of the data being different than the type definition, and it doesn’t know or care if your data actually matches the type definition at runtime. It would be up to the developer to account for different versions of the data when writing out type definitions, and the worst case is that you try to access a prope…
I mean, that's already what Erlang/Elixir has, in the form of Dialyzer, a runtime "type linter" (which is what the typespecs in the article feed into.) It's static typing that Erlang can't complete-the-triangle on; not typing generally. The only problem is that "offline" type-checking like this does nothing to solve one of the main use-cases/pain-points where Erlangers want types (or, at least, think they want types)…
Yes. If only GenServer had an OOP syntax instead of a handle this / handle that list of functions which obfuscate what the process actually does. Elixir in particular lost a chance to make it easier to deal with.
Earlier quoted context omitted.
Yeah, it does have that stigma. It certainly did for me; "Why the hell are there colons before these variables..?" It's funny how much the first languages you learn (for lots of people, Java/C/JS) have such an impact on what "feels weird," when every programming language is basically magic anyway.
Well, Ruby and Julia and scheme, I think?) all have those same colons too, so it's not totally crazy. It's the post- colon that's strange (but Ruby has those too)
Earlier quoted context omitted.
I mean, that's already what Erlang/Elixir has, in the form of Dialyzer, a runtime "type linter" (which is what the typespecs in the article feed into.) It's static typing that Erlang can't complete-the-triangle on; not typing generally. The only problem is that "offline" type-checking like this does nothing to solve one of the main use-cases/pain-points where Erlangers want types (or, at least, think they want types)…
> A message is an OOP concept (and Erlang is an OOP language, where processes are the "objects.") Yes. If only GenServer had an OOP syntax instead of a handle this / handle that list of functions which obfuscate what the process actually does. Elixir in particular lost a chance to make it easier to deal with.
I will say one thing:. If you are thinking of BEAM processes as actors/(Kay objects), you're missing the real meat of what makes BEAM processes special; what they really are are atomic units of failure domains. The other stuff is just a useful analogy that lets people grok the code structure by comparing it to something familiar. The trouble then is that people will take habits from OO and apply them to BEAM where blindly copying the organizational form will lead to performance regressions. If you're treating BEAM processes like python or Java or Ruby objects, you're going to bottleneck your system and turn it into a needlessly complex mess.
In short, not all function calls (cheap) should be message passing (expensive). Sorry Alan Kay.
Earlier quoted context omitted.
That first link is from 2009. A lot's changed since then, so I didn't read it. And maybe I missed something in the second link, but Go showed very similar I/O performance to Elixir, while consuming a boatload less CPU doing it. That's what I'm after. Open to being told I missed something, though.
> Open to being told I missed something, though. The Bean keep using CPU even with no work to be done, so avoid context changes. We can't compare about CPU values.
Can you explain more why we can't compare? Looking at this chart...
https://stressgrid.com/blog/benchmarking_go_vs_node_vs_elixi...
...shows pretty clearly how the CPU utilization grows linearly (ignoring some sawtooth) as the load increases, plateaus once the load remains constant, and then comes down linearly as the load decreases on the other end. Looks like a very clear mapping between work done and CPU load to me.
