121–130 of 216 posts
Earlier quoted context omitted.
How?
If you push to keep your code organized into modules with simple function APIs, and make sure that code outside your modules doesn't use the package internals directly, then your function APIs can be easily extracted into a REST/gRPC call, and the only thing that changes (to the first approximation) is your internal service (function) calls become external service (api) calls. Obviously you now need to add an API cli…
Earlier quoted context omitted.
> 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 exa…
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.
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.
I think I'd only ever choose RoR for a throwaway project, in 2019. I do love RoR and the development experience but Elixir and Phoenix give me almost exactly the same feeling but with WAY better performance and an Immutable/Functional language that results in much cleaner and better code. It's an investment to learn Elixir but it's 100% worth it and honestly I'd choose Phoenix over Rails almost every time.
What is your IDE setup? I like elixir, but it seems that IDE support isn't where I'm used to in other languages. Specifically module auto imports/aliasing. Not a big gripe, but I haven't found an IDE I like as much as Rubymine for Elixir.
I love Ruby/Rails and owe my career to it, but I don't see the advantage of choosing this stack in 2019 over Elixir/Phoenix for greenfield projects. Elixir tooling and libraries are now up to par and I'd argue have surpassed RoR. At this point, it's just as productive (perhaps even more as you don't have to glue on a bunch of additional components) and joyful to work with like RoR but massively scalable out of the bo…
1. You can find a RoR developer.
Earlier quoted context omitted.
As a counterpoint, I love ActiveRecord. It's a Swiss Army knife that's got pretty much everything you need, you just need to find the right tool and use it. What ActiveRecord isn't is discoverable . Which is to an extent understandable. Its domain is literally anything you could express in SQL. But you really can do anything you want with it, you just have to find the right abstraction. A tool I use a lot is to .to_s…
Long ago I liked ActiveRecord(AR), then I worked at a company that did large aggregations in SQL and found it to be severely limited in working with complex queries which use many JOIN statement and sub-queries. During that time I came to enjoy working with the Sequel[0] gem, and its fantastic documentation. Now, after working with Ecto[1] in Elixir, I've found that the ROM[2] builder pattern is a better approach to…
I've used sequel before and agree, it's closer to the SQL and does the job well. ROM looks excellent. I'm just reading down the page you linked, and I love every word. I can say I've had all of these problems with ActiveRecord, and ROM's answers to them all look great!
I can't put my finger on it, but Django just feels intuitive to me and Rails just feels strange. Maybe it is the convention over configuration mindset which results in lots of magic, but I just can't get comfortable using Rails.
I love the idea of Rails and it's community, but I don't think it will ever be the tool for me.
And as a Django + Python lover, I feel the need to refute the idea (not just in this article) that it is mainly for academic/scientific purposes. Python is a great general purpose language which can do just about anything. It's not the best tool for every job, but for the generalist, it is wonderful. And Django is incredibly solid and can build an MVP in no time. And maybe I'm just a bad developer, but I don't see how the extra configuration necessary when using Django vs Rails is going to add up to much time at all when building your MVP. Is a couple of extra hours really going to make a difference?
I love Ruby/Rails and owe my career to it, but I don't see the advantage of choosing this stack in 2019 over Elixir/Phoenix for greenfield projects. Elixir tooling and libraries are now up to par and I'd argue have surpassed RoR. At this point, it's just as productive (perhaps even more as you don't have to glue on a bunch of additional components) and joyful to work with like RoR but massively scalable out of the bo…
1. You can find a RoR developer.
Earlier quoted context omitted.
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.
The lack of a type system in Elixir is a productivity killer though :(
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.
I love Ruby/Rails and owe my career to it, but I don't see the advantage of choosing this stack in 2019 over Elixir/Phoenix for greenfield projects. Elixir tooling and libraries are now up to par and I'd argue have surpassed RoR. At this point, it's just as productive (perhaps even more as you don't have to glue on a bunch of additional components) and joyful to work with like RoR but massively scalable out of the bo…
Among my peers (undergrads in college) Rails has largely lost mindshare to python and Node (and even PHP!). At the 3 hackathons I went to this semester I could not find a single other person who knew Rails (so I always have to switch to node or python). If you take a look at devpost, Rails is increasingly losing popularity: https://devpost.com/software/built-with/ruby-on-rails My plea to the Rails community and Rails…
> I've seriously seen people who have difficulty understanding a for loop that know how to use react at a basic level. Is that really what you want? That sounds like a ticket for short-term gains and long-term pains.