231–240 of 246 posts
I’ve been programming in elixir for about 2 years now. I have to say it’s hard to go back to something like Ruby or JavaScript. In elixir you really get the full power of multi core and support for distributed computing out of the box. Code that would have been beyond my pay grade or wouldn’t even imagine to write in Ruby or JavaScript is now easily reasoned about and maintained in projects. I can write succinct code…
Earlier quoted context omitted.
The fact that it's dynamically typed is also often overlooked, while it's at the top of my deal breaker list. The programming world is strongly moving toward statically typed languages, because today, there's pretty much zero reasons to use a dynamically typed language.
Static typing incurs restrictive boilerplate while only eliminating a small subset of all possible bugs. I will admit the guarantees it gives you are nice but I’d argue that the guarantees immutability-all-the-way-down gets you in a language like Elixir are stronger. You don’t get those guarantees on ANY of the statically-typed languages that run on the JVM because as soon as you interop with anything Java, bye-bye g…
Wrong, type inference has been aa thing for decades.
Earlier quoted context omitted.
Workers and queues fail. SQS was down for us for almost two weeks while AWS fixed a bug. We had no choice but to wait or rewrite our implementation... Again! We've already had to rewrite once due to poor visibility and rare occasional problems processing data. Debugging such distributed systems is legendary hell. And that's just for simple async processing so that we can return a response quickly to the user and fini…
I am sorry but I disagree. You are trying to make it sound that your cloud provider downtime has something to do how you manage your workload in your code. Debugging __any__ distributed system is difficult, this is why monitoring and tracing should be first class citizens in your deployments. It seems they are not for you.
Earlier quoted context omitted.
I assume perf comment is in relation to AWS Lambda, for which the Elixir example they've put up is severely below par perf wise
I am talking about raw HTTP request handling performance. Elixir/Cowboy/Plug is in the middle range of web servers. Again, it is good enough for most use cases.
Earlier quoted context omitted.
I agree and believe that it's harder to maintain a dynamically-typed codebase, but Elixir has a well-thought-out gradual typing solution: typespecs ( https://hexdocs.pm/elixir/typespecs.html#basic-types ). This builds on Erlang's Dialyzer tool and is supported by editor plugins like VSCode's ElixirLS extension. In practice, you do get instant typechecking while you code, if you write down the typespecs properly.
Purely anecdotal: our experience with Dialixir was rather disapointing (slow, lots of false positive, hard to express types coming from external libraries and generated code.) Unfortunately, the tradeoff at the time made us stop using specs altogether.
Has anyone had experience of both Elixir and F#? I've dabbled with both - but really fell in love with both of them! I come from a C# background, so the static typing of F# is a big pull. OTOH, the simplicity of Elixir was an absolute delight - after just an afternoon, I felt like I had a decent grasp of it. I'm conflicted, and would value some other opinions?
I love Erlang's OTP, but I would never go back to a dynamically typed language. Most of my current work is in Go, which is a fairly strict language, and I value perhaps more than anything the ability to verify my program at compile time -- for one, I can do large-scale refactoringest, safe in the knowledge that my program won't run until everything is again sound. Go still leaves a lot to be desired, so I've been exp…
Mind elaborating? F# seems like a decent fit from what you've said. I'm hoping the language will grow less stagnant as .NET Core matures.
I love Erlang's OTP, but I would never go back to a dynamically typed language. Most of my current work is in Go, which is a fairly strict language, and I value perhaps more than anything the ability to verify my program at compile time -- for one, I can do large-scale refactoringest, safe in the knowledge that my program won't run until everything is again sound. Go still leaves a lot to be desired, so I've been exp…
> I looked at F# for a bit, too, but it comes across as having too much .NET/Microsoft flavour for me. Mind elaborating? F# seems like a decent fit from what you've said. I'm hoping the language will grow less stagnant as .NET Core matures.
However, it comes with the baggage of .NET Core, which is a rather big thing. And it's growing, as Microsoft is apparently porting over everything from the older, non-cross-platform .NET stuff. For one, .NET Core includes the CLR/CIL, i.e. the JIT VM and cross-language integration, which I'm not interested in at all; I just want an AOT compiler. The AOT support seems like a fairly recent addition, and it's unclear to me how optimized it is or how well-supported it is compared to the older CLR-based toolchain. As a standard library, CoreFX seems rather large, and contains things like GUI and SQL Server support, for some reason.
In short, .NET Core seems like something you'd love only if you were already heavily invested in Microsoft's tech stack. I'm not interested in it myself.
Earlier quoted context omitted.
Erlang/Elixir has some really great advantages in concurrency and parallelism but what you're describing are just badly designed systems. Shopify, for example, use Resque (Ruby + Redis) to process thousands of background jobs per second. > * Require very specific ergonomics(for example, don't hand the model over, hand over the ID so you can pull over the freshest version and not overwrite) This is good practice but c…
> This is good practice but certainly not a requirement. You can pass objects in a serialized format like JSON or use Protobuf etc. ie, requiring very specific ergonomics. If you have to change what you're doing, it's a new domain to learn. > ETS and Mnesia aren't production ready job queues, unfortunately: https://news.ycombinator.com/item?id=9828608 I didn't mention ETS or Mnesia? The OP was talking specifically ab…
Resque & Sidekiq build this in by converting job arguments to JSON. There's nothing extra to learn.
> I didn't mention ETS or Mnesia? The OP was talking specifically about using job queues to get concurrency/parallelism, in which case you absolutely don't need job queues. If you need a job queue, you need a job queue.
Sorry, I thought you were talking about building a background job system in Erlang using out of the box OTP but it sounds like you're actually talking about trying to get parallelism in Ruby by doing RPC over Sidekiq? That's always a bad idea!
> Redis queues have millisecond latency, Ruby using Redis queues does not. That's the part that polls when there's nothing else going on. If you're never running out of jobs to do then your latency is fast, but you're also not accomplishing things as fast as possible(since it's waiting on whatever is in front of it).
Ahhh! When Mike Perham says "Sidekiq Pro cannot reliably handle multiple queues without polling" what this really means is a Redis client can only block on and immediately process from the highest priority queue. The lower priority queues are only checked when blocking timeout expires. There's no "check all queues and sleep" polling loop which adds artificial latency.
> And are incredibly difficult to use and pass information back and forth(hence why Elixir exists at all- Jose Valim was the person implementing this on the Rails core team).
Jose Valim didn't join Rails core until a couple years after Josh Peek (now working for GitHub) made Rails thread-safe.
> And are incredibly difficult to use and pass information back and forth(hence why Elixir exists at all- Jose Valim was the person implementing this on the Rails core team).
It's really not that hard anymore!
results = ['url1','url2'].parallel_map{|url| HTTParty.get(url) }
2012-2013 onwards Ruby got great libraries like concurrent-ruby and parallel that make things a lot easier.
> Which Ruby has a lot of trouble maintaining performantly. When my original team went to use Rails5 sockets, we found we could barely support 50 sockets per machine.
ActionCable is designed for convenience not performance. https://github.com/websocket-rails/websocket-rails will handle thousands of connections per process.