271–277 of 277 posts
Earlier quoted context omitted.
Yeah, setting a hard cap on the maximum cpu count doesn’t feel right? Why not depend on the available cores?
It’s a safe choice. Some systems won’t report cores correctly which can lead to reallllllly bad performance.
Earlier quoted context omitted.
shrug the companies you mentioned do not use C++ for web-app. Amazon is a huge Java shop. Twitter used to be huge Rails app with Java/Scala services. NGINX and Passenger are infrastructure pieces just like Memcached so I think you need to understand the context here...
Shrug, you have no idea what you are talking about [1]. Also nginx and passenger are webservers and claiming they are not part of your web app is a pretty wild claim when they literally send http responses to browsers (unlike memcached). [1] https://en.m.wikipedia.org/wiki/Programming_languages_used_i...
We're talking about web-app, not microservices.
We're talking about CRUD with DB migration, sessions, caching, etc.
I recalled Google's dl.google.com was implemented in C++ and Brad F rewrote it with Golang. We're not talking about microservice that serves file here. We're talking about the main web application that serves wikipedia, youtube original version (they might had revamped it sometime post acquisition with web gateway and bajillion microservices), Google Search (was Java servlet), Facebook original web-app (was PHP, became HVVM/H4CK.
So yes, I _know_ what I'm talking about in terms of the context of a web-application here. Do you?
Earlier quoted context omitted.
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.
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.
I skip Ruby hype but I know RoR and I use Golang professionally to build microservices serving Fortune 10,50,100,500, whatever and I wouldn't use Go to build a web-application.
Golang for microservice that relies on other microservices are great (i.e. my Golang service doesn't handle authN/authZ, but another service does), Golang for monolithic web-app that has to handle db migration (yeah I know something exist), implement multiple crud objects (remember, Golang microservices typically has smaller context and challenges than a medium size web-app) is pain in the ass!
PS: cut my teeth in Java servlet/jsp, moved on to Spring Framework+GWT, skipped RoR went straight to JS and ended up in Golang for the last 5+ years. I'm not Rails worshipers but I'd probably pick Java Spring ecosystem over Golang for monolithic web-app.
Earlier quoted context omitted.
Mike Perham (the sidekiq maintainer) also maintains the less well known faktory[0] which is language agnostic and has runners for both Ruby and Python [0] https://github.com/contribsys/faktory
That's awesome. Any idea why he doesn't just supersede Sidekiq with that? I spent quite some time hacking my own solution. I just looked at the source, I guess Mike has been mostly working on both projects on his own for the last 4 years, so Faktory has a lot of features that require the enterprise license. I wonder if he could change the situation it he markets a bit more to the python and more specifically Django c…
Earlier quoted context omitted.
I think Ruby is much better at shell script like tasks and interactive / exploratory programming for system tasks compared to Python or Node. Use it as “better bash” or “better Perl” and it’s worth it. I primarily work in a Typescript codebase, but regularly reach for it as a tool to wrangle log data, semi-structured text, or do regex rewrites of a bunch of files. Ruby is also very fun, probably the most fun language…
This is very intriguing, could you please elaborate? I have been looking for a better bash for scripting stuff without all the bash and sh-isms and gotchas.
Then add in something like Pry or Irb, where you are able to build castles in your sandbox.
Most of my data exploration happens in Pry.
A final book I’ll toss out is Data Science at the Command Line, in particular the first 40 or so pages. They highlight the amount of tooling that exists that’s just python shell scripts posing as bins. (Ruby of course has every bit of the same potential.) I had always been aware of this, but I found the way it was presented to be very inspirational, and largely transformed how I work with data.
A good practical example I use regularly is: I have a project set up that keeps connection strings for ten or so SQL Server DBs that I regularly interact with. I have constants defined to expedite connections. The [Sequel library](https://sequel.jeremyevans.net/) is absolutely delightful to use. I have a `bin/console` file that sets up a pry session hooking up the default environment and tools I like to work with. Now it’s very easy to find tables with certain names, schemas, containing certain data, certain sprocs, mass update definitions across our entire system.
``` # Something failed, and not everything loaded as you expected # explore explore explore…
db::CompetitorPricing.tables
db::CompetitorPricing.tables.grep(/^pricing_/)
latest = DB::CompetitorPricing.tables.grep(/^pricing_/).map {|table| [table, table.max(:create_ts)}
latest = latest.sort_by(&:last)
# serialize to csv, or json, or perhaps copy the data into excel:
Clipboard.copy latest.map{ _1.join("\t")}.join("\n") ```
Just like with work in the shell, you have a really easy time iteratively exploring the problem and building up your answer. The ability to serialize your data you’ve found, and keep your favorite tools in your pocket feels extremely productive. And of course, all of this can be written in ruby 1-liner shell scripts, or more complex shell scripts to pipe in and out of other tools if desired.
Earlier quoted context omitted.
It doesn't answer the question of why you would choose Ruby. Honestly, you all sound like you got a Sega Genesis for Christmas, while everyone else got a SNES. You can tell other kids on the playground that Genesis has better graphics, but the spec sheets don't lie. You're trying to make it seem like it's a wash, because "scripted" but it's not. Node.js outperforms Ruby in every department. And it's based on one of t…
Fine analogy. Plenty of people liked the Sega Genesis more than the SNES. (I think a more apt analogy is more contemporary consoles, where the lowly-spec’d Nintendo competes just fine against the competition’s higher performance units. People like Nintendo for reasons other than the spec sheet.) I enjoy writing Ruby a heck of a lot more than I do writing JavaScript. I like the object model. I like Ruby’s standard lib…
We're talking about performance because of the context, which is – there aren't the jobs to support the language's continued growth and dedication. We're talking about speed because there needs to be a defining reason to continue using a language and develop in an ecosystem that isn't moving at the growth of other communities.
If Nintendo Switch had 4 games, and they all looked like dog piss - asking why would I bother wasting time with Switch is a valid opinion.
There's also this insect-minded logic of only being a "front end developer" or "back end developer", and that mindset is furthered by languages that don't bother speaking the language of the web. If I learn javascript, I can be both - pretty much on day 1. If I learn Ruby and Javascript, great. How easy is that to do for a junior developer just getting out of school? Not widely.
I believe with version 3.3 Ruby is back in a big way! The language focused on developer happiness and derided for its slowness is slow no more. YJIT is an amazing technology, and together with other innovations like object shapes and various GC optimizations, Ruby is becoming seriously fast! Big Ruby shops such as Shopify [1] have been running 3.3 pre-release with YJIT and reporting double digit percentage performanc…
Ruby the language may be fast but the whole ecosystem is painfully slow. Try writing a server that serves 1mb of json per request out of some db query and some calls to other services. I get 100 requests per second in Rails. Same service rewritten in go serves 100k requests/s.