nathan_long

> So is Verizon responsible even though nobody at Verizon had anything to do with it?

Imagine if CompuServe still existed, but they had undergone 100% employee turnover in recent years. They'd still be liable, right?

It seems to me that when Verizon bought CompuServe, they calculated that its assets minus its liabilities totaled less than the purchase price and hence it was a good deal. If we treat leakable data as a legal liability, it should send the right financial signal - eg, maybe as a company you don't want to collect much.

> not an apples to apples comparison IMO

I see what you did there.

I think password management is a good fit for Mozilla. I perceive Mozilla to be trustworthy and competent, and the code for this is open source: https://github.com/mozilla-lockbox

They also generally do a good job with UI, which is not true of all open source solutions. This may not be crucial for devs, but it's crucial if we want to share passwords with the non-devs in our lives.

The bullet gem has helped me solve this problem in specific applications before, yes.

My higher-level problem is that having lazy-loading on by default allows N+1 queries to creep in to a code base and you need a third-party gem to find them. I've had to spend significant time finding and fixing this after joining teams with large legacy apps.

"Disable lazy loading globally" should be an ActiveRecord setting and it should be on by default IMO; people who need lazy loading should have to turn it on per query, something like `query.allow_lazy_loading(post: :author)`. I suspect that a very small fraction of queries would use this, since many apps don't do server side rendering, many who do SSR don't use Russian doll caching, and even those who do both still execute many queries that should prefetch all the associations they use.

> Wouldn't you expect a carbon tax to be similar in price to the cost to get the carbon back out of the air?

If the goal of the tax is to fund carbon removal and if that removal can be done immediately after emission without any damage being done to the environment, then yes. Otherwise you'd want to factor in the damage done.

If someone injected you with snake venom and argued that they should only be fined the amount it costs you for antivenom without consideration of the damage to your body, you would not accept that.

> Callbacks suck, so write service functions for complicated CRUD. Working around ActiveRecord defaults is like the 2nd thing you learn to do at a serious Rails shop. I'm afraid you may not have been working with sophisticated Rails engineers, because we certainly modify defaults in our applications.

I'm not sure why you feel like you need to demean my experience to discuss this. Callbacks are extremely commonly used in Rails apps and not at all the province of Rails newbies. Here's DHH in 2018 telling you about how Basecamp uses callbacks: https://www.youtube.com/watch?v=M3JPTOTqsnE

And even if you don't like callbacks and never use them, at some point you're going to change jobs or consulting clients and land in a code base that's full of them.

> Elixir is hot, but it's hard to learn and will always have a barrier to entry that Rails won't.

Maybe so. I can't predict to what extent it will catch on, but it's paying my bills. If I get to stay in a happy little niche, that will be fine with me.

> I love how every time there is a post about Rails, someone preaches the holy grail of Elixir/Phoenix.

I can understand how you might feel that way. I tried to make clear that I don't think it's the perfect answer to everything forever, but to specify ways in which I've personally seen it as an improvement. And given that the OP is about the continued merits of Rails, don't you expect some commenters to express disagreement?

> the main thing that execs care about is the bottom line and how fast we can push products to production

True. But that matters not just on day 1 but for years to come. Sandi Metz in the Ruby community teaches that point well.

I've seen Rails patterns like ActiveRecord callbacks lead to buggy, confusing code, greatly hindering progress on feature work and requiring significant debugging effort.

Certainly lots of businesses have succeeded with Rails, and I've worked for some of them. Lots of businesses have succeeded with Python, Java, .NET, PHP, and Node, too. That in itself doesn't argue for which one to pick when starting a new project.

After experiencing difficulties with my Ruby tech stack, I started looking around, and Elixir is where I landed. At this point I'm invested and biased, just as the OP is. But bouncing back and forth between the languages recently has confirmed for me that I prefer Elixir for the reasons I gave above.

> To any young devs out there, I strongly encourage you to not pick a framework by its hype but evaluate it based on your system needs / maturity.

I'd suggest young devs pick tools based at least partly on job postings, and on that measure, Rails will win by a landslide. But keep your ear to the ground. When I started as a developer, I was using PHP, but I kept hearing how Rails was better. Learning it and moving to work in it was a great career move for me.

Something will come after Rails. Something will come after Phoenix. There will always be a new something. Don't get too caught up in the hype, but don't get too attached to your current tools, either.

If the query was expensive and could be run periodically, I'd either create a materialized view that gets refreshed as often as necessary (maybe by https://dockyard.com/blog/2017/11/29/need-an-elixir-dependen...) or use a GenServer process for caching that data (as you might do with Redis otherwise).

I don't think the view rendering itself would ever be a performance issue, but rendering a view is just a function call in Phoenix, so I could take a similar approach there - store it in a GenServer.

> The problem I had with the bullet gem however is that some times you actually want N+1 queries. Especially with Russian-Doll caching.

I know it sounds like I keep beating the same drum, but to me this problem seems like "we have slow views, therefore we need to sprinkle conditional caching logic everywhere, therefore we need to allow lazy loading, therefore we need to watch for N+1 queries."

