While I agree with you, (1) this thread was started when someone argued that Trump isn't a dictator because he was democratically elected and (2) it's _extremely_ difficult to remove a US president from office--so hard that it has never happened.
Presumably that would favor large scale battery storage, right? If large scale battery storage is already cost competitive with turbines and there is still more low-hanging fruit, then presumably battery costs will continue to fall faster than for turbines?
That said, I doubt the cost of either of these technologies is driven so much by the technologies themselves so much as it is our ability to manufacture and install large volumes of them at scale. Presumably it's easier to mass-manufacture batteries in a big factory and then ship them to the site than it is to construct each gas peaker plant on location, and moreover it's probably easier (i.e. cheaper) to scale up the manufacturing process for batteries than it is to scale up the construction process for peaker plants.
> If large scale battery storage is already cost competitive with turbines and there is still more low-hanging fruit, then presumably battery costs will continue to fall faster than for turbines?
Yes, and this is the assumption that the comment I replied to seems to disagree with. I think the assumption is right and the disagreement is wrong.
> That said, I doubt the cost of either of these technologies is driven so much by the technologies themselves so much as it is our ability to manufacture and install large volumes of them at scale.
Deployment is part of the learning curve.
I think you're agreeing with me (and disagreeing with the comment I replied to) here :)
Maybe you think Trump (34 counts of felony fraud for the purpose of concealing another crime, attempted election fraud, rampant insider trading, using the powers of his office to persecute political enemies, creating a secret police force to provoke riots, deploying the military against US cities, aggressive attempts to consolidate power in the executive, etc) is just a man of the people but clearly the CEOs didn’t think so or they wouldn’t have done all that embarrassing groveling at the whitehouse.
If I want to upgrade the disk on my MacBook Pro, I need to buy a new MacBook Pro with a larger disk. If I want to upgrade the disk on my work laptop, I’m SOL.
> Ensuring that diffs to updated dependencies remain within a vendor folder is trivial.
It’s not obvious to me how putting the dependencies in a vendor folder solves the diff problem. Does every code host allow you to hide diffs to certain directories?
And what’s the advantageous scenario for vendored dependencies? Is it just when the mod proxy and the upstream code host go down at the same time?
> If I want to upgrade the disk on my MacBook Pro, I need to buy a new MacBook Pro with a larger disk
Is this a significant risk in reality? MBPs today come with a minimum of 1TB of storage. Even 5 years ago I think the minimum was 256 GB. This is more than large enough for all but the most massive repositories, even with vendored dependencies. And you can always plug in external SSDs or HDDs or connect to a network server.
> And what’s the advantageous scenario for vendored dependencies? Is it just when the mod proxy and the upstream code host go down at the same time?
This is a useful homework assignment. Ask your favorite LLM or consult some respected release engineering books. Also consult your local AppSec and infosec teams.
> This is more than large enough for all but the most massive repositories
Consider the possibility that the drive needs to accommodate more than just a single repository?
I have lots of software, entire language toolchains, AI models, Docker images, application volumes, VMs, etc.
And this isn’t a theoretical concern; I have to free up space every few months.
> This is a useful homework assignment. Ask your favorite LLM or consult some respected release engineering books. Also consult your local AppSec and infosec teams.
So there is no advantage scenario that you’re aware of?
Has this ever been necessary/useful? Genuinely curious because I’ve been using Go since 2012 and can’t recall a time when vendoring solved a problem better than “regular” modules. Like have there been times when the source went down and the module proxy went down (or didn’t have your dependency cached)?
> It's sorta a shame that Go keeps doing such a good job at a minimum-viable wheel-rewrite, but then lets it linger for so long without catching up to the rest of the programming world.
How many mainstream languages have content addressed imports? I can’t think of any, so I assume I’m misunderstanding your meaning of the term because you seem to be suggesting that it is common and Go is the outlier for lacking it?
Go is not really an outlier for not having signed packages (there are a fair number that have it, but far from most)... but definitely stuck behind common accepted practice. By decades, if comparing against some (e.g. Java).
Which keeps happening with stuff they rebuild from scratch - an excellent and somewhat unique first showing, far beyond what most first attempts manage, but followed by near-complete stagnation while issues that everyone familiar with the field predicted from miles away pile up.
Coming from the Java side this is typical of Google libraries. They start off impressive and gain wide adoption but then they stop supporting changes the community wants, missing basic features.
Yeah, it still very much tastes like Google in many of the worst ways :/ clearly Google isn't actually running the project, it's far too well run for that, but the same general "why would anyone need [that thing nearly the entire open source world does outside Google's monorepo]?" ignorance pervades a lot of it.
Which is a shame because there is quite a lot to like about Go in practice. And in spite of it all I'm thrilled that it is eating into Python's share in a lot of places.
> I personally feel the chances are slim that "familiar programming concepts" (i.e. as taught by most intro CS courses) are optimal by themselves.
On the other hand, Erlang has been out for ages and has largely failed to attract much adoption, so it doesn’t seem like the market finds it to be “optimal” either. Not that popularity is everything, but over time a language better languages should increase their market share, especially if your language got its start during an era where the competition was C and C++ and Java.
> And I know it's an old thing, but the fact that Go was once adamantly against generics...
Erlang not only lacks generics, but it lacks any static type system at all…
Rather than entire languages, I'd say that feature adoption is more likely the better indicator. Like generics, first-class functions, lambdas, error-handling (I'm partial to monads like `Result`), etc.
If one wanted, they could put ecosystem tooling here as well (e.g. `gofmt` saving everyone time and mental health).
Also, to clarify, I'm not arguing that Erlang > Go, I don't (purposefully) use either, though I have to read Go sometimes.
> There is no proper way to cancel them, they need to cooperate via select/context
Isn’t this also true of threads? I know you can usually cancel them from a thread handle, but that kills the thread ~immediately without cleaning anything up, right? Presumably you pretty much always want cooperative cancellation?
It's true for almost all pthread implementations, not all. But when talking about asynchronous I/O runtimes and coroutines, you have more options. Systems like Tokio, or zio (the one I'm working on), give you a task handle, and when you call `cancel()` on the handle, it will cancel whatever async operation the task is currently running. And it does so reliably.
These things were all known when development on Go began. But, as with so many other aspects of the language, if it wasn't known in the 80s/90s then it may as well not have existed.
I don’t know why people criticize Go for not being a cutting edge research language when that was very explicitly not the goal. Lots of things were available in the research at the time, and much of that has gone ~nowhere.
Starting with what they knew to work and iterating from there is wise.
reply