foobazgt

It's stated directly in the article that Tesla's study reports vehicles with 200K miles generally retaining 85% capacity. That's nearly 300% better than what you're suggesting.

> Why guess?

Manufacturers DO publish reports. Tesla routinely provides data about the lifetimes of their vehicle batteries, which turn out to greatly exceed their warranties. (This shouldn't be surprising to anyone. Manufacturers just can't afford to have high warranty return rates).

The rest of your post is an attempt at hand-waving away what is a real phenomenon. EVs are still new to a lot of people, there's a lot of FUD floating around, and that can affect used vehicle prices. Markets behave irrationally sometimes, and that leads to opportunity. (In this case, getting a value buy on a used EV).

> hybrids are still obviously better

Hybrids are objectively worse. They have less all-electric (efficient, non-polluting) range, they charge more slowly, they have a more complex drivetrain with more parts subject to repair, etc. They're a better fit for a specific market segment, but that segment is small and rapidly becoming non-existent. You can get cheap EVs nowadays that have more range than my last ICE.

> For batteries, 80% of the initial capacity is referred to as the point

The publication cites sources from 15 years ago for this "fact" [0]. That's ancient history in the context of EVs (even before the first reliable mass production EV - Tesla's Model S - was initially released). As a practical matter, the article points out that most EV manufacturers (Tesla included) warranty their batteries for at least 70% capacity at timespans near a decade, which would bankrupt them all if EV batteries just up and died at 80%.

0) [35] O. Erdinc, B. Vural, and M. Uzunoglu, ‘‘A dynamic lithium-ion battery model considering the effects of temperature and capacity fading,’’ in Proc. Int. Conf. Clean Electr. Power, Jun. 2009, pp. 383–386.

[36] K. Smith, T. Markel, G.-H. Kim, and A. Pesaran, ‘‘Design of electric drive vehicle batteries for long life and low cost,’’ in Proc. Accelerated Stress Test. Rel. (ASTR), IEE Workshop, 2010, pp. 6–8.

This is so backwards, it's hard not to take it as a troll.

There is zero risk to using Java. People standardly use OpenJDK builds, which are freely and widely available under open source licensing (GLPv2 + classpath exception). In regards to maintenance, Java continues to be one of the most highly invested languages in existence.

If you had to pick an age for societal burden, it'd be the average "young" person who isn't making a net-positive contribution until around the age of 25. Most people don't receive a corresponding 25 years of retirement, and the retirement they do receive is a product of contributing to it for 40 years.

But it turns out young people become middle-age people, become old people, and we're all in this together. The real problem is not about how the pie is split across generations, but about the realities of lifespans, economic production, and expenses. If you're responsible for funding the entirety of your retirement, all of this is abundantly clear. When you nationalize retirement, all sorts of budgeting tricks start happening, like "borrowing" to fund other programs, papering shortfalls via population growth, etc. Then you start getting age warfare when the govt has to eventually cut back.

You could dissolve the national retirement plan, but that seems like a bad idea for similar reasons as entirely dissolving national welfare and insurance programs. It will always be the case that some people, need some help, some of the time. I guess in my ideal world, it's reduced to a much smaller safety net, because the government is managing the economy well enough that the populace has the wherewithal to save appropriately, and they are educated enough to do so.

JITs have runtime information that static compilers do not. Sometimes that's not a huge benefit, but it can often have massive performance implications. For example, a JIT can inline dynamically loaded code into your own code. That sounds unusual, but it's actually ultra-common in practice. For example, this shows up in something as mundane and simple as configurable logging.

There's clearly a cost-benefit tradeoff on the spectrum of static typing. We aren't all using Coq. OTOH, the burden of "basic" static typing is very low at this point given the successes we've seen with type inference. [0]

It seems like all of the dynamically typed programming languages are pursuing (optional/gradual) static typing systems, and we've mostly moved on past "pure" dynamically typed PLs at this point. It's more about how-much and what-kind of static typing. And perhaps this depends upon your domain (e.g. Rust and its focus on memory safety while eschewing GC, which necessitates lifetime annotations).

