Sees post recommends https://nerves-project.org for IoT
Clicks thru
Sees that Nerves is an excellent platform for IoT and only requires a base of 12MB and Linux.
Quickly backs away.
Would you still pick Elixir in 2019?
171–180 of 246 posts
Re: Would you still pick Elixir in 2019?
#172Earlier quoted context omitted.
> nobody is forced to use new libraries only because they use JavaScript. It's not completely true IMO for 2 reasons: 1- the nodejs standard lib is quite poor compared to say, Java's, Scala's or python's, so you generally need quite a lot of modules to do anything 2- the npm ecosystem is much more amateur. To do anything you have a ton of poorly supported by hobbyists or not supported at all modules. This can force y…
Yeah but on Node.js, Express has been the de facto framework of choice for building REST APIs for over 6 years. The JS fatigue phenomenon was mostly on the front end, and even that has basically settled down as people have rallied around React, Angular and Vue.
Not for our customers that keep happily using solutions based on Java and .NET platforms.
Re: Would you still pick Elixir in 2019?
#173Elixir has great things "of his own": * the syntax is well though-of (`with`, destructuring, `|>` are powerful * message passing has great use-cases And then it has problems that are not necessarily "elixir-y", but are there nonetheless: * it's hard to model an application around the Actor model. It's very easy to abuse it. * it's hard to maintain / refactor a large application without help from the compiler before r…
`|>` comes from F#.
Re: Would you still pick Elixir in 2019?
#174Question : How does OTP work together with things like kubernetes in the real world ? Designing around actors with OTP spawning and respawning part of the actor tree, while at the same time provisionning / deprovisionning VMs if load is going up or down, sounds like either a dream if it works well, or a nightmare if there's just a single glitch somewhere.
Best question in this thread and I am looking fwd to an answer. I guess that just very few mastered Elixir and k8s.
Re: Would you still pick Elixir in 2019?
#175Earlier quoted context omitted.
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…
That's even more work? Most developers already have redis/Postgres running, the issue there is the added complexity in complex operations. 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. Th…
> Most developers already have redis/Postgres running
You are joking right? You mean web developers?
Re: Would you still pick Elixir in 2019?
#176Earlier 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…
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.
Re: Would you still pick Elixir in 2019?
#177This went past me as the post is filled with a lot of claims with no reasoning to back those up. It is not a critical evaluation of the language, but rather sounds like a "fanboy" piece, for the lack of a better term. > Memory efficiency is much better than most other languages (with the exception of Rust, but Elixir is miles better at Error handling than Rust, which is a more practical feature IMO How exactly are ar…
I am not sure I would say one is better than the other, but they are very different.
As you said, in Rust you are forced to handle errors by the compiler. In Elixir, you actually don't. In fact, we even encourage you to [write assertive code](http://blog.plataformatec.com.br/2014/09/writing-assertive-c...). This is also commonly referred as "let it crash". In a nutshell, if there is an unexpected scenario in your code, you let it crash and let that part of the system restart itself.
This works because we write code in tiny isolated processes, in a way that, if one of those processes crash, they won't affect other parts of the system. This means you are encouraged to crash and let supervisors restart the failed processes back. I have written more about this in another comment: https://news.ycombinator.com/item?id=18840401
I also think looking at Erlang's history can be really interesting and educational. The Erlang VM was designed to build concurrent, distributed, fault-tolerant systems. When designing the system, the only certainty is that there would be failures (hello network!) so instead trying to catch all failures upfront, they decided to focus on a system that can self-heal.
I personally think that Erlang and Elixir could benefit from static types. However, this is much easier said than done. The systems built with those languages tend to be very dynamic, by even providing things such as hot code swapping, and only somewhat recently we have started to really explore the concepts required to type processes. But a more humble type system could start with the functional parts of the language, especially because I think that other techniques of model checking can be more interesting than type systems for the process part.
Re: Would you still pick Elixir in 2019?
#178I've been working with Elixir in a single-developer production system for over a year now. I'm running it in Docker containers on Kubernetes, in the cloud. It has been extremely stable, scaling has been a non-issue. Error reporting has become easier and easier, now that companies like Sentry and AppSignal have integrations for Elixir. Elixir is VERY fault-tolerant. DB connection crashing? Ah well, reconnects immediat…
> Elixir is VERY fault-tolerant. DB connection crashing? Ah well, reconnects immediately, while still serving the static parts of the application. PDF generation wonky? Same thing. I still don't understand this. I don't think I've ever built a web server in any language where this wasn't true unless I specifically wanted hard failure. The amount of fault tolerance would be a per-app design goal rather than something…
You are probably in the top 10% of software engineers. It is definitely the case with the rest of them to not to handle database connections, use single threads to talk to the network and than blame the performance on network engineers and I could go on and on. These are work experiences btw., I did not make it up. I would be super happy if all of the software engineers out there would not have such silly assumptions about how computers and networks operate.
Re: Would you still pick Elixir in 2019?
#179Earlier quoted context omitted.
It's less about how it handles exceptions but rather how the BEAM makes sure that things that break don't crash the whole system. The magic is in the supervisor pattern, explained here for erlang: http://erlang.org/documentation/doc-4.9.1/doc/design_princip... It is hard to describe why this "feels different" in Elixir than it does in Express.js or a Tomcat running a Java application. It's all experiential for me, bu…
But with Kubernetes what's the point of BEAM?
Not sure what you mean. Kubernetes is a containerisation and orchestration platform BEAM is a VM for Erlang. How would they be comparable? Or is this a different BEAM?
Re: Would you still pick Elixir in 2019?
#180Earlier quoted context omitted.
Both of these points are False, point 2 I’ve been integrating a bootstrap framework and sass and it’s super simple; I put the files in assets, add npm install —save sass and that’s it! 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 Not that difficult!
> I put the files in assets, add npm install —save sass and that’s it! It takes forever if your assets are large. Just serving random static files shouldn't take long. > IO.inspect It's nothing like a real debugger.
I’ve not found this, are you on windows?
Inspect is fine as in Elixir you don’t have any hidden state. Use the :debugger if you need more than this.