221–230 of 277 posts
Earlier quoted context omitted.
Python has far more custom syntax than Ruby. In Ruby an elegant syntax like blocks solves many problems, in Python each problem has custom syntax.
Quick, which language is this written in? a = [1,2,3,4] for b in a print(b) end
But you would write `[1, 2, 3, 4].each { |n| print(n) }`
Earlier quoted context omitted.
Quick, which language is this written in? a = [1,2,3,4] for b in a print(b) end
Here's some advice. If you want to make a point, make it clear and direct. No one knows what point you are trying to make here.
Looks good. There's a new IRB, the interactive Ruby interpreter, with better autocompletion and debugging. Most of the Ruby 3.3 changes will lead to improved developer tooling. The language API is largely unchanged and consistent with previous releases. I wrote a guide [1] for the update to Ruby 3.3, with notes for each of the various version managers. [1] https://mac.install.guide/ruby/update.html Just curious, whic…
Earlier quoted context omitted.
Hi-tech are cyclical. Ruby got nothing else bigger than Rails unfortunately no matter how people in that community is hyping Ruby out. It's okay if Ruby and Rails on a downward trend it might pick up again in the future. C'mon now, we all know that our industry is like a Fashion industry. The only reason why Rails is making a comeback is because we're in tough time: no more VC money to hire tons of Engineers to build…
Correct. But now there is another complication to an eventual reemergence of ruby on rails: the competition defeated the initial comparative advantage - i.e. the simplicity - of the RoR platform. The premises that justified RoR in the past are too weak today in my opinion. The framework was sold on how easy and no-nosense it was setting it up and start prototyping your commercial solution in a time where the competit…
Looking at the Spring Boot guides, the amount of setup, complexity and lines of code just to get an application running with MySQL doesn't support this statement: https://spring.io/guides/gs/accessing-data-mysql/ Even 20 years ago this would be easier in Rails.
Or try building the blog demo that's build on the Rails homepage video in Spring Boot. 35 minutes to build a blog with rich text (including image uploads), live comments, notification mails and tests. And after changing the database to PostgreSQL, deploy it to production. https://rubyonrails.org/
Earlier quoted context omitted.
One of the biggest breaking changes that EF Core did was to explicitly disallow such generated queries that required application-side evaluation and could not get compiled to pure SQL (you can get other behavior back with a toggle but it is discouraged). I strongly believe it is wrong to do otherwise and is a source of numerous footguns unless you invest in tracking them down.
I will admit I'm behind the state of the art with EF, but I switched to dapper in the early days of dotnet core and never looked back. It gets out of my way so I can properly utilize postgres' advanced features like jsonb while cutting out a lot of the boilerplate associated with hand-rolled queries.
As for EF Core - it very good as of today (has it ever been bad?). You can transparently compose your queries with `context.FromSql(...).SingleAsync()` which will use string interpolation API to consume your plain $"SELECT * FROM {myTable} ..." and make it injection-safe and transform passed arguments as appropriate. It's quite handy.
Earlier quoted context omitted.
Nah. One rust based server can power the same number of connections as 10-100 ruby based servers. This is not just “pretend database IO” problem. This is actual cost that no business should accept on the basis of “but but but database IO (that I’ve never actually measured, but it’s an easy cop out because I read it on medium once).
But you factored-out developer productivity. What you gain in reduced server costs is lost many times over in developer productivity. Companies who chose Rails for decades knew it was slower and more memory-hungry than rolling everything yourself in Rust or C++. They did the math and the business case for Rails was more compelling.
Let's not act like everyone who tries Rust gives up. OK? Sure it's definitely more difficult but people are learning and practicing and the pool is slowly expanding (me included, though I am not at production-grade experience yet).
> What you gain in reduced server costs is lost many times over in developer productivity.
Are you exaggerating for dramatic effect? I'd say depending on your people's seniority the productivity loss is anywhere from -50% to -500%, which is hardly "many times over".
You absolutely do iterate slower with Rust writing web backends -- no two ways about it. But you also (a) exaggerate the multiplier and (b) underestimate the long-tail of gained productivity that a language like Rust brings to the table (strong static typing et. al.)
And even if we take into account your comparison between server costs and programmer productivity -- there are areas where correctness and speed are more important than Joe and Susan being able to crank out 17 CRUD endpoints this week. I feel that this nuance is often ignored.
> Companies who chose Rails for decades knew it was slower and more memory-hungry than rolling everything yourself in Rust or C++.
I have worked with Rails for 6.5 years and they knew no such thing. They treated server costs exactly like they treated programmers -- a necessary evil, a cost center that (currently) cannot be optimized away.
I am consistently blown away by the protected and downright pampering environments that some HN people have lived in. It's pretty brutal out there though, and somebody has to point that out to you every now and then, lest you forget it (which it seems that you did).
> They did the math and the business case for Rails was more compelling.
They did no math, except one: how easy it is to hire 5 new devs in the next 1-2 months. No other analysis was involved whatsoever. Again, I've looked from within, a good number of times.
---
I am all for an informed debate but that seems to be difficult with you as you resort to exaggerations and dramatic language.
For the record, I don't do my main work neither with Ruby on Rails nor with Rust (though I know both, or should I say I knew RoR because I haven't used it in a while now). I got no horse in the race, I am simply looking for an objective discussion based on merits that can hopefully ignore network effects and popularity. Technologies absolutely can and have won by utilizing network effects and popularity (see: Python) but that does not say much about their objective merits.
Earlier quoted context omitted.
Rails is no more productive than go, and a developer taking 20 extra minutes (frankly, not likely, even if we’re talking rust) to write go rather than Ruby is not going to cost more than the $1000 a month the extra Ruby servers cost you just to run. “But but but developer productivity” is a myth.
It sounds like you haven't worked with many startups which is where Rails has been the goto option for a very long time. Rails is a framework. Go is a programming language. Show me a Go command line which sets up a fully-baked MVC app complete with data model, migrations, CORS, caching, asset pipeline, mailer, mailbox, chat(Action Cable), job queue and a Hotwire equivalent. While you're baking all of that yourself I'…
That's the only thing RoR wins at: speed of delivering first MVP.
Once you get into areas where companies don't die if they can't deliver a demo next week, RoR is not at all impressive or even consequential.
Earlier quoted context omitted.
Web backends in Rust and C++? Not saying web frameworks in these languages don't exist but to claim they're anything other than curiosities is misleading. In any case, good luck with the fraction of a millisecond such languages gain you while waiting on database i/o. There are use cases for switching to a compiled language like Rust or C++. Web back-ends isn't one of them.
Nah. One rust based server can power the same number of connections as 10-100 ruby based servers. This is not just “pretend database IO” problem. This is actual cost that no business should accept on the basis of “but but but database IO (that I’ve never actually measured, but it’s an easy cop out because I read it on medium once).
Earlier quoted context omitted.
> I seriously don’t think it’s worth comparing Ruby to languages like C++ and the rest. It is worth comparing any two languages and ecosystems if they are used for the same things, in this case -- web backends. Anything and everything that has a web backend is a fair game for comparison.
Building a web backend with C++ is a very dangerous and complex ordeal, you're extremely likely to expose memory based vulnerabilities to the entire world.