[zerkten]

> I've been slowly working on a backend for a web app in Rust

I'm interested in why you made the choice to use Rust for a web app? It feels like you love a good challenge, but there are obviously technical constraints for some apps. I look around and wonder if the options have really changed a whole lot since 2006?

If you need productivity, choose Ruby or Python (or maybe JS.) Java and .NET exist if you have more exacting performance requirements (these platforms are somewhat more pleasant in 2019 and I see Go as joining their ranks.) Or, you choose to go really low-level with C/C++, or perhaps Rust in 2019. The latter never seemed like a viable option unless you had extreme performance concerns.

[faizshah]

Or if you need both, Yehuda Katz's company Tilde made a library that can help you write code in Rust and use it in Ruby. So if there's a critical path in Rails that you need to speed up in Rust you can do that: https://www.youtube.com/watch?v=lBapt5YDDvg https://github.com/tildeio/helix

[AlchemistCamp]

Or if you want productivity and a performant web server, try Elixir + Phoenix.

Number crunching still has to be dished off to something else like C, Rust or Go, though.

[pmontra]

I'm working on three projects for three customers right now. Phoenix, Django and Rails. From my personal experience:

1) Elixir + Phoenix have some definite advantages when spawning asynchronous tasks (no external dependencies, it's in the language) and it runs reasonably quick.

2) Coding in Ruby on Rails is faster. An example, it's much easier to write queries in ActiveRecord than in Ecto, which is over engineered for the common needs of a web app. Queries, updates, transactions, everything are productivity killers there. For 99.9...% of the web apps it will be fast enough and the CPU will sit idle most of the time.

3) Django is as bad as Rails for concurrency and performances. The ORM is more verbose than ActiveRecord but luckily it's much closer to AR than to Ecto. The project structure is very loose compared to both Rails and Phoenix, which is bad for onboarding people coming from other Django projects ("ah, you put that there, why?")

My suggestions. If you know you're going to build a big application, scale it, etc, use Phoenix. Small to medium size: use Rails unless you're already a Python shop. In that case use Django. Smaller frameworks like Sinatra or Flask: it's not worth using them with the exception of very small applications that won't grow bigger. If they do you'll start adding components and turn them into an homegrown nightmare resembling the more polished Rails and Django.

[AlchemistCamp]

How much experience do you have with each of the three? Like many, I moved to Elixir + Phoenix from Rails and having a considerable amount of experience with Node.

I've found Ecto to be a productivity boon once I understood it, except for very small projects. For those, I reach for Rails just as you suggested.

My real productivity boost with Phoenix is that Elixir (or the Erlang VM, to be accurate) can take care of so many things I'd be dishing off to Redis, Sidekiq or other tools in a Rails app. That and the lack of surprises from metaprogramming or ActiveRecord default behaviors I haven't kept in mind while building.

[munmaek]

That's been my experience with sinatra and padrino as well.

The promise of a lean app with rails' ecosystem is too good to be true, and it is. It's so much easier to just start with rails from the beginning instead of slowly adding things piecemeal.

I still like sinatra and flask but they have one purpose: very very simple webapis, that's it. Nothing even remotely as complex as user sessions or forms.

I've been playing with Pheonix/Elixir here and there but I've never sat down and written a full app in it. I guess that's the future ultimately, at least for larger companies that need that performance.

[bjz_]

The lack of a type system in Elixir is a productivity killer though :(

[Dangeranger]

You can annotate your types if you want and get a lot of editor benefits. Also, I don’t buy the “we need strong types for everything” argument, as optional typing in Clojure, JavaScript, and now Ruby gives you lots of benefits without having to think all the way through the app’s architecture.

[chessturk]

Can you give me an example of this? I'm genuinely wondering if I've just dodged a pain point so far.

My other strongest languages are Golang and JavaScript, so I'm used to (duck-)typed and untyped approaches, and I've never felt that Elixir was difficult to work with because of the lack of types. I've treated pattern-matching like type inference, and as long as you have guard clauses, the worst that can happen is a runtime error which you "let fail" anyway.

I guess the guard clauses are a bit of boilerplate, but I feel like these complaints have a different root. I just don't see it yet.

[strzibny]

I think combination of type annotations and pattern matching actually works pretty well. Yes, it's not Rust though:)

[simplify]

Agreed. If Elixir had static typing then Phoenix would be my dream framework!

[girishso]

There’s no type system in Ruby too!

[munmaek]

I just like using Rust. This is a small side project of mine so it's been more fun to experiment with using Rust to make a backend api than to stick with rails.

I also recently dealt with maintaining / upgrading a large, not well architected rails app. Debugging mysterious issues in Rails (and asp.net webapi2) sucks compared to Rust.

For a professional project I would largely go with rails, depending on the situation. asp.net isn't bad either.

[geowwy]

Ruby and Python aren’t any more productive than C# or Java in my opinion. Especially when you consider the errors static typing helps you avoid.

[munmaek]

I would say the productivity comes from the established community around Ruby, when it comes to web development.

It's true that you end up running into certain types of bugs that a strongly typed language would've caught immediately, but in java/c#/rust you end up having to hand implement more stuff depending on what you're doing.

Ideally I would use rust, but I also think Ruby can work quite well if defensive programming practices are followed, as well as running linters, static analyzers, etc. Most issues seem to stem from poor architecture or tightly coupled, dense code.