[HN Gopher] Mike Perham, Creator of Sidekiq: From Employment to ...
___________________________________________________________________
Mike Perham, Creator of Sidekiq: From Employment to Independence
Author : derekkraan
Score : 169 points
Date : 2023-04-14 08:02 UTC (14 hours ago)
(HTM) web link (codecodeship.com)
(TXT) w3m dump (codecodeship.com)
| andris9 wrote:
| Mike Perham's Sidekiq was what I modeled my own business,
| EmailEngine, after. I took my decade's worth of expertise in
| email protocol implementations (I also run the open-source
| Nodemailer library) and built an email gateway app my customers
| can download and run on their machines or servers. Just like
| Sidekiq Pro, the customers need an active subscription to run it,
| but the app runs on their premises, and they maintain it. I only
| run the key generation and validation server, which costs me
| around $50 per month, including all the backups and so on.
|
| I quit my job to go full in with EmailEngine exactly one year
| ago, when MRR for EmailEngine was $500, now it is $3,900 and
| steadily growing. I do work full time on it, but the result is
| async - the work I put into EmailEngine today brings me income
| sometime later, and the recurring income I receive today is
| unrelated to any effort I put into the company right now.
| albertgoeswoof wrote:
| I was just about to post emailengine here, the business model
| is so similar to sidekiq.
|
| Any other great ideas?
| andris9 wrote:
| Yeah, it is so similar because I blatantly copied it. I had
| the old Changelog podcast episode with Mike Perham pretty
| much on repeat when I tried to figure out how exatly to set
| up my business.
| mperham wrote:
| Congratulations, that's great. I'm always happy to hear of more
| successful indie developers.
| alberth wrote:
| Unsolicited feedback, always link to your business in your
| posts.
|
| I googled "emailengine" and it's wasn't super obvious which was
| your business since so much paid ads exist for that search.
| andris9 wrote:
| Oh, yeah, I forgot my pitch. The link is
| https://emailengine.app - EmailEngine acts as a mail client,
| basically the same way Thunderbird runs on desktop, or the
| iPhone Mail on the phone, but instead of a GUI it has REST
| API and instead of desktop notifications it sends JSON
| webhooks. And instead of a single email account, it can
| manage thousands of accounts.
| thaumasiotes wrote:
| > I was Director of Technical Operations at The Clymb, which was
| outdoor-focused e-commerce vendor (think REI without the stores).
| I had a team of four and we were responsible for site devops and
| infrastructure. This was perfect because they were my alpha
| customer and I was in charge of the tech stack. The Clymb
| switched to Sidekiq immediately, of course, and every Sidekiq Pro
| feature I wrote was running in production before it was released.
|
| This makes me curious about either
|
| (a) conflict-of-interest rules at The Clymb that may or may not
| have governed the DTO directing the company to use his own
| separately-owned (commercial?) software.
|
| (b) negotiating private ownership of software written for The
| Clymb.
|
| One of those must have been relevant?
| mperham wrote:
| I started work on Sidekiq right before I joined so I made sure
| my employment contract had a IP carve out for anything related
| to Sidekiq.
|
| I never charged The Clymb to use the software. Previously they
| had been using delayed_job and were suffering badly from scale
| issues due to the use of MySQL as their queue store.
| fidrelity wrote:
| Mike Perham is an inspiration to me both in terms of Ruby/tech as
| well as business.
|
| I've been using sidekiq now for almost a decade and had the
| pleasure to meet Mike at a Ruby conf many years ago.
| aqme28 wrote:
| Love Sidekiq and loved how he runs it. Really feels like the
| right way to make money on OSS. Enterprise never crippled the
| free version.
| joshmn wrote:
| I've said this to Mike and I'll say it again: I hope he never
| gets a job.
| everybodyknows wrote:
| Naive question: How do you deter thieves who would pose as legit
| customers, but instead redistribute the library?
| john_fushi wrote:
| I guess Matsumoto should have charged for Ruby. I'm sure Mike
| Perham and Derek Kraan would have been glad to pay for that and
| that the Ruby community would be in a strong and healthy shape.
| ianbutler wrote:
| People need to eat man, doing something for free is a luxury
| not many possess. We can see how messed up the financial
| situation is for a lot of Open Source devs and their lives
| would be better if they were charging money instead of
| subsisting off grants and donations.
|
| I don't even necessarily disagree with your point that without
| being free those things wouldn't have taken off but we need to
| find a way to strike a balance in the developer community.
|
| Sidekiq having a free version and an enterprise version walks
| an okay middle line imo.
| wyldberry wrote:
| I personally try to spend money or use ad supported anything
| that is open-source just to help someone else eat. It really
| hit home for me about five years ago when the author of a WoW
| addon[0] couldn't develop anymore because of his financial
| and life situation.
|
| So many communities across the web rely on people putting in
| their spare hours for free just to enjoy things. Whether it's
| spreadsheets in Eve, Addons and Weak Auras in WoW, forum
| analysis posts, or whatever goes on in the depths of pvpoke,
| so much free labor underpins massive parts of the world
| today.
|
| I would love something that I could donate x money to per
| month and then based on usage, have it dole out to all the
| content providers with perhaps a minimum per month. It just
| seems daunting to do that as a) not a crypto scheme and b.)
| across all the various creator landscapes.
|
| [0]https://www.polygon.com/2018/9/25/17901552/world-of-
| warcraft...
| bdcravens wrote:
| Not by Matz, but there are paid versions of Ruby out there.
| mattgreenrocks wrote:
| Hilarious take given the fact that there are plenty of orgs
| making an order of magnitude more than Mike is that rely on
| Ruby.
| ch4s3 wrote:
| This is a very bad take. From an OSS perspective languages can
| attract large communities of contributors and corporate
| sponsors because of their broad appeal and utility. Specialized
| libraries will have more trouble doing both and may need
| alternate models to sustain themselves. From a business
| perspective, Mike offers not only a free version but the paid
| enterprise version comes with support from Mike and his team,
| which is something you can't get from a language owner unless
| you outright hire them or they run a consultancy.
| jorge-d wrote:
| Well Sidekiq is free to use. It's only the pro version that he
| charges and the free version code is open source.
|
| I don't see the problem in having that kind of business model,
| it still allows the community to thrive and offers entreprises
| a way to have premium support.
|
| Plus it allows him to invest more time in maintaining the free
| version.
| phamilton wrote:
| I have no problem paying for the Pro version, but one if its
| marketing pitches is "enhanced reliability", which is a wild
| marketing spin on "the free version will lose jobs in fairly
| common scenarios".
|
| In sidekiq without super_fetch (a paid feature), any jobs in
| progress when a worker crashes are lost forever. If a worker
| merely encounters an exception the job will be put back on
| the queue and retried but a crash means the job is lost.
|
| Again, no problem paying for Pro, but I would prefer a little
| more transparency on how big a gap that is.
| durkie wrote:
| how often do your workers crash? i rely heavily on sidekiq
| and don't think I see this very often, if ever.
| kubectl_h wrote:
| In containerized environments it may happen more often
| due to OOM kills or if you leverage autoscalers and have
| long running sidekiq jobs that have a runtime that
| exceeds your configured grace period for shutting down a
| container during a downscale and the process is
| eventually terminated without prejudice.
|
| OOM kills are particularly pernicious as they can get
| into a vicious cycle of retry-killed-retry loops. The
| individual job causing the OOM isn't that important (we
| will identify it, log it and noop it), it's the blast
| radius effect on other sidekiq threads (we use up to 20
| threads on some of our workers), so you want to be able
| to recover and re-run any jobs that are innocent victims
| of a misbehaving job.
| Colex wrote:
| it's not uncommon to lose jobs in sidekiq if you heavily
| rely on it and have a lot of jobs running. If using the
| free version for mission critical jobs, I usually run
| that task as a cron job to ensure that it will re-try if
| the job is lost.
|
| I have in the past monitored how many jobs were lost and,
| although a small percentage, it was still recurring
| thing.
| phamilton wrote:
| We process around 50M sidekiq jobs a day across a few
| hundred workers on a heavily autoscaled infrastructure.
|
| Over the past week there were 2 jobs that would have been
| lost if not for superfetch.
|
| It's not a ton, but it's not zero. And when it comes to
| data durability the difference between zero and not zero
| is usually all that matters.
|
| Edit for additional color: One of the most common crashes
| we'll see is OutOfMemory. We run in a containerized
| environment and if a rogue job uses too much memory (or a
| deploy drastically changes our memory footprint) the
| container will be killed. In that scenario, the job is
| not placed back into the queue. SuperFetch is able to
| recover them, albeit with really lose guarantees around
| "when".
| ZephyrBlu wrote:
| Let me get this straight, you're complaining about eight
| 9s of reliability?
|
| 50,000,000 * 7 = 350,000,000
|
| 2 / 350,000,000 = 0.000000005714286
|
| 1 - (2 / 350,000,000) = 0.999999994285714 = 99.999999%
|
| > _It 's not a ton, but it's not zero. And when it comes
| to data durability the difference between zero and not
| zero is usually all that matters._
|
| If your system isn't resilient to 2 in 350,000,000 jobs
| failing I think there is something wrong with your
| system.
| [deleted]
| phamilton wrote:
| This isn't about 2 in 350,000,000 jobs failing. It's
| about 2 jobs disappearing entirely.
|
| It's not reliability we're talking about, it's about
| durability. For reference, S3 has eleven 9s of
| durability.
|
| Every major queuing system solves this problem. RabbitMQ
| uses unacknowledged messages which are pinned to a tcp
| connection, so when that connection drops before
| acknowledging them they get picked up by another worker.
| SQS uses visibility timeouts, where if the message hasn't
| been successfully processed within a time frame it's made
| available to other workers. Sidekiq free edition chooses
| not to solve it. And that's a fine stance for a free
| product, but just one I wish was made clearer.
| aqme28 wrote:
| When we used Sidekiq in production, not only did I never
| see crashes that lost us jobs, but there are also ways to
| protect yourself from that. I highly recommend writing your
| jobs to be idempotent.
| pselbert wrote:
| Jobs may crash due to VM issues or OOM problems. The more
| common cause of "orphans" is when the VM restarts and
| jobs can't finish during the shutdown period.
| phamilton wrote:
| Idempotence doesn't solve this problem. The jobs are all
| idempotent. The problem is that jobs will never be
| retried if a crash occurs.
|
| This doesn't happen at a high rate, but it happens more
| than zero times per week for us. We pay for Sidekiq Pro
| and have superfetch enabled so we are protected. If we
| didn't do so we'd need to create some additional infra to
| detect jobs that were never properly run and re-run them.
| ransackdev wrote:
| Or install an opensource gem[1] that recreates the
| functionality using the same redis rpoplpush[2] command
|
| [1] https://gitlab.com/gitlab-org/ruby/gems/sidekiq-
| reliable-fet...
|
| [2] https://redis.io/commands/rpoplpush/#pattern-
| reliable-queue
| aqme28 wrote:
| Fair enough about idempotence.
|
| I'm still confused about what you're saying though.
| You're saying that the language of "enhanced reliability"
| doesn't reflect losing 2 jobs over about 50*7 million
| (from your other comment)?
|
| And that if you didn't pay for the service, you'd have to
| add some checks to make up for this?
|
| That all seems incredibly reasonable to me.
| danenania wrote:
| Crashes are under your control though. They're not caused
| by sidekiq. And you could always add your own crash
| recovery logic, as you say. To me that makes it a
| reasonable candidate for a pro feature.
|
| It's hard to get this right though. No matter where the
| line gets drawn, free users will complain that they don't
| get _everything_ for free.
| Mavvie wrote:
| How are crashes under your control? Again they aren't
| talking about uncaught exceptions, but crashes. So maybe
| the server gets unplugged, the network disconnects, etc.
| danenania wrote:
| To me 'crash' means any unexpected termination, whether
| it's caused by an uncaught exception, OOM, or
| hardware/network issues.
|
| I guess you can say that hardware issues on your host
| aren't under your control, but it's under your control to
| find a host that doesn't have these issues. And not even
| a full-on ACID database is going to be 100% reliable if
| you yank the power cord at the wrong moment.
| Mavvie wrote:
| I hope my tone doesn't come across as rude or too
| argumentative, but I think your understanding is a bit
| inaccurate.
|
| > it's under your control to find a host that doesn't
| have these issues
|
| All hosts will have these issues, the only question is
| how often. If you need 100% consistency, then you can't
| use the free Sidekiq. Personally, I've never needed
| Sidekiq pro (as these kinds of crashes are extremely
| rare). But this will depend on your scale and use case.
|
| > And not even a full-on ACID database is going to be
| 100% reliable if you yank the power cord at the wrong
| moment
|
| This is only true if there's bugs in the DB, or some
| underlying disk corruption happens. The whole point of an
| ACID database is that they're atomic, durable, and
| consistent, even in the worst case scenario. If a power
| failure corrupted my SQL database I would feel very
| betrayed by the database.
| danenania wrote:
| It wouldn't be corrupted, but in-flight transactions
| could fail to commit, just like queued jobs can be lost
| with sidekiq. The failure modes are similar.
|
| I take your point that at a certain scale, hardware
| failure is inevitable, but if you're running that many
| servers, you can afford sidekiq's enterprise plan. It's
| not something that will realistically happen if you're
| just running like 20 instances on AWS. It's perfectly
| reasonable to charge extra for something only large
| organizations with huge infrastructure budgets need.
| arkasan wrote:
| I wish this was prominently documented. Most people new to
| Sidekiq have no idea that the job will be lost forever if
| you simply hard kill the worker. I have seen a couple of
| instances where the team had Sidekiq Pro, but they had not
| enabled reliable fetch because they were unaware of this
| problem
| tebbers wrote:
| Exactly why we refuse to use Sidekiq. "Hey, you have to pay
| to guarantee your jobs won't just vanish".
|
| No thanks.
| the_gastropod wrote:
| To be fair to Mike, Sidekiq is absolutely free. He sells an
| enterprise version for money, that comes with support.
| 1123581321 wrote:
| And he only started because companies were telling him it
| would be easier if they could just pay him.
| toomanyrichies wrote:
| This is great. Reminds me of the Derek Sivers post [1],
| "Don't start a business until people are asking you to."
|
| 1. https://sive.rs/asking
| mcsniff wrote:
| Sorry, this is bogus.
|
| "If I had asked people what they wanted, they would have
| said faster horses." or whatever the quote is.
|
| There are tons of businesses selling products that are
| ideas brought to life from scratching their own itch or
| simply a desire to make something and put it out there.
|
| Personally, I am one of those people who started a
| business based on an idea with no validation before
| launching it.
|
| I built it in its entirety, then went to places and
| people who I expected would want it and low-and-behold, I
| am making a living doing it.
| toomanyrichies wrote:
| > There are tons of businesses selling products that are
| ideas brought to life from scratching their own itch or
| simply a desire to make something and put it out there.
|
| I'd bet money that the number of businesses which fail
| because they boil down to "a solution in search of a
| problem" is vastly larger than the number of businesses
| that succeeded despite performing "no validation".
|
| That said, "making something" and "starting a business"
| are two different things. I would challenge you to point
| out where in the post he argues against _making
| something_ , especially for the reasons you mention.
|
| > I am one of those people who started a business based
| on an idea with no validation before launching it. I
| built it in its entirety, then went to places and people
| who I expected would want it and low-and-behold, I am
| making a living doing it.
|
| Consider the possibility that you're in the minority
| there, and that you succeeded _despite_ performing no
| validation.
|
| > Sorry, this is bogus.
|
| So if it doesn't apply to you personally, or in all
| cases, then you dismiss it as "bogus", full stop? Are you
| in the habit of doing this often?
|
| Also, for future reference, it's "lo-and-behold", not
| "low-and-behold". [1]
|
| 1. https://en.wiktionary.org/wiki/lo_and_behold
| mcsniff wrote:
| > That said, "making something" and "starting a business"
| are two different things. I would challenge you to point
| out where in the post he argues against making something,
| especially for the reasons you mention.
|
| The author states up directly, "Don't make a website or
| an app. Don't build a system".
|
| Starting a business doesn't have to follow any real
| "formula". It can be a step in the beginning, middle, or
| end of a process. Yes, you should have the ingredients
| for a cake before you bake it, but you don't need to find
| someone who will eat your cake before you bake one or
| offer it for sale and you sure as shit don't need to
| "find real people whose problem you can solve. You listen
| deeply to find their dream scenario."
|
| > Consider the possibility that you're in the minority
| there, and that you succeeded despite performing no
| validation, rather than because of it.
|
| While I never claimed it was due to not performing
| validation, we can clarify that yes, it is not due to
| this, it is despite not doing it. Validation itself can
| be found in successful sales or other means, it does not
| need to be done pre-market and there are many examples of
| this, aside from the horses quote I provided.
|
| And yes, I, in the same way the author declares it,
| declare it as bogus because these rules do not need to be
| followed in the way the author claims.
|
| The post is riddled with questionable content, IMO, made
| to hit the wannapreneur market.
|
| I don't dare tell someone how to start a business. It's
| their business, it's their journey, they should do it how
| they want.
| bombcar wrote:
| Anyone who has a free thing, sell _something_ that produces
| an expendable invoice or receipt. Makes it easy to use
| company funds to pay for company work. "Buy me a coffee"
| buttons don't really cut it.
| JustLurking2022 wrote:
| It's always interesting to find out about these niche
| subcultures. Having worked with batch schedulers of all varieties
| for a couple decades, I've never run across Sidekiq but, then
| again, I didn't realize anyone had actually built anything in
| Ruby in the past decade.
| sandstrom wrote:
| Sidekiq Pro is great, we're paying for it! 10k a year I think.
|
| But for people who are interested in alternatives, I'd also
| suggest Good Job (runs on Postgresql).
|
| https://github.com/bensheldon/good_job
| adrianthedev wrote:
| Mike is an inspiration to me and my project!
| ezekg wrote:
| Same. He's always been a role model for my business as well,
| especially when I was just starting out. My business uses
| Sidekiq every day. It really is a great piece of software. He's
| also one of the reasons I think open source software can be
| highly profitable if people just figure out a business model
| that works.
| sickcodebruh wrote:
| Sidekiq is one of my favorite things about using Ruby, I include
| it in my short list every time a "Why use Ruby?" question gets
| asked. I miss it desperately when I work in other languages. I
| plan on giving Faktory a shot ASAP.
|
| Mike has always struck me as a great guy, really the kind of
| person who you're happy to know is building one of your favorite
| tools. In a world of starving open source contributors and mega
| corps throwing around weight, his success with Sidekiq stands
| out. It makes me very happy to see.
| shubhamjain wrote:
| This is one of the best businesses I have heard of. Even 6-7
| years back, Sidekiq was grossing $80k/month [1]. I imagine it
| must be much more now. No servers to maintain, no employees,
| minimal support work and Mike has the complete freedom to work on
| updates whenever he prefers. Almost entire revenue minus payment
| processing costs must be profit. Imagine making $1M / yr working
| only 10-20hrs per week (Don't wish to presume here, but that's my
| estimate of the man-hours it costs to run).
|
| > I still have 0 employees and don't plan to hire. I tune my
| business processes to run as lean as possible: Most of my
| customers are on credit card so their payments are automatic. The
| gem servers take about one day of maintenance per year. I can't
| really outsource much of my support work because it is so
| technical and specialized.
|
| > My gem server is a $6 droplet on DigitalOcean. Because gems are
| just static files, that little droplet can handle millions of
| requests per day with just Apache. Oh, and I run three servers in
| parallel for failover purposes for a grand total of $18/mo.
|
| I wonder what makes Sidekiq special? I don't imagine any
| equivalent product (background job processing) in the other
| languages is raking in that much, if making any revenue in the
| first place.
|
| [1]: https://www.indiehackers.com/product/sidekiq
| pselbert wrote:
| > I wonder what makes Sidekiq special?
|
| Time, know-how, and long term dedication are the key
| ingredients from my perspective. Maybe he's working 10-20 hours
| now, but there's support and development every day for the past
| 11 years.
|
| > I don't imagine any equivalent product (background job
| processing) in the other languages is raking in that much, if
| making any revenue in the first place.
|
| I guarantee, there are background job processors in other
| languages making revenue.
| pmarreck wrote:
| https://getoban.pro/ would like to have a word... It's
| apparently making good money
| pmarreck wrote:
| > I guarantee, there are background job processors in other
| languages making revenue.
|
| I had no idea until someone just hinted me that this was
| self-referential... LOL, apologies for the now-embarrassing
| other comment I made LOL (I only know you as "sorentwo",
| whoops!)
| mtlynch wrote:
| In 2017, Sidekiq was generating over $1M/yr in revenue.[0] It
| sounds like his costs are basically nil, so he's living the
| dream.
|
| [0] https://www.indiehackers.com/podcast/016-mike-perham-of-
| side...
| EastSmith wrote:
| > I can't really outsource much of my support work because it
| is so technical and specialized.
|
| Yeah, I had a Sidekiq question on StackOverflow and Mike Perham
| answered himself couple of days later.
| sparker72678 wrote:
| Sidekiq is special because it's crazy performant, and it
| _works_.
|
| Mike has built a system that's rock solid, and he doesn't
| twiddle around with it willy nilly. He keeps it super stable.
|
| The people paying for it (I'm one of those people) are paying
| for the reliability, in addition to the features.
|
| Mike's also managed to find a real sweet-spot with the features
| he holds out for Pro/Enterprise. The stratification is _just_
| right to nudge you up, but it always feels like you 're getting
| a good deal when you pay.
| princevegeta89 wrote:
| Just like the underlying platform it was built for (Rails) - it
| is so stupidly simple to deploy Sidekiq. Performance is great
| and a lot of complexity is well hidden. This makes it a great
| product overall.
| iudqnolq wrote:
| Oban is a roughly equivalent elixir library. They claim to have
| hundreds of customers and their cheapest plan is $500/yr, so
| maybe they make an order of magnitude less? Considering the
| relative language popularity that seems pretty good.
| mperham wrote:
| Hangfire and Oban are two other background job systems which
| have a commercial aspect. AFAIK Hangfire has been around almost
| as long as Sidekiq and is still actively supported.
|
| I'm closer to $10m than $1m in annual revenue now.
|
| My take on Sidekiq's secret sauce: a job system is a
| distributed system. Most of Sidekiq's commercial features are
| available as OSS gems but the complexity sneaks up on you as
| you integrate 3-6 of those features together. Building your own
| almost always leads to a worse system than the mature, well-
| debugged system which I have curated.
| alberth wrote:
| Super excited of you.
|
| - Do you have any outside hired help? I see you still have no
| employees, but do you contract with anyone to do customer
| support as an example?
|
| - How many approx customers do you have these days? $10M
| revenues = 10,000 customers. Is that roughly correct, if so -
| wahoo, congrats.
| mperham wrote:
| I'm closer to 2000 customers.
| aaronds wrote:
| That is absolutely absurd that you have built something
| many have tried and failed to do with millions of dollars
| of venture capital behind them, all on your own.
|
| Genuine kudos to you, you should be an inspiration to any
| indie hacker.
| sahila wrote:
| Part of the problem with venture funding is 10m arr
| wouldn't be considered enough.
| aaronds wrote:
| Totally. But regardless lots of ideas get funded that
| turn out not to be "venture scale" and many at an early
| stage that do not even get to $10m ARR.
| pmarreck wrote:
| Spoke with Mike at a couple of Railsconfs a few years ago (before
| I got into Elixir). Really great guy.
| davidw wrote:
| He's also a standup guy in terms of contributing back to worthy
| things here in Oregon.
| jack_riminton wrote:
| "I toyed with Sidekiq.js but decided to kill that idea real quick
| because, as we all know, JavaScript is terrible"
|
| This is why I love the ruby community, so much sense :)
| rektide wrote:
| From the JS community, this is sadly the level of snark we
| expect.
|
| It doesn't have to be like this. Your community tried to be
| better once. Have you forgotten?
|
| https://jasonfleetwoodboldt.com/courses/stepping-up-rails/ma...
| brigandish wrote:
| Matz is nice but that culture's definitely not coming back,
| anymore than the kind of fun and curiosity that _why brought
| to us. Maybe it's inevitable as communities grow and people
| taste success?
|
| Regardless, it's probably better if we leave room for little
| jokes with each other.
| rektide wrote:
| As someone who quite likes js & our wild teaming ecosystem
| a lot, I can also say: we definitely deserve some/mamy
| jokes too. No one's wrong on that. (jokes are good!)
|
| I wish they felt like they had some punchlines though. No
| one ever bothers to make the JS world laugh along. We know
| it's wild here (Come play! So much fun freedom!). It comes
| off more like a beat down.
|
| Context also matters. Conversationally Mike's words could
| be an amusing wink & grin quip. I can see that. On paper, &
| seeing it repeated with the same reckless unnuanced
| antipathy, it lacks the personal connection & feels
| indicative of a general attitude situation that is quite
| prevalent.
|
| Again I think there's plenty of valid negativities in js,
| but looking at the distribution of where folks fall on the
| alignment chart when they talk about JS issues, it concerns
| me how lopsidedly & with what casual acceptance folks tend
| towards the scariest boxes of the chart. To me we are all
| in the challenge of making computing better together, & we
| can help ourselves by helping others.
| danielrhodes wrote:
| There seems to be an ever-present high-level of defensiveness
| from the Ruby community over JS/React. Rails has had a
| profound impact on web development, promoting fast starts and
| shipping quickly. Companies like Shopify and Twitter
| benefited greatly from this. But the framework is 18 years
| old. The web that it was created for has changed
| significantly.
| ghiculescu wrote:
| It's changing back. SPAs are on the way out. Check back in
| 5 or 10 years - Rails will still be here.
| bradgessler wrote:
| I think there's two reasons for that:
|
| 1. When deploying a Rails app, the JS asset compilation is
| always the slowest part and is the most likely to break.
|
| It doesn't help that Rails has made a complete mess of JS
| assets, which I wrote about at https://fly.io/ruby-
| dispatch/making-sense-of-rails-assets/
|
| 2. For people who had to ship a Rails API + JS SPA, their
| workflow felt slow, brittle, and cumbersome. It wasn't
| their imagination either--testing the stack required
| integration tests, which are always slow. Maintaining an
| HTTP API to talk to the SPA is additional effort that's not
| needed, which Hotwired has demonstrated clearly.
|
| I still think Rails has a lot of fuel left in its tank,
| thanks to Hotwired and the big companies behind it, but I
| agree the "Rails is the most productive framework" gets way
| overplayed. It was def "most productive" 18 years ago, but
| most other modern frameworks took notice, caught up, and
| have even surpassed Rails in a lot of ways.
|
| The Ruby runtime leaves a lot to desire when you compare it
| to runtimes like Elixir/BEAM, Go, etc. I also think Rails
| has a terrible view layer, but most folks don't quite
| understand that that means yet. This is something I'm
| working on at the moment.
| danielrhodes wrote:
| The Rails view layer used to be quite nice at its peak.
| Way better than many of the alternatives. That you could
| execute actual code inside a view was just magical.
| jack_riminton wrote:
| The other thing I like about the ruby community is the sense
| of humour
| pmarreck wrote:
| You act as if some percentage less than 100% of Ruby users
| have extensive experience with JS as well...
|
| OK, maybe it's only, say, 96% of Ruby users, or 100% of Rails
| users at least
| rektide wrote:
| See like, this isn't constructive maligning at all, it's
| more undirected blanket unniceness.
|
| It costs nothing to actually put down a reason for being
| upset, versus having totally generic downputs. Very few
| things are truly rotten to the core, most bad things have
| some bad aspects but could be much better if ___. If
| something is rotten to the core the central articles of
| faith for why that's so should be declared.
|
| Plenty of Ruby folks have gone on to do great friendly
| Rails ish JS works. Ember.js is very batteries included,
| tries to show that yes all the potential is there to pave a
| nice well integrated happy-path system. To assume misery
| seems unreasonable; many have done fine.
|
| I think we have a real obligation to do better to ourselves
| & one another than to foster _shallow_ prejudices. Trump in
| his April 11th Tucker Carlson interview was asked why he
| thought Dems weren 't worried about nuclear weapons.
| "That's because they don't understand life. That's because
| they don't understand what it is that you have to
| understand." This is an irrefutable claim. There's no point
| to start discussing here, no possibility that the other
| side might change or have some nuances. Let's not do this.
| Let's rise to higher places where we take real appraising
| concerned looks at things, rather than just dismiss stuff
| out of hand. We don't even have to be nice, but let's at
| least strive to be somewhat useful.
| pmarreck wrote:
| > It costs nothing to actually put down a reason for
| being upset, versus having totally generic downputs
|
| Actually, it does cost something- time and effort- but
| thanks to the latest AI, I can cut some of that out right
| now:
|
| As an Elixir enthusiast, I'd like to point out some
| technical criticisms of JavaScript and its ecosystem,
| particularly in comparison to Elixir's approach to
| dependency management and community.
|
| A) Dependency bloat: The JavaScript ecosystem, especially
| when working with Node.js, often suffers from excessive
| dependencies. Even when you require just a few
| dependencies for your project, you may end up pulling in
| a large number of indirect dependencies. This can lead to
| increased complexity, slower build times, a larger attack
| surface for potential security vulnerabilities, and an
| ever-growing workload spent applying security fixes that
| have nothing to directly do with the purpose of the web
| app.
|
| In contrast, Elixir's dependency management system,
| powered by Mix and Hex, encourages a more conservative
| approach. Elixir libraries are often designed with
| minimal dependencies, and the community values self-
| contained, focused libraries.
|
| B) Security concerns: The extensive use of third-party
| packages in JavaScript projects can expose your
| application to security risks. When you pull in a large
| number of packages, you become responsible for ensuring
| that all of those dependencies are up-to-date and secure.
|
| Elixir's ecosystem tends to have fewer dependencies,
| reducing the potential attack surface. Additionally,
| Elixir's focus on immutability and the actor model can
| help minimize the impact of security vulnerabilities.
|
| C) Lack of native concurrency and parallelism: JavaScript
| is single-threaded by design, which can limit its ability
| to take full advantage of multi-core systems. While
| Node.js introduced asynchronous I/O to help mitigate this
| issue, it can still be challenging to build highly
| concurrent applications in JavaScript.
|
| Elixir, built on the Erlang VM (BEAM), provides excellent
| support for concurrency and parallelism through
| lightweight processes, message-passing, and the actor
| model. This allows Elixir applications to scale across
| multiple cores and handle a large number of simultaneous
| connections more efficiently than most JavaScript
| applications.
|
| D) Callback hell and async/await complexity: JavaScript
| has traditionally relied on callbacks for asynchronous
| programming, which can lead to a phenomenon known as
| "callback hell" when dealing with nested callbacks. While
| the introduction of async/await has improved this
| situation, it can still be cumbersome and confusing for
| developers.
|
| Elixir offers a cleaner approach to concurrency with its
| process-based model and message-passing mechanism,
| enabling easier-to-read and maintainable code.
|
| E) Mutable data- One of the key differences between
| Elixir and JavaScript is the way they handle data. Elixir
| enforces immutability, meaning that once a data structure
| is created, it cannot be modified. Instead, operations on
| data structures in Elixir return new versions of the
| data, leaving the original untouched. This approach
| offers several advantages compared to JavaScript's
| mutable data structures: 1)
| Predictability and easier reasoning: Immutability in
| Elixir makes it easier to reason about and understand
| your code. Since data structures cannot be changed once
| created, you don't have to worry about unintended side
| effects or data being altered in unexpected ways. This
| results in more predictable and maintainable code.
| 2) Concurrency safety: Elixir's immutable data structures
| simplify concurrent programming by eliminating the need
| for locks, mutexes, or other synchronization primitives.
| This is because multiple processes can safely read and
| share the same data without the risk of data corruption
| due to concurrent modifications. In JavaScript, managing
| shared mutable data in concurrent scenarios can be error-
| prone and challenging. 3) Functional
| programming: Immutability is a core principle of
| functional programming, and Elixir is heavily influenced
| by this paradigm. Functional programming promotes the use
| of pure functions that do not produce side effects, which
| can make code more modular, reusable, and easier to test.
| While JavaScript supports functional programming
| concepts, its mutable data structures can make it more
| challenging to adhere to functional programming
| principles. 4) Reduced cognitive load:
| Immutable data in Elixir means that developers don't have
| to keep as much track of changing state as they read or
| write code. This can make it easier to understand the
| flow of data and logic in your application, leading to a
| more pleasant and efficient development experience and
| ultimately, fewer bugs generated per LOC.
|
| F) Community values: The JavaScript community is known
| for its rapid pace of change and the constant
| introduction of new libraries, frameworks, and tools.
| While this can drive innovation, it can also lead to
| fragmentation and inconsistency across projects.
|
| The Elixir community tends to be more focused on
| stability, long-term support, and collaboration. This can
| result in a more consistent and cohesive ecosystem, where
| tools and libraries are more likely to work together
| seamlessly.
|
| In conclusion, while JavaScript has its strengths and has
| undoubtedly played a vital role in the growth of web
| development, its dependency management and ecosystem can
| be seen as less than ideal from an Elixir enthusiast's
| perspective. Elixir's dependency management system, focus
| on concurrency, and community values offer a more robust,
| sane and secure alternative.
|
| (How's that for "actually putting down a reason" as to
| why Javascript is terrible? Hey, you asked!)
| rektide wrote:
| Works for me! Very much matches the MO I've been using as
| "JS is wild, ain't it great!," so I tend to agree with
| the shown perspective.
|
| I also think a huge amount of these tend to be pretty
| typical conservative-developer overconcern (see Yegge's
| Notes From The Mystery Machine Bus
| https://gist.github.com/cornchz/3313150), governing
| yourself on fear, that is probably not really as fully
| warranted or deserved.
|
| But I'm also a huge fan of wild & fun & diversity. I also
| love that we try & do other things, that programming
| languages are not a Last Man Standing situation, & that
| we have great technical ecosystems with caring trying
| folks finding new ways to move forward & progress like
| Elixer. I look forward to seeing what lessons there prove
| really valuable (and perhaps aping them)! It's a choice
| in JS world but I do use immutable.js, for example, and
| it's great & as described as an advantage above. Ditto
| for some fp tools, but often I will mutate & use
| effectual/imperative styles, I often find there are
| significant performance or understandabity wins.
|
| I would say, yes, the cost of talking vs snarking may be
| real, but it doesn't have to be this large & well
| examined a list as you've madd. I don't like JS, the
| amount of dependencies terrifies me. I don't like JS,
| it's too fragmented. I'd rather use Elixer, I like having
| a good actor model underpinning my ecosystem. Sharing
| some sort of tidbit can help calibrate where a person is
| & turn destructive contagious negativity into healthy
| discourse.
| jack_riminton wrote:
| I think you're taking this way too seriously, it was just
| a blogger having a little lighthearted jab
| rektide wrote:
| Both agree in this case with Mike's right to fun, but
| also, I feel like the idea of lighthearted jabs has
| become a steady stream of blows. I said elsewhere:
|
| > _Context also matters. Conversationally Mike 's words
| could be an amusing wink & grin quip. I can see that. On
| paper, & seeing it repeated with the same reckless
| unnuanced antipathy, it lacks the personal connection &
| feels indicative of a general attitude situation that is
| quite prevalent._
|
| "Don't get so upset it's just a joke" is sometimes indeed
| a legit statement, sometimes we do take things too
| seriously & need to be reminded. But when the light jabs
| keep coming, when there's so rarely an attempt to ever
| bring both parties into the laughing, when it's always
| jokes at expense, the action whatever it's intent becomes
| part of a larger behavior that is more than a
| lighthearted jab.
|
| How many folks would stand up and say, no, there is no
| pattern of behavior about JS receiving short shift put
| downs? Do folks think there is no issue? How above board
| Vs how trashy do we think we've gotten with how
| programmer culture especially those parts that don't like
| it treats JS? What other parts of programmer culture
| endure repeated joke making at their expense today?
| thaumasiotes wrote:
| > How many folks would stand up and say, no, there is no
| pattern of behavior about JS receiving short shift put
| downs? Do folks think there is no issue?
|
| If you identify with JavaScript so strongly that you'll
| go over to message boards and rend your garments when you
| see people making fun of it, and you consider it a big
| problem that you have to do this so often... maybe
| consider whether there are some faults in JavaScript that
| lead it to attract a steady stream of mockery?
|
| > What other parts of programmer culture endure repeated
| joke making at their expense today?
|
| All of them. Programmers are an unpopular group.
| camdenreslink wrote:
| I wouldn't be so sure. They invented coffeescript in response
| to not liking JavaScript.
___________________________________________________________________
(page generated 2023-04-14 23:01 UTC)