As I wrote elsewhere (http://nathanmlong.com/2016/11/elixir-and-io-lists-part-2-io...):

> By contrast, by compiling templates to functions, Phoenix automatically and universally applies this simple view caching strategy: the static parts of our template are always cached. The dynamic parts are never cached. The cache is invalidated if the template file changes. The end.

With fast views, no lazy loading is needed and no N+1 queries need to be possible. I don't think this is a problem inherent to Ruby, just to the way ActionView and ActiveRecord currently work.

> Perhaps you don't want everything eager loaded, but you want an exception to be raised if you try to access an associated record that hasn't been preloaded.

Yes, exactly.

> When I need to load/use them along with many parent records, it seems pretty obvious that I'll want to include those associations (eagerly loaded) in my AR query to avoid N+1 queries as you mentioned. Then again, maybe I've just spent too long taking those assumptions for granted where newer devs might not.

You know that and I do too, but legacy Rails apps tend to be full of N+1 queries in my experience, and it's a major cause of slowdowns.

I haven't used Node, but I think it's funny how they tout asynchronous IO via callbacks. Meanwhile the BEAM has that plus asynchronous computation - you just write synchronous code and let the scheduler pause your BEAM process as needed.

If you don't have to write code to deal with the computer pausing your unix process to run a different one, and you don't have to write code to deal with the VM pausing your code to run garbage collection, why would you have to explicitly write code to deal with a pause for IO?

I know how to preload associations, but I don't know how to globally disable lazy loading of associations. Do you know a way?

Yep, I used it extensively on one project, configuring it to raise exceptions if it detected an N+1 query and gradually enabling it test by test as I fixed them. It's very helpful.

I spent a couple of years dreaming of getting paid to work in Ruby and Rails and about 7 years doing so. There are many things I loved about Ruby, and Rails brought a ton of good ideas to web development, as this post describes (though I don't agree with all the highlights).

I've since moved to using Elixir and Phoenix, and then even more recently, done some consulting on a Rails project. So the contrasts are on my mind.

My perspective now is that the advantages Ruby/Rails have over Elixir/Phoenix (community size and number of libraries) are circumstantial, and the advantages Elixir/Phoenix have (fault tolerance, concurrency, speed, less requirement for external tools) are inherent in the VM.

Yes, speed of development and maintainability matter. And yes, you can write good or bad code in any language. But if Rails taught us anything, it's that defaults matter. And the default pattern in Rails is to use ActiveRecord and rely heavily on model callbacks, which can get confusing quickly. ActiveRecord also has no way to turn off lazy loading as far I know, and chasing down N+1 queries to improve performance is something I spent far too many hours doing.

My productivity also wasn't helped by the long test run times of Rails applications, or by wasting time trying to optimize view rendering on a heavily-used page.

All of those are either non-issues for me now or at least greatly reduced - Phoenix view rendering is crazy fast, N+1 queries aren't possible with Ecto and it doesn't have callbacks, Elixir test suites are highly concurrent and generally fast (though driving a headless browser is still rather slow).

Performance and concurrency do impact productivity. And I find that "functions in modules" is a great way to structure code and makes it easy to refactor. So does being able to run the entire test suite faster than I can get distracted.

The best ideas of Rails, in my opinion, are present in Phoenix - things like structural conventions, English-like naming, and database migrations. But many of the pain points are missing.

Phoenix and Elixir aren't the One True Way™, aren't the best for every conceivable software problem, etc. And surely they'll be superseded. But in my opinion, Rails already has been.

This reminds me of the ISPs getting upset about the bandwidth they have to deliver on behalf of Netflix.

"Our platform enables your app" is true in both cases. But so is "our app brings people to your platform." The power imbalance is that it's easier to build a competing app than a competing app store or ISP.

> I hate being outright dismissive but it sounds like an expensive html/pdf form with a printer attached.

I don't think that's dismissive at all. That's what it is, and it sounds good to me. Basically the computer is a scribe with perfect handwriting that fills out the paper ballot for the voter while the voter watches. Absolutely any voter is qualified to assert whether the ballot contains the votes they intended to cast.

From there, you could have the voter carry the ballot and drop it in a box that's being observed by any number of interested parties, providing old-fashioned accountability. Counting by scanner is an optional time saver, with hand counts as the alternative / double-check.

> none of the election committees were willing to commit to a full hand recount

I don't see how any system can work if nobody is willing to double-check it.

> Kiniy said Galois will design two basic voting machine types. The first will be a ballot-marking device that uses a touch-screen for voters to make their selections. That system won’t tabulate votes. Instead it will print out a paper ballot marked with the voter’s choices, so voters can review them before depositing them into an optical-scan machine that tabulates the votes. Galois will bring this system to Def Con this year.

This sounds great: paper trail, no chance of "hanging chads" or bad handwriting, verifiable by the voter at the moment before scanning and hand-countable if necessary.

> But using less javascript is the hype today...

Is it? This article on npm weekly (https://medium.com/npm-inc/npm-weekly-133-billions-of-packag...) says 4 billion packages were downloaded in a single week - representing multiple packages per week per human on earth. (Granted, this was Feb 2018, which is 2.8 millennia ago in JavaScript years.)

This site (on which you can't use the back button after choosing a graph) seems to show downloads still growing for popular packages. https://www.npmtrends.com/

> You think people can’t tell the difference between Melanesians, Caucasians and Sub Saharan Africans?

Get someone to show you pictures and have you identify them. I bet you'll make a lot of mistakes.

Historically, not only can people not tell the difference objectively, they decide what the difference is subjectively. In the United States, the child of a white slave owner and a black slave, if their parentage was known, was ... black. People of "mixed race" might be deemed a different race than their own full siblings, based on which visible characteristics they got from which ancestor.

Even today, people migrating from one country to another are often surprised that their racial classification is different in the new country than at home.

> When you discover that some "race" is underrepresented in some field, it's completely possible that a major cause is that the median in that arbitrarily defined racial category is below the median in another arbitrarily defined racial category.

It's possible, yes. It's also possible that perceptions of race influence the subjective decisions that drive those outcomes. How would you determine causality?

Eg, you could try sending employers identical resumes with "black sounding" and "white sounding" names and measuring callback rates. This has been done: https://www.politifact.com/punditfact/statements/2015/mar/15...).

There are likely many factors in racial disparities, but this appears to be one of them.

A genetic test to see whether someone has ancestry from Melenasia or Sudan or Scotland is likely to give a different result than casual visual classification. The latter is what we commonly call "race".

No. Go look at pictures of Melanesians. Are they "black"? Yet:

> Among Templeton's conclusions: there is more genetic similarity between Europeans and sub-Saharan Africans and between Europeans and Melanesians, inhabitants of islands northeast of Australia, than there is between Africans and Melanesians. Yet, sub-Saharan Africans and Melanesians share dark skin, hair texture and cranial-facial features, traits commonly used to classify people into races. According to Templeton, this example shows that "racial traits" are grossly incompatible with overall genetic differences between human populations.

https://www.eurekalert.org/pub_releases/1998-10/WUiS-GSRD-07...

> Race is a subjective classification based on objective characteristics.

Perhaps more subjective than you think? Please read about the "one drop rule".

> Templeton used the same strategy to try to identify race in human populations that evolutionary and population biologists use for non-human species, from salamanders to chimpanzees. He treated human populations as if they were non-human populations.

> "I'm not saying these results don't recognize genetic differences among human populations," he cautions. "There are differences, but they don't define historical lineages that have persisted for a long time. The point is, for race to have any scientific validity and integrity it has to have generality beyond any one species. If it doesn't, the concept is meaningless."

> ...

> Among Templeton's conclusions: there is more genetic similarity between Europeans and sub-Saharan Africans and between Europeans and Melanesians, inhabitants of islands northeast of Australia, than there is between Africans and Melanesians. Yet, sub-Saharan Africans and Melanesians share dark skin, hair texture and cranial-facial features, traits commonly used to classify people into races. According to Templeton, this example shows that "racial traits" are grossly incompatible with overall genetic differences between human populations.

https://www.eurekalert.org/pub_releases/1998-10/WUiS-GSRD-07...

I have also heard of medical examples like that. However, this article argues that generalizations based on apparent racial characteristics are medically unreliable.

https://www.scientificamerican.com/article/race-is-a-social-...

> Yudell said that modern genetics research is operating in a paradox, which is that race is understood to be a useful tool to elucidate human genetic diversity, but on the other hand, race is also understood to be a poorly defined marker of that diversity and an imprecise proxy for the relationship between ancestry and genetics.

> ...

> "What the study of complete genomes from different parts of the world has shown is that even between Africa and Europe, for example, there is not a single absolute genetic difference, meaning no single variant where all Africans have one variant and all Europeans another one, even when recent migration is disregarded," Pääbo told Live Science. "It is all a question of differences in how frequent different variants are on different continents and in different regions."

> In one example that demonstrated genetic differences were not fixed along racial lines, the full genomes of James Watson and Craig Venter, two famous American scientists of European ancestry, were compared to that of a Korean scientist, Seong-Jin Kim. It turned out that Watson (who, ironically, became ostracized in the scientific community after making racist remarks) and Venter shared fewer variations in their genetic sequences than they each shared with Kim.

> ...

> "If you make clinical predictions based on somebody's race, you're going to be wrong a good chunk of the time," Yudell told Live Science. In the paper, he and his colleagues used the example of cystic fibrosis, which is underdiagnosed in people of African ancestry because it is thought of as a "white" disease.

What, genetically, is a race?

Speaking as someone who is forced to vote on a proprietary touchscreen system with no paper trail, I wish researchers were finding cryptographic problems in my voting system.

...and this has always been a unique pain point of development in the browser.

It could instead imply "if the browser didn't ship with a version that satisfies my requirements, use the polyfill"