0) I don't think type inference is a panacea. For example, it's not super helpful when you have a complex type system inferring crazy types for you, and you're stuck debugging them when the inferrer has failed.

> Those are traditionally offered in Java in the form of bytecode transformation

And we've come full circle. I think they're traditionally written as bytecode transformations, because the entire pipeline for both writing and using many kinds of program transformations in bytecode is far simpler, more accessible, and more performant than implementing and executing a source-to-source compiler that feeds into another java compiler.

That said, there are also times you wish to perform transforms on programs for which you don't have access to source, in which case your hand is forced. Ideally, you would be able to write many classes of transforms agnostic to that context.

> Sure

Thanks!

You've referenced Lombok a lot here, and some Google searches later, I can see that you're in conversations all over the internet re: Lombok (and similar projects like Manifold). Their purpose is to extend the Java language. The class of code I'm referring to is more like those you already mention in your JEP: logging, tracing, profiling, serialization, authn/authz, mocking, ffi, and so on. I would describe all of those as fitting under the umbrella of "cross-cutting" and needing a "meta-programming" facility.

> However, we think there are much better solutions

I'd like to hear more. Can I discuss this further with you in a more appropriate venue than this forever thread?

Thanks for clarifying your role in the JEP.

I feel like we're talking right past one another. The ultimate reality is that annotation processors are pretty terrible for implementing functionality that a lot of Java developers depend upon. You could say annotation processors "weren't designed for that", but then you're just agreeing with me. This is sad, because arguably something quite similar to annotation processors could make the jobs of all of these developers a lot easier, instead of having them falling back to other mechanisms.

If your concern is integrity by default, why not just add yet another flag for can-muck-with-the-ast-annotation-processors? Or we can continue with the status quo.

Just because something mucks with a program's AST doesn't mean that it's introducing a new "language". You wouldn't call using reflection, "creating a new language", either, and many of these libraries can be implemented either way. (Usually a choice between adding an additional build step, runtime overhead, and ease of implementation). It just really depends upon the details of the transform.

The integrity by default JEPs are really about trying to reduce developers depending upon JDK/JRE implementation details, for example, sun.misc.Unsafe. From the JEP:

"In short: The use of JDK-internal APIs caused serious migration issues, there was no practical mechanism that enabled robust security in the current landscape, and new requirements could not be met. Despite the value that the unsafe APIs offer to libraries, frameworks, and tools, the ongoing lack of integrity is untenable. Strong encapsulation and the restriction of the unsafe APIs — by default — are the solution."

If you're dependent on something like ClassFileTransformer, -javaagent, or setAccessible, you'll just set a command-line flag. If you're not, it's because you're already doing this through other means like a custom ClassLoader or a build step.

Yeah, I'm not a big fan of annotation processing either. It's simultaneously heavyweight and unwieldy, and yet doesn't do enough. You get all the annoyance of working with a full-blown AST, and none of the power that comes with being able to manipulate an AST.

Annotations themselves are pretty great, and AFAIK, they are most widely used with reflection or bytecode rewriting instead. I get that the maintainers dislike macro-like capabilities, but the reality is that many of the nice libraries/facilities Java has (e.g. transparent spans), just aren't possible without AST-like modifications. So, the maintainers don't provide 1st class support for rewriting, and they hold their noses as popular libraries do it.

Closely related, I'm pretty excited to muck with the new class file API that just went GA in 24 (https://openjdk.org/jeps/484). I don't have experience with it yet, but I have high hopes.

How is this different from REST?

I don't understand why you consider this to be a burden. The gateway will calculate the depth / quantities of any query for you, so you're just setting a config option. When you create a REST API, you're making similar kinds of decisions, except you're baking them bespokely into each API.

Query whitelisting makes sense when you're building an API for your own clients (whom you tightly control). This is the original and most common usecase for graphql, though my personal experience is with using it to provide 3rd party APIs.

It's true that you can't expect to do everything identically to how you would have done it with REST (authz will also be different), but that's kind of the point.

Right, my point is that "holding for life" means you never "lose" anything, regardless of how the market performs. This isn't hypothetical for me. I've never sold or traded-in a functioning vehicle (only gifted). You can also purchase used or lease to similarly mute market effects.

