I am increasingly wondering if we are in a post-language world in terms of development. Why would I ask an agent to write a server in anything other than the most efficient language, although efficiency can take several forms: runtime, token usage during development, and wall clock dev time (affected by slow compile times for example).
My intuition is that type-safe languages with fast compilers are the best option. Maybe Go? I personally prefer Java just due to my experience running it in production, but am not sure there's many arguments for it over Go in a greenfield application. The other candidate would be Rust, but I worry about token efficiency and tool performance, I suspect it's not worth it for the runtime improvements.
All that being said, in this article switching to Python seems like a wild choice. Relatively poor performance, no compile time checking at all. Python's big selling point was developer ergonomics, which seems largely irrelevant now.
These are all just thoughts at the moment, I should try to find some evidence one way or another.
I would argue that it helps me when performing maintenance to see and correct where types may have changed. Not always, and sometimes it is busy work I agree, but overall I prefer it.
I agree, and I'm not sure how something like 'var accounts = calculateAccounts(something)' can be thought of as better in a code review setting. I suspect using "var" or equivalent will be considered a problem by most companies within the next few years.
Side note, the Connection Machine is pretty much the coolest looking computer ever: https://www.computerhistory.org/revolution/story/73 It looks exactly to me what a powerful and slightly scary computer from an 80's movie looks like.
I can understand the frustration from a climate change perspective, but you still get the benefits of cleaner air locally, increasing energy independence and freedom from commodity cost fluctuations.
It's an interesting trade off between swapping station cost and time to charge. I suspect charge times will decrease enough that it's not worth all the physical investment in swapping, it may already not be.
My understanding is that this the vulnerability only allows memory access to related Safari/Webkit processes (specifically those sites that were opened with a window.open call). So passwords stored in a separate password manager app are inaccessible unless that app autofills the password into the compromised Safari window/process.
It's hard not to think that both Honda and Toyota are just trying to convince EV buyers to delay their purchase since something "much better" is about to be released, or at least until they have time to release competitive EVs. Both companies are in the press talking about huge improvements possible with their solid state batteries, with no current production to speak of.
It should be considered a failure of our profession that after all these years the number 1 issue is still out of bounds write, a memory safety issue. In any true engineering profession a failure of this sort would be unacceptable, but in ours it's tolerated and explained away as a necessary byproduct of certain tools. How much personal information has been compromised due to these low standards? How many people put at risk? It's shameful.
It’s very healthy to be skeptical. I’m no expert but the current status appears to be a successful test of the merge on a public testnet and an expectation that it will happen on mainnet in the next few months. More details here: https://ethereum.org/en/upgrades/merge/ and a prediction market on the actual date it will happen here: https://polymarket.com/market-group/ethereum-merge-pos
I very happily use this technique and I believe I found out about it from your original blog post. Thanks for the original writeup and for the update on how it's going a few years in!
Has anybody tried this and can share their experiences? It sounds really cool, but it's usually the edge cases that determine whether something like this is actually good or not. Thanks!
Agree, it's a straight up reduction in code readability for all future maintainers so a single original developer can avoid doing a thing their IDE probably would do for them automatically. (I use "introduce variable" to create most variables automatically of the correct type).
Yes I know the IDE can also reveal what type a var is, but you generally read code in lots of places that aren't IDE enabled.
It also adds more work for the compiler. I'm not sure the effect on Java compile types yet but Kotlin and Swift have both suffered from slow compile times and this seems to be a factor.
I'm guessing that most of the larger codebases out there will add "no var allowed" to their style guides within the next few years.
None of these feel particularly true to me, but in particular "less code is more readable" is just so clearly not true. If this was the case we'd all still be using Perl.
I'm not an expert, but in a recent article about the new mRNA synthesis techniques they were asked the same question. The answer was there's already lots of potential bioweapons and many simpler techniques for producing them, so these new technologies don't change the danger level much.
First, congrats on the launch! Glad to see more products in this space. Now, some questions :)
I've looked at many of the attempts similar to this over the years and while you hear "you don't need to know how to operate K8S" you are in fact operating K8S and when there's a problem suddenly all this complexity is revealed. If Heroku has a problem, it's pretty clear where the responsibilities lie, but with this it's your code but my deployment so I'm kind of on the hook. What are your thoughts on that?
How would you compare to something like app platform at Digital Ocean?
Tip for that situation: Since Heroku runs on AWS, you can just use a single RDS DB instance to serve as the database for a bunch of hobby instances. Really hard to beat the $5/dyno hobby pricing considering the feature set.