91–100 of 138 posts
Earlier quoted context omitted.
What would be the difference between a "real vector" and a Map with numeric keys?
> What would be the difference between a "real vector" and a Map with numeric keys? Access in O(1) instead of O(nlogn).
The deal-breaker for me with Elixir has always been the lack of real Elixir vectors rather than the crappy Erlang array library. Yes, I know you can use a Map with numeric keys but that's not the same.
So what do you use real arrays for? For 80% of programming lists are just fine. Are you doing cpu-bound numerical calculations?
Earlier quoted context omitted.
> What would be the difference between a "real vector" and a Map with numeric keys? Access in O(1) instead of O(nlogn).
Data is immutable in Erlang. How do you know the runtime does not optimize Maps with numeric keys into arrays?
Earlier quoted context omitted.
I've done this multiple times. I will not make the mistake again. Next big system is being born in Elixir.
Well, give me a call if you need help. Just looking for work again lately.
Earlier quoted context omitted.
This is coming from someone who likes Elixir. Not much for its distributed systems features, but mostly because of the language design. I keep hearing everyone talk about how Erlang/Elixir gives everything out of the box and you don't need to worry about Queues, RPC or whatever... But in reality, people don't really recommend using Distributed Erlang that much, on most Elixir gigs I worked, they didn't use Distribute…
> I keep hearing everyone talk about how Erlang/Elixir gives everything out of the box and you don't need to worry about Queues, RPC or whatever... Many companies are using Distributed Erlang but not the way you described: they are using it to exchange messages between nodes running the same version of the software. Imagine that you are building a web application, you can directly exchange live messages between nodes…
Speaking of which, I'm looking forward to using Broadway [1] in a new project here in my company. Here, people are using an enterprise integration engine specialized in the healthcare space [2], with built-in single-branch version control and all actions going through the UI.
As I come from a background of several years with Ruby on Rails, I really hope to convince people to use this great library/framework your company created, since RoR is severely lacking when handling heavy concurrency like when gluing multiple APIs in complex workflows. Software engineers are going to love it, but integration analysts are used to IDEs with GUIs, so we'll need to create a pretty admin dashboard to convince them to switch.
[1] https://elixir-broadway.org/ [2] https://rhapsody.health/solutions/rhapsody/
Earlier quoted context omitted.
Yes exactly! This is super important for people new to elixir. The vast majority of the time, you don't even need to know that there is even any concurrency. You can write entire sophisticated Phoenix apps and never need it. But when you do eventually need it, it's there and it's wonderful, once you grok the pattern.
Agree. That's a big advantage of thread-based concurrency [0] vs async/await. The decision of whether to do things sequentially or concurrently sits with the caller, not the callee. Which means it's there where you need it and out of the way when you don't. With async/await, the decision is made by a function implementer somewhere down the stack, quite probably in 3rd party code. As the caller you get no choice becau…
Building on asynchronous sends also makes it conceptually the same to make a local request vs a request on a remote node, although with some additional failure conditions that don't usually make sense to worry about on a single node system.
Earlier quoted context omitted.
Hate to break it to you but in the BEAM you're always in an event loop.
No really. The scheduler isn’t really like an event loop. The scheduler will only allow a task so many units of execution before pulling it off the processing queue and scheduling other work. You can block an event loop, but not the scheduler.
Earlier quoted context omitted.
So what do you use real arrays for? For 80% of programming lists are just fine. Are you doing cpu-bound numerical calculations?
Same things arrays are used for in all mainstream languages ie. index-based access.
With a big caveat that modifying tuples isn't great for performance unless the compiler or optimizer determine that mutating the tuple is acceptable rather than providing a mutated copy.
Earlier quoted context omitted.
>those other ecosystems still need Kubernetes, Kafka, Redis and GRPC, to get by And what makes Elixir not need Kafka, Redis or GRPC? Instead of Redis, you could use ETS for caching. But once you have 2+ instances of your app, you will need to have a centralized caching mechanism, otherwise, each instance will have its own ETS with its own memory, not sharing anything. Unless you decide to use Distributed Erlang and c…
ETS is quite faster than using Redis though.
ETA: As another couple of comments pointed out, ETS also dies with the node so you've got to handle that also when rolling it.
ETS is cool, but its not a panacea.