jupp0r

I think it's often the other way around. The differences in perceived coding productivity that many people attribute to claude vs codex is more the harness than the model it's running (if running comparable classes of models).

Wouldn't this be solved like similar problems on earth by making small structures with large surface areas?

If there is not enough supply for the demand in housing then nothing but meeting demand with new supply will solve that.

I highly doubt they destroy digital copies of the books after scanning. They will want to train their future models on the same content. So what prevents them from making these digital copies available to the public? Copyright!

Just have your agent use an existing design system. They provide coherence and many styles to choose from (and customization if you really need that for your personal use). I wouldn't expect agents to invent a coherent component library from scratch for every project. It's a solved problem. I'd personally just use something very popular like MUI and be done.

I don't think that needs to be true either anymore. Exhaustive specifications and comprehensive test suites are easily created now too. That's why I think software engineering will not go away, it will just change drastically.

It's actually a combination of both, leaving out more expensive smaller markets.

And what would the goal of that be? I thought the goal of education was... education. The grading is not goal in itself. Will this really motivate kids to do better?

Sounds like a great opportunity for kids in high school to learn how to feed back the AI detection results into the model and have this process be automated. Next level would be fine tuning the model via reinforcement learning and sharing it with your friends via Hugging Face.

See Dyson Sphere: https://en.wikipedia.org/wiki/Dyson_sphere

Dependencies. There are billions of lines of C++ out there that have been optimized and production hardened over decades that you might want to reuse. Rust lang interoperability with anything but C sucks in practice.

libuv? libevent?

I generally agree, but max line length being so high you have to horizontally scroll while reading code is very detrimental to productivity.

Rails is in steady decline [1].

[1] https://trends.google.com/trends/explore?date=all&geo=US&q=%...

> What caused the drop in popularity in RoR?

Async/await. JavaScript and all other modern languages and frameworks have a great concurrency story. Rails still hasn't (but it's coming next year, it's been coming next year for a decade).

I disagree. Hiding async makes reasoning about code harder and not easier. I want to know whether disposal is async and potentially affected by network outages, etc.

I think you should appreciate more how much the tens of billions of dollars Google has invested in Chrome has benefited the web and open source in general. Some examples:

Webrtc. Google’s implementation is super widely used in all sorts of communications software.

V8. Lots of innovation on the interpreter and JIT has made JS pretty fast and is reused in lots of other software like nodejs, electron etc.

Sandboxing. Chrome did a lot of new things here like site isolation and Firefox took a while to catch up.

Codecs. VP8/9 and AV1 broke the mpeg alliance monopoly and made non patented state of the art video compression possible.

SPDY/QUIC. Thanks to Google we have zero RTT TLS handshakes and no head of line blocking HTTP with header compression, etc now and H3 has mandatory encryption.

Aside: it’s impressive how the whole blog post does not mention a single detail of what they actually did to achieve these performance improvements. Code changes, really?

There is also the question of cause and effect. Did Instagram grow to what it is today because of a decade of investments from Meta?

The point of deterrence is that you spend the money so the chance of Russia doing something like a land invasion of Europe is decreased.

The much more likely scenario that Europeans are wanting to prevent is a limited invasion in the Baltics or Balkans in order to politically divide and damage western democracies.

We need to invest a lot of money to stop climate change. Renewable energy projects are very capital intensive compared to fossil fuel equivalents.

This ironically applies both to climate change and being a decade too late to react to Russia's expansionist actions.

You're being overly dramatic. Germany has been spending low amounts of money on its military for two and a half decades. Circumstances changed and spending needs to be increased to adjust to the new situation. This is not militarization, it's the state fulfilling fundamental purpose of providing external security for its citizens. Spending is going to be less (relative to GDP) than in the 70s and 80s.

The Rails documentation has lots of info about this: https://guides.rubyonrails.org/tuning_performance_for_deploy...

Concurrency support is missing from the language syntax and this particular library as a concept. This is by design, to not distract from beautiful code. Your request will make zero progress and take up memory while waiting for the LLM answer. Other threads might make progress on other requests, but in real world deployments this will be a handful (<10). This server will get 10s of requests per second when something written in JS or Go will get many 1000s.

It’s amazing how the Ruby community argues against their own docs and doesn’t acknowledge the design choices their language creators have made.

Yes, it does. Ruby has a global interpreter lock (GIL) that prevents multiple threads to be executed by the interpreter at the same time, so Puma does have threads, they just can’t run Ruby code at the same time. They can hide IO though.

Rails is a hot ball of global mutable state. Good luck with threads.

Well instead of looking at the two first hits of Google I spent several years on a platform team of a multi billion dollar company using mostly Rails and worked on solving real world problems caused by Ruby/Rails’ design choices which lead me to believe that Ruby concurrency as of today is hot garbage.

They need fundamental breaking changes to the language to fix this, which means people won’t be able to use their beloved pile of 438 gems that haven’t seen a commit in 7 years. If I had to bet, I’d say the language is dead. It might still be a nice niche language for easy prototyping, but the world has moved on to async/await (js/python/Rust/C++) or stackful coroutines (Go).

Unfortunately, 5 years after the release you linked, almost none of this has made it to Rails or even to relatively new libraries this post is about. The reason (imho) are unfortunate design choices in how the language incorporates concurrency - it’s just not well done.

The API looks nice on the surface, but this will be expensive to operate due to Ruby and Rails’ lack of support for concurrency. Everything is blocking, which is not a great match for the async nature of interacting with these models.