111–120 of 246 posts
- Pipelines are hard to debug. You can’t just throw a debugger just before the line with the issue.
- Phoenix is very bad at serving static files. It was a nightmare to import a new CSS template requiring to convert everything to work with bower first, or dump the files in the /priv directory to make it work.
Elixir is a niche (that's the truth). Also in the article it is written 'Relatively difficult to "recruit" developers with existing experience in Elixir'. Why would a SW company invest in niche languages where the resources (software developers) are really expensive and really hard to get? Technologically it's all great but economically that's a nightmare.
The difference is, in Ruby, after 2-3 months, you'll be rewriting large portions of what you did to get there. And in another year or two, you'll find yourself being blocked by earlier designs not for a day or two, but by a month of work or better.
In Elixir, you simply will not experience that. Even if written poorly, it's easy to rework/change, and you probably won't need to anyway because it's just easier to get things done without painting yourself into a corner.
Was very excited by Exilir coming from Ruby, however found 2 issues that made it hard to work with: - Pipelines are hard to debug. You can’t just throw a debugger just before the line with the issue. - Phoenix is very bad at serving static files. It was a nightmare to import a new CSS template requiring to convert everything to work with bower first, or dump the files in the /priv directory to make it work.
Then debugging a pipeline is as simple as dropping in IO.inspect between statements as it returns the content as well as printing.
thing
|> stage1
|> IO.inspect
|> stage2
Elixir is a niche (that's the truth). Also in the article it is written 'Relatively difficult to "recruit" developers with existing experience in Elixir'. Why would a SW company invest in niche languages where the resources (software developers) are really expensive and really hard to get? Technologically it's all great but economically that's a nightmare.
See http://www.paulgraham.com/avg.html for one answer.
Was very excited by Exilir coming from Ruby, however found 2 issues that made it hard to work with: - Pipelines are hard to debug. You can’t just throw a debugger just before the line with the issue. - Phoenix is very bad at serving static files. It was a nightmare to import a new CSS template requiring to convert everything to work with bower first, or dump the files in the /priv directory to make it work.
You absolutely can. Just change,
```elixir
users
|> send_email_with_money()
|> do_complex_thing_that_crashes()
```
into
```elixir
users = users
|> send_email_with_money()
```
I turned the `require IEx; IEx.pry()` into a snippet just to make life as easy as it is in Ruby land.
> - Phoenix is very bad at serving static files. It was a nightmare to import a new CSS template requiring to convert everything to work with bower first, or dump the files in the /priv directory to make it work.
Well, two sides to this. For one, Phoenix uses Webpack now(since finally the war to see what app bundler would win is over).
But even when you did use bower- you should've been able to just delete `phoenix.css`, copy your template in, and in `app.css` put `import "template_name_here"`.
Earlier quoted context omitted.
> If you need multi core and distributed features (which is generally more common than you think) elixir is truly your friend. Is it though? At least in my line of work I don't think I've ever run into this. I feel like I've always been able to distribute just fine with workers/queues. If I even suspected it would I'd look into it more, but generally I find distributing across systems to be a software architecture-le…
Until I used Elixir, I thought workers/queues were enough. But after the last nearly-three-years, I've actually fallen into a place where workers/queues are almost always strictly inferior. Workers/queues in languages like Ruby have problems like, * 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) * They require a se…
With kubernetes you have an endpoint per service that route and load balance to the correct machine.
It seem to me you already got all the benefits from using actor but with less lock-in to a language.
This post is killing me. I’ve been really really loving Elixir and for a while was fighting the “everything looks like a nail” syndrome once I learned it. But now I have a contract that would really benefit from the runtime. That being said the existing environment has a lot of python expertise and I don’t have enough production Elixir experience to have confidence in myself to deliver something of the right caliber.…
Earlier quoted context omitted.
Until I used Elixir, I thought workers/queues were enough. But after the last nearly-three-years, I've actually fallen into a place where workers/queues are almost always strictly inferior. Workers/queues in languages like Ruby have problems like, * 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) * They require a se…
If you need a request/response model (ex: query some data) and not simply queue an operation to execute later without waiting for it. I agree (worker/queue) are the wrong solution. But you should use a multi-language RPC framework like GRPC instead of building a distributed monolith. With kubernetes you have an endpoint per service that route and load balance to the correct machine. It seem to me you already got all…
Not to mention, microservices are not always the answer. And even if they were, they're still an insane amount of more work than literally changing what functions you call.
I'm not saying you should never use an RPC, but I've significantly reduced the times I'd want to use one. The only reason I even advocate for one now, is because I prefer to empower developers to use whatever language makes them happy, even if I personally greatly prefer Elixir.