News flash: buying new cars and getting rid of them early comes with market risks.

While we're swapping anecdotes, I own several Teslas, starting over six years ago, and have never experienced this. I've also never met a person in my life who has experienced this.

In contrast, I've had recalls from other manufacturers take so long (several years), that my vehicle died before I was able to get them applied. I've had a recall where the OEM is refusing to make it available to me, because it only occurs in "cold" weather.

Tesla's recalls are better than the rest of the entire industry.

You're talking about the MCU (media control unit), which is completely isolated from the critical driving functions of the vehicle. As its name implies, this unit mostly drives the vehicle's entertainment functions. It's actually incredibly confidence-inspiring to me to know that the MCU can go entirely offline and the vehicle continues to function at 100%. This seems like it must be table-stakes for all vehicles, but I've seen more surprising things.

I'm not sure why you mention cell coverage, given that it is entirely unrelated.

"Have you ever seen a bricked Tesla driving down the road?..."

I'm having trouble making any sense whatsoever out of this paragraph. It does not appear to bear any relationship whatsoever to Tesla OTAs. They don't apply while you're driving. The vehicle must be in park and is inaccessible until the OTA has successfully completed. If for whatever reason the update can't complete successfully, the vehicle rolls back to its previous software version.

Driving a "bricked" Tesla isn't a thing. Worrying about not being in cell range isn't a thing. Installing an OTA does not involve any kind of act of "turning the car on and off again".

(Owner of multiple Teslas for 6+ years).

I was originally worried about depreciation when I bought my EV six years ago, because I feared 5 years later all the cars on offer would have 500mi range and charge in half the time.

I realized I generally hold my vehicles for life, (because it's the most cost effective thing you can do), and it really doesn't make any difference what happens as long as I'm happy with the features at the point I bought them. If you don't want to hold onto a vehicle for life, you should strongly be considering used or lease.

Another thing to note is that EV depreciation is being wildly exaggerated. The resale value of my EV is right in line with other comparable ICEs (actually better, depending on the comparison). Most of the misleading reporting uses data from the COVID era where vehicle pricing was wildly whack. At that time I could sell my 3 year old car for more than I paid new - something I had never seen in my lifetime and suspect I will never see again.

This is fake news. The backing study for this claim did all sorts of wonky unrealistic testing to come to this conclusion. If you own an EV, you viscerally know it's BS given that you're the one paying for the actual tire replacements on your real-world driven vehicle.

The author pans meta-tracing and shows a graph of TruffleRuby having really crazy runtime behavior. However, it looks extremely suspicious - like the kind of thing you'd see if there was a memory leak and the garbage collector was running constantly.

Most people seem really excited about the results coming out of Graal and TruffleRuby seems to have some really impressive results in general, so the graph is surprising. It's also missing a bunch of details, so it's hard to speak to its voracity - for example, what are the different versions of the runtimes, what flags were used, on what hardware?

As a counter example, there's a different (admittedly old) result where TruffleRuby beats cruby on the same benchmark by 4.38x. https://eregon.me/blog/2022/01/06/benchmarking-cruby-mjit-yj...

The new LLM-based completion in Intellij is not useful. :(

The author says they do the literal opposite:

"Almost all the completions I accept are complete boilerplate (filling out function arguments or types, for instance). It’s rare that I let Copilot produce business logic for me"

My experience is similar, except I get my IDE to complete these for me instead of an LLM.

I wonder if the first bullet point, "smart auto complete", is much less beneficial if you're already using a statically typed language with a good IDE. I already feel like Intellij's auto complete reads my mind most of the time.

This is a common myth. Most of the pollution of a vehicle is in its use, both for EVs and ICE [0]. The average EV, even on the dirtiest fuel, still has much higher efficiency than the average ICE. On top of that, things are only going to get better:

- more of our electricity is coming from clean (renewable/nuclear) sources every year. We reached 40% in 2023. [1] Solar and wind are dominating fossil fuel in new generation. [2]

- we're evolving battery materials for cleaner batteries, and more new battery materials will be sourced from recycled batteries instead of new mining. (EVs are still so relatively new and batteries live long enough that we haven't yet reached that point).

0) https://www.epa.gov/greenvehicles/electric-vehicle-myths#Myt... 1) https://www.wri.org/insights/clean-energy-progress-united-st... 2) https://www.eia.gov/tools/faqs/faq.php?id=427&t=3

