matt2000

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.

It's the first thing on the linked page:

Realtime database Authentication File storage Admin dashboard

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.

This is kind of happening at scale in China right now (only some brands are pursuing it though): https://restofworld.org/2024/ev-battery-swapping-china/

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.

And here's a link to the new version for convenience: https://earth.google.com/

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.

Is that pricing for an additional service that is optional, or is it required to operate the card? I'm confused.

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?

Thanks!

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.

It's 14GB for $500/month. Still pretty expensive though.

I am around 20 years into professional software dev and this list is great. Not sure what else I can add, just wanted to +1 the whole thing basically.

The Hindenburg has also now been heavily scrutinized. Good to go.

Does Render run on AWS? Or it's own servers? Having a little trouble figuring out things like that and what regions they're in etc. Looks cool though.

Would you mind linking to a couple of them? I don't know anything about Elixir (but am very comfortable in a lot of other languages), and am interested in the kind of thing more experienced people are using with Elixir. Thanks!

I've been programming Java since 1998 or so, and this may be surprising to some on here - but I still like it!

Here are the upsides in my mind, and as with all these things keep in mind - nothing's perfect! Everything has tradeoffs and I am making no absolute statements. Anyway, in no particular order:

  - Performance. It's possible for Java to be within 50-98% of the speed of even the most hand tuned native code, which is pretty remarkable considering the language comforts it provides.
  - Backwards compatibility. I have code that's 15 years old I still use. Programming hasn't fundamentally changed _that much_ in the past 20 years, but a lot of other languages act like it's changing by the year or even month. I deeply value not spending time fixing breaking language changes or dependency problems (for the most part).
  - OOP. I know we're in the cycle now where "OOP is a failure," but that's just wrong. Just like it was wrong when "OOP was the solution to everything." I don't go crazy with it, rarely use inheritance, use interfaces only occasionally, but do find it's nice to keep myself organized in terms of scope of code and responsibilities.
  - Typing. I know it's not perfect, but I really lean on the type system in Java. I think this might be because I'm a bit of a messy programmer to be honest, so this helps me keep a handle on things. When I work in Javascript I find things getting out of control quickly, whereas I can make statements about the entire codebase in Java that help me stay on track.
  - Tools. I've been using Idea as an IDE for 15 years or so and it feels like an extension of my mind. I can't even remember what the keyboard shortcuts are anymore, I just do them. It really helps keep the focus on the problem at hand rather than the details of implementation. We're finally coming out of the "IDEs are bad" cycle so I see more people using them again, that's good for everyone.
  - Simplicity. One major thing that people have forgotten with Java is that you can write simple code with it. It feels like the number one complaint is over engineered "AbstractFactoryImpl" codebases, and I hate those too. But it's also possible to write simple, easy to follow, understandable code.
  - Exceptions. I used to hate these too, then I had to write some code that _really had to work and handle everything_ and suddenly they were pretty nice.

  - It's pretty bad for scripting. A lot of that could be fixed with extensions to the standard library that provided easy helper methods. We shouldn't be constructing URL objects for anything, just do it. I'm very jealous when I see a nice Python script for doing something with data from an API.
  - It does tend to want a lot of memory. This isn't as much of a problem anymore thanks to Moore's law, etc.
  - Library support for new services. People tend to write a Javascript, Ruby and Python library for everything, which is super nice. Java is not as common these days.
  - Some other stuff I'm probably forgetting right now, I'll update this if I think of anything else. As I said, nothing's perfect.

I appreciate the author putting this post together. I am, however, having trouble squaring the overall positive tone of the piece with what seem like multiple show stopping problems. The bottom line I am taking away from this is you might not be able to ship your app at all if you use SwiftUI. Am I being too harsh? Or does that seem accurate?

I would guess so, although the size overhead for an optimized Flutter release build is now down around ~4MB, so not a determining factor for most use cases anyway.

They are planning to complete the transition in 2 years: https://www.apple.com/newsroom/2020/06/apple-announces-mac-t...

Makes your question even more interesting though, what will a Mac Pro look like running Apple silicon inside 2 years from now?

I love to read about how StackExchange does things, it's such a stark contrast to the cloud maximalists. I'm not saying there aren't advantages to each camp, it's just nice to have a solid example on the "vertical scaling can actually get you pretty damn far" side of things.