stevebmark

Valid according to who? If you're automatically linking text that looks like URLs, this will fail since most people don't type the protocol when sharing a website URL.

I'm not surprised you don't consider the team you work on as overhead. But it is just that. This is a Rails only problem. This is not a problem that applies to other engineering ecosystems, because upgrades are easy to trivial in other ecosystems. It is a problem that shouldn't exist. It makes sense that the only way Shopify has found to do efficient Rails upgrades and keep using Rails is to dedicate a team to it and subsidize Rails core development. But this isn't a model other companies should follow.

I don't see the JVM team as the same thing as a team dedicated to working off a project's core. The JVM team looks closer to the YJIT project. Making a JIT also calls into question Shopify's scalability: Rails was slow enough that they allowed a JIT to be built internally? That's quite the trade-off to make.

Did you really mean 1,000 and 2,000 LOC for tests? Or did you mean 1000k or something else? If you meant 1,000, that is an objectively tiny app, and not relevant to the difficulty of maintaining large Rails applications.

It's not easy to automate. As you know Github now works directly off the Rails main branch. They have both core Ruby and core Rails maintainers on staff. They have to find, fix, approve, and merge, introduced bugs every day, as well as deal with Rails bugs themselves in the main branch that emerge. This is a huge overhead cost for keeping software up to date, and does not (and should not) apply to any other company.

This is an ironic comment on a Shopify story, they have wasted a lot of time upgrading Rails https://shopify.engineering/upgrading-shopify-to-rails-5-0

I agree labor is expensive, which is why you shouldn't use Rails. Shopify brags it took them only a year to upgrade Rails one major version https://shopify.engineering/upgrading-shopify-to-rails-5-0

Maybe you haven't worked on a large production Rails app? Rails takes 3-4x the infrastructure hosting costs as other languages/frameworks. Not to mention the insane testing costs from Ruby test bloat.

Has anyone tried to load old Flash files with these? Will give it a try, I always regretted not converting some of my old Flash projects into YouTube videos, etc.

I agree, client only is choosing DX over UX. Slow loads, bad for mobile, loading spinners, flashing content. Which is why Next.js is awesome, it abstracts all of that away for you, so you still get fast sites without sacrificing DX.

The default should be SSR / SSG. Client only is a recipe for a slow web. Client loading is mainly appropriate for long running apps, like GMail, where users tolerate a slow initial load because they're keeping the tab open for a long time. There's a reason the Jamstack mascot is a loading spinner.

I take it you don't write HTML because you don't want to use an "XML-like syntax"?

Say more. What's the distinction between layout and style?

Please don't take any advice from this blog post! It's a waste of time

I'm entertained by the trolling, it reminds me of when React first launched, to see who was yelling the loudest about React violating separations of concerns, and totally missing the point, just jumping on the bandwagon. It feels like a similar thing this time around. It's fun to keep tabs on who misses the point.

My favorite part about this debate is that this is how Rails works, but Rails is worse. You intersperse raw database calls with your template code (`user.first_name`), and your templates kick off an untrackable amount of queries, and when you start nesting templates, you've lost all hope of app optimization.

RSC looks like it has some great potential. I really enjoy seeing these miss-the-point trolls that overlook existing technology issues.

How did this make it to the front page? There is nothing insightful here. Someone who isn’t very a mature got bored and wrote too much with little substance. Hard skip.

Absolutely not. All books printed have text that is roughly the same line width for a reason. Reading width should always be constrained.

I legitimately find your cognitive dissonance interesting. I think you're on the other end - you may understand the fundamentals so well that your brain isn't processing the question / conundrum in the way that others see it. Honing in on the the scales of the arms as your reaction the paper is why I think this, as that's not related to the problem. And, well, you said it yourself, you don't understand the question:

> No clue why GP thinks it "shouldn't work"

It's also possible you think that this is all about laser interferometry, and aren't properly considering how it could work in the context of compressing space, since a laser interferometry system in compressed space wouldn't produce interference.

I think you have an intuitive mental model of how it works, but don't actually understand it, or aren't able to explain it well.

This question is important enough that there have been papers written on it. I suggest you read https://pubs.aip.org/aapt/ajp/article-abstract/65/6/501/5300... which may strengthen your understanding.

I hate LIGO because it shouldn't work on paper, and few seem to actually understand it.

1. If you have a light wave in the universe, and you "hang" a mass by each valley and trough of the light wave, and then you squash and stretch the universe, the masses stay connected to the valleys and troughs of the light wave. Said another way, when you squash and stretch space, lightwaves within that spacetime are also squashed and stretched.

2. LIGO claims to work by measuring the squashing and stretching space with light. However, as we just learned, squashing space also squashes light waves. So the LIGO arms and light waves in the arms are all compressed together.

Said another way, LIGO can't work because the ruler itself is squashing as space squashes, so you can't measure if space is compressing.

LIGO does work, but if you can't explain how it works despite this description, then you don't understand LIGO.

Competition doesn’t drive down prices in American healthcare, it usually increases prices.

Read the book “An American Sickness”. It is indeed everyone.

Now you have your recent advocacy, which is common in the Ruby community. Embrace magic, embrace indirection.

I wasn't aware of that new cop. Anecdotally, find Rubocop (and Flog and Reek) to be backwards tools. To me, they pattern match (ha) as the same core problems with the Ruby ecosystem. Ignore best practices that other language ecosystems have evolved, and embrace what other languages agree are bad practice.

I guess you haven't read Eloquent Ruby!

Pattern matching is an objectively good language feature. I wasn't aware the Ruby community sees it as controversial. Why does the Ruby ecosystem do so many things backwards compared to modern software engineering? Pattern matching bad, method_missing good?

It’s a common logical error. Infinity doesn’t mean all possibilities. An infinite universe doesn’t have infinite copies of someone. Pi doesn’t have everyone’s source code. There an infinite number of infinite random digit series that don’t contain anyone’s source code.

No, go the other direction. Once those kids start working on code that other people use, the poison can cause them to shun compile steps, types, tests, build processes, comments, module organization.

There's something interestingly poisonous about the demoscene mentality. Write small, hacky, throwaway, non-reusable code, hand minified beyond readability. Unit tests aren't relevant. You can see this mentality infect WebGL systems and places like Shadertoy. There's a tension between "software engineering" (whatever you want to call it) and demoscene hackers.

Yup, most important psytrance artist to include. Lots of no name generic artists. Included Ace Ventura which is good, but no Sub6, Skazi, Blastoyz, Infected. Was this just done based on random Spotify searches?