throwaway894345

Lol this seems like a very believable and normal thing for a Knowledgeable Person (TM) to say

> 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?

> Disk is cheap

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?

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)?

Go defaults to using a caching proxy, but you can use your own too.

> 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?

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.

> 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…

> 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?

I think we mostly disagree about whether "dumb assholes" is a boolean or continuous variable.

Nah, they're independent and they've swung pretty hard away from MAGA once it affected their personal finances. Far from noble, but also pretty far from MAGA.

In the case of my country, USA, we are the ones wounding ourselves. We made the conscious choice to elect a government that prefers isolationism to economic competition, and which rejected near-peer military preparedness in favor of more deadlock wars with third world middle east countries. It’s not like we were somehow victimized by the EU.

American here. Only a third of us are MAGA. Still plenty to ruin our country though.

If rather see the US stop self-sabotaging by destroying our relationships that established us as the monopole.

I’m an American, and I don’t see it as a purely political game against Trump—my country has dramatically shifted its position toward its allies from reliable partner for 80 years to aggressive antagonist both in trade and military. And it’s not just a rogue president—a full third of the US electorate supports these actions.

It makes sense to me that these countries would want to build new trade and security alliances with countries who have similar interests and who face similar threats.

The alternative to these defensive military pacts is that Russia or the US or whomever can literally invade and annex countries piecemeal to expand their power. If we can’t effectively ban that, then it doesn’t make sense to me to ban the only thing that deters it today.

I'm not disputing that X has a legal right to monetize the content, but I am not remotely convinced that (1) X has the _exclusive_ legal right to monetize the content (content creators add no value and thus have no right to the content, which seems obviously absurd) (2) X has the exclusive legal right to prevent others from distributing the content for free or (3) your "network-effects-derived moats justify a legal right to monetize content".

You seem to be depending on a whole lot of assumptions to get to your "XCancel/Nitter/etc shouldn't be allowed to exist" conclusion.

I’m very sympathetic to this point of view but I also can’t remotely afford the hardware required to get in the ballpark of Fable.

> absolute order requires very precise time synchronization which is hard

Presumably relativity is the reason precise time synchronization (and thus absolute ordering) is hard.

Your comment seems to implicitly assume that X has some ethical claim to the content they're monetizing, when in fact they're trying to monetize _others'_ content.

Widgets are just apps with limited scope and surface area. There’s no reason they can’t apply this to the weather app which already has (or should have) a limited scope.

Even before AI the trend was moving toward increasingly static languages (JS->TS and even a lot more typed Python). Once you accept the static typing benefits, you start to wonder if you could leverage the constraints to drive performance improvements.

Widgets can't have vulnerabilities?

If I was writing no-alloc production code, I would stick with Rust, FWIW, at least until Go's library ecosystem improves.

I don't mind writing Rust (have been dabbling with it since ~2014), especially with some AI assistance. It's just more of a grind for me than working with Go.

> Considering the effort involved in coding in such unnatural Go variant,

I was also expecting writing Go in this style to be more friction, but it was surprisingly smooth. The friction was entirely from lack of libraries and a little uncertainty about how to communicate errors without allocating. Rust has better libraries by far, but I felt more friction from the language (e.g., if you have a buffer you have to initialize every element of it or you have to use something like `heapless::Vec`--not a big deal, just decisions to make to figure out what the happy path is).

I touched OCaml several years ago and ran into a bunch of problems with build tooling, standard library, syntax noise, ideological/unhelpful community, etc that turned me off. I'm also just not experienced enough to write OCaml without a GC; that would be biting off a lot of learning.

A decade ago we would hire them fresh from some Ruby on Rails bootcamp so we could pay them less :shrug:

The lock screen widgets don't tell you much more than what you can get from looking outside. It's not very helpful to know that it's currently overcast and raining, but it would be a lot more helpful if I could know when the rain is supposed to stop or what the week's forecast is and so on.

If the app doesn't have any sensitive information, then yes. We already do this with home screen widgets today, so clearly there's no real barrier.

I've been having _a lot of fun_ writing Go apps that don't allocate anything and that use small, preallocated buffers to stream through requests/etc. Basically TigerStyle for Go. I don't use arenas, I just size everything for the worst case (or make the sizes configurable at startup) and still end up using much less memory.

This is really only possible because I told Fable to build the underlying allocation-free HTTP, JSON, etc libraries and consequently I'm not building anything serious yet (although the libraries are well-tested using pre-existing corpuses from reputable projects e.g. curl as well as fuzz tested).

Most "outputs" are passed as out parameters for the function to fill in, and results are Rust-like enums (a Go tagged union containing only small data). I could also have returned (T, error) but I would have to take care that the thing I pushed into the error argument doesn't allocate--not sure if I made the right decision or not, but for now it feels nice. The worst part is that I don't really have a good way to communicate detailed error information, but that hasn't bitten me yet.

This has also been a lot less effort than writing Rust, although Rust would have real checks for lifetimes and im/mutable and enum exhaustiveness and so on--so far I haven't been bitten, and I suspect things like enum exhaustiveness can be addressed via linter if necessary.

Unrelatedly, I'm still trying to figure out why Apple requires me to unlock my phone to look at the weather. Is there some concern that someone could pick up my phone and learn what city it is in?

As an American, I wonder if Trump succeeds in giving away so much of America's economic and military power to other countries, will it make America a less interesting target for corrupting interests? Maybe the billionaires and foreign governments will invest less money in corrupting our system if it's not the global hegemon?