Earlier quoted context omitted.
I think it's less about the working style and more about the promise of working in the future(tm). When Rails 0.9 dropped in 2004, I instantly rewrote my old PHP app in it and never looked back. It just felt so expressive and naturally declarative. Rust has a similar amount of promise, though not quite as good of a demo. The idea that you can write high-performance code without typical high-performance code bugs is a…
> The idea that you can write high-performance code without > typical high-performance code bugs is amazing! There's a whole > new type of type system that ensures it! I just can't see how Rust is a good choice for web dev. There's a lot of mental overhead to writing Rust. Something like C#/Kotlin/Go will avoid all the same bugs and give you 95% of the performance while being much easier to code.
Moving on from Rails and What’s Next
51–60 of 88 posts
Re: Moving on from Rails and What’s Next
#52Earlier quoted context omitted.
Correct, they are for completely different purposes. I have the feeling that a lot of people (particularly the bloggers/more vocal types) jump into newer languages for no other reason than to position themselves as experts in said language/stack, right when it's getting more popular. I've seen this happen with Ruby/Rails, JavaScript/Node, and now Rust. In this case, it would have made a lot more sense to move to some…
I cut my teeth on Ruby and Rails, I've screwed around with Phoenix, and I'm currently infatuated with Rust. Earlier on I thought that, yeah, Rust is a great replacement for C and not something want to write a web app in. So, sure, I've got a bunch of little doodads written in Rust (mostly CLI tools). Now? The fluff I've written in Elixir is getting ported to Rust. The Rust tooling and community are just that good. I'…
There are mostly two ways to deploy Elixir. One is the provisioned approach: you install Erlang/Elixir (or you assume it is installed in the machine), then you fetch your project source code, fetch deps, compile them and run your project (in the same way you would run it locally).
The other approach is via releases. A release is a way to package the Erlang VM, Elixir and all of your application code into something you can dropped into production. The downside is that you need to match the target OS and architecture but there are many documented approaches to do so. Today the main tool for performing releases is Distillery and it has great documentation covering AWS, Docker, etc: https://hexdocs.pm/distillery/home.html
In Elixir v1.9, coming out this July, we are incorporating releases as part of the language. You can read more about it in our documentation for master: https://hexdocs.pm/mix/master/Mix.Tasks.Release.html
If you are using a PaaS such as Heroku, it is likely there is already tooling that will take care of it for you, such as the Heroku Elixir buildpack: https://github.com/HashNuke/heroku-buildpack-elixir. There is also Gigalixir, a PaaS specific to Erlang/Elixir: https://gigalixir.com/
Finally, if you want a more structured resource, there is also the Adopting Elixir book (disclaimer! I am one of the authors): https://pragprog.com/book/tvmelixir/adopting-elixir - One third of the book is about production concerns, covering deployment, performance, metrics, monitoring, etc.
If none of this works, you can always reach out to the community in elixirforum.com. I assure you there are more than 2 developers that know about deployment :) and if you still feel like none of the replies about deployment there have been satisfactory, feel free to add me to the conversation there.
> And you're definitely not going to write CLI tools in Elixir (it straight doesn't work with escript in the first place).
I do not understand this comment as Elixir works with escripts just fine. You can build an escript for your project by simply calling `mix escript.build`. This has been available since v1.0 (https://github.com/elixir-lang/elixir/blob/v1.0.0/lib/mix/li...). You can even install escripts directly from Hex (our package manager) since Elixir v1.4 (2.5 years old).
Re: Moving on from Rails and What’s Next
#53Earlier quoted context omitted.
I work on windows boxes all the time for go development it works great for that. Docker / Docker machine cause issues, and I can't use HyperV because I also have to be able to run android emulator. However every time I've looked at crystal I've stopped because there's no windows version. I have to have a gaming PC and I only use editors and languages that work on windows mac and linux so I don't hamstring myself or a…
>However every time I've looked at crystal I've stopped because there's no windows version. I have to have a gaming PC and I only use editors and languages that work on windows mac and linux so I don't hamstring myself or anyone I'm working with. I have a gaming PC too and I run my editor and browser etc... in windows, but I have a Linux server where the software I'm developing actually lives and runs (if it's someth…
Re: Moving on from Rails and What’s Next
#54Earlier quoted context omitted.
> The idea that you can write high-performance code without > typical high-performance code bugs is amazing! There's a whole > new type of type system that ensures it! I just can't see how Rust is a good choice for web dev. There's a lot of mental overhead to writing Rust. Something like C#/Kotlin/Go will avoid all the same bugs and give you 95% of the performance while being much easier to code.
Rust catches some more bugs than at least C# by having a more expressive type system (sum types), read-only being default, class/strict members always needing to be initialized.
.NET is a multi-language platform, with support out of the box for C#, F#, VB.NET, C++ and many others with MSIL backends.
Re: Moving on from Rails and What’s Next
#55Earlier quoted context omitted.
> The idea that you can write high-performance code without > typical high-performance code bugs is amazing! There's a whole > new type of type system that ensures it! I just can't see how Rust is a good choice for web dev. There's a lot of mental overhead to writing Rust. Something like C#/Kotlin/Go will avoid all the same bugs and give you 95% of the performance while being much easier to code.
I just can't see how Rust is a good choice for web dev. There's a lot of mental overhead to writing Rust. Something like C#/Kotlin/Go will avoid all the same bugs and give you 95% of the performance while being much easier to code. Rust is dramatically lower level than something like Ruby or Python. But sometimes the promise of really usable dependency and project management with something like Cargo wins out over th…
Re: Moving on from Rails and What’s Next
#56Earlier quoted context omitted.
Not sure when you were using Elixir, but releases are a good option for deployment now. This is supported with the distillery library ( https://hexdocs.pm/distillery/home.html ). The master version of Elixir also has support for releases https://hexdocs.pm/mix/master/Mix.Tasks.Release.html
Last I checked distillery was Linux only (e.g. does not work on BSD), which is a deal breaker for me. But I wouldn't consider using distillery (and thus Elixir/Phoenix) on any platform given the haphazard nature of the support for distillery. There's exactly one person who knows anything about it and he supports it when he doesn't have anything better to do. Sure, in a smaller shop you could dig into distillery and t…
The single point of failure is gone. The code is now maintained by the Elixir Core Team and it should garner more general attention from the community. The amount and complexity of scripts have been reduced drastically and they are statically verified to run on `sh` (no bash). As with everything else in Elixir, we do our best to keep the Erlang Elixir interface pretty clean. You should expect the same level of quality and polish as the remaining of the Elixir tooling.
I am not sure about this point though:
> Others like Ruby and Python can be moved around with standard system tools easily enough.
If you are not using releases, and simply Mix, is Elixir any harder to move around then Ruby and Python? From my understanding, using Mix to run Elixir in prod is a similar experience that both Ruby and Python would provide.
Re: Moving on from Rails and What’s Next
#57Earlier quoted context omitted.
I cut my teeth on Ruby and Rails, I've screwed around with Phoenix, and I'm currently infatuated with Rust. Earlier on I thought that, yeah, Rust is a great replacement for C and not something want to write a web app in. So, sure, I've got a bunch of little doodads written in Rust (mostly CLI tools). Now? The fluff I've written in Elixir is getting ported to Rust. The Rust tooling and community are just that good. I'…
I am sorry to hear that you had bad experiences while deploying Elixir. To avoid having others running into the same bad experiences, I would like to point out to some resources and recent improvements in the area for those interested in deploying Elixir. There are mostly two ways to deploy Elixir. One is the provisioned approach: you install Erlang/Elixir (or you assume it is installed in the machine), then you fetc…
I'm deploying to BSD, which distillery does not support. Perhaps there are other people who can grok deployments on Elixir, but none of them have seen fit to (or know how to) resolve these issues. I've seen scattered reports of success in the issues, bitwalker's attitude and general willful lack of engagement was enough to get me to move on from Elixir and not look back. By the time I gave up on Elixir, deployments on BSD had been known broken for months.
I'm used to hitting speed bumps by not deploying to Linux, but Elixir was by far the bumpiest road for the least benefit. For comparison the rust community has been extremely responsive to BSD users of all stripes (incl. dfbsd).
Re: Moving on from Rails and What’s Next
#58I would have thought rails to golang so I too am surprised. I wish I had millions and could be a patron saint of sorts for people like the author. Open source funding is so broken as the companies that build upon the vast open source and often free software don’t do much in the way of donating or otherwise supporting the companies or individuals behind the projects.
> Right now my goal is to get a handful of medium sized grants from larger companies to support my work on crates.io. If you work for a company that might be interested in helping sponsor me, please reach out.
If that's a financially viable proposition, that speaks well of large companies supporting individuals on open source projects, no?
Re: Moving on from Rails and What’s Next
#59Earlier quoted context omitted.
I am sorry to hear that you had bad experiences while deploying Elixir. To avoid having others running into the same bad experiences, I would like to point out to some resources and recent improvements in the area for those interested in deploying Elixir. There are mostly two ways to deploy Elixir. One is the provisioned approach: you install Erlang/Elixir (or you assume it is installed in the machine), then you fetc…
FWIW the last time I tried to use Elixir with escript was with 1.3. The parts that make Elixir interesting for web apps aren't necessarily things you'd be leveraging in scripts and so, unfortunately, instead of waiting around for Elixir to do the things I was interested in I've moved on. There just aren't any killer features in Elixir that would revisit it. If I need lightweight concurrency primitives there's go. If…
Interesting, escripts should have worked by then. I assume this was quite some time ago, so you don't have it around anymore, but if you do recall what went wrong I would love to take a look at it. But just to put things in perspective, v1.3 is almost three years old and things have generally evolved since.
> There just aren't any killer features in Elixir that would revisit it.
Well, sometimes the killer feature is having all of that in the same package: immutability, concurrent primitives, scripts, etc.
There are also killer features (although I guess "killer" will depend on the person) that we get from running on the Erlang VM: focus on fault-tolerance and supervisors, concurrency and distribution out-of-the-box, and generally other features coming from processes and the actor model. For example, Phoenix makes an excellent use of all those features to build performant web applications with a focus on real time (Phoenix LiveView being a recent great example). Nerves uses the fault tolerance bits for building embedded software. Etc.
Re: Moving on from Rails and What’s Next
#60Earlier quoted context omitted.
Last I checked distillery was Linux only (e.g. does not work on BSD), which is a deal breaker for me. But I wouldn't consider using distillery (and thus Elixir/Phoenix) on any platform given the haphazard nature of the support for distillery. There's exactly one person who knows anything about it and he supports it when he doesn't have anything better to do. Sure, in a smaller shop you could dig into distillery and t…
If those are your concerns, then the fact we are adding releases to Elixir core in the upcoming version should solve most of them. The single point of failure is gone. The code is now maintained by the Elixir Core Team and it should garner more general attention from the community. The amount and complexity of scripts have been reduced drastically and they are statically verified to run on `sh` (no bash). As with eve…
I've articulated my experience in my previous reply to you, but I'll pose this response: that it's taken so long for Elixir to come up with a manageable deployment story makes it seem like deployments are an afterthought with Elixir. If things are better now that's great, but as an ops guy by trade I think that deployments are one of the most important user stories out there.
I suspect one of the reasons people are gravitating towards Rust for things it's not particularly well suited for (like web apps with a ton of business logic) is that the Rust team focuses on important user stories like:
- tooling (human readable error messages, dependency management, portability)
- deployments
- IDE user experience
These are things that Elixir and Phoenix aren't focused on. For example I still get the occasional email from github about the poor souls trying to use distillery on FreeBSD so I don't buy that things have improved that much.