There are other problems besides just being inefficient. In a world where energy is cheap and abundant, you still have to deal with leaks (hydrogen is small, so tends to escape everything over relatively small periods of time) and embrittlement (again, hydrogen is small, so it tends to fuse into other materials and destroy them).

I don't know if these limitations are fundamental, or if we'll eventually come across some breakthroughs that make them economical to deal with, but it's something we've struggled with for a very long time so far.

> If you're running on a simple system architecture,

His point was that even a feature flag system in a complex environment with substantial functional and system requirements is worth building vs buying. If your needs are even simpler, then this statement is even more true!

I'm having a hard time making sense out of the rest of your comment, but in larger businesses the kinds of things you're dealing with are:

- low latency / staleness: You flip a flag, and you'll want to see the results "immediately", across all of the services in all of your datacenters. Think on the order of one second vs, say 60s.

- scalability: Every service in your entire business will want to check many feature flags on every single request. For a naive architecture this would trivially turn into ungodly QPS. Even if you took a simple caching approach (say cache and flush on the staleness window), you could be talking hundreds of thousands of QPS across all of your services. You'll probably want some combination of pull and push. You'll also need the service to be able to opt into the specific sets of flags that it cares about. Some services will need to be more promiscuous and won't know exactly which flags they need to know in advance.

- high availability: You want to use these flags everywhere, including your highest availability services. The best architecture for this is that there's not a hard dependency on a live service.

- supports complex rules: Many flags will have fairly complicated rules requiring local context from the currently executing service call. Something like: "If this customer's preferred language code is ja-JP, and they're using one of the following devices (Samsung Android blah, iPhone blargh), and they're running versions 1.1-1.4 of our app, then disable this feature". You don't want to duplicate this logic in every individual service, and you don't want to make an outgoing service call (remember, H/A), so you'll be shipping these rules down to the microservices, and you'll need a rules engine that they can execute locally.

- supports per-customer overrides: You'll often want to manually flip flags for specific customers regardless of the rules you have in place. These exclusion lists can get "large" when your customer base is very large, e.g. thousands of manual overrides for every single flag.

- access controls: You'll want to dictate who can modify these flags. For example, some eng teams will want to allow their PMs to flip certain flags, while others will want certain flags hands off.

- auditing: When something goes wrong, you'll want to know who changed which flags and why.

- tracking/reporting: You'll want to see which feature flags are being actively used so you can help teams track down "dead" feature flags.

This list isn't exhaustive (just what I could remember off the top of my head), but you can start to see why they're an endeavor in and of themselves and why products like LaunchDarkly exist.

This all resonates very strongly with me. We have tons of automation - the proverbial "economies of scale", but we haven't managed to solve the last mile.

Auto assembly seems like a poster child. There's wild automation going on, but the typical plant still requires thousands of employees doing things by hand. Musk tried to automate a lot more of this away with newer/better robotics, but failed. (Tesla has still achieved a lot here, but it's been more towards creating designs that are more amenable to the current state of robotics).

IMO, this problem should be solvable now. I.E. we don't need "new physics" to reach another step-function in automation. We need more investment. We're still largely in the mindset of "special-purpose" automation.

There would literally be an instant revolution by 50% of the US upon such an act. Let's please avoid the inflammatory rhetoric.

It's one thing to be exposed to varying viewpoints, it's another thing to have a nation state wage propaganda campaigns against you on your home turf.

If 999/1000 tiktoks you see are of one particular viewpoint, you don't think the audience is going to draw specific conclusions? Our species now has mis-information tools that we couldn't have possibly imagined even just a decade ago. We're in the midst of a real struggle to work out how your average person can identify it. It's disheartening how little progress has been made in this area.