Garfield’s version seems more complicated since you have to calculate the area of a trapezoid instead of the area of a square, but conceptually they are the same.
> code.google going away, without the excuse that google itself was going away, after I had started to rely on it and link to it in docs and scripts all over the place
It didn't go away, though. It got archived and that archive is still up and running today. Those links you put all over the place should still be working.
> If google had said "The purpose of this service is an academic goal of Googles, not to serve users needs. This service will be shut off as soon as Googles academic purpose is met." I would not have used it.
That's not an accurate representation of what DannyBee said. Moreover, what DannyBee did say is in line with what Google itself said was its goal when the service launched: https://support.google.com/code/answer/56511
"One of our goals is to encourage healthy, productive open source communities. Developers can always benefit from more choices in project hosting."
> Effectively, Google harnessed users for it's own purposes without their consent by means of deception.
This does not appear to be a good faith argument.
None of what DannyBee said in their comment aligns with that interpretation. Neither does that interpretation line up with Google's publicly stated goals when they launched Google Code.
Yes, there is a difference, but one thing you should do when you see this difference and think it is critical consider whether you are parsing words way too strongly in a colloquial discussion on hacker news.
I'm trying to participate in a discussion. Not write comms that go to hundreds of millions of people. That is why the rules of hn are very clear on assuming the best, not the worst.
"It didn't go away, though. It got archived and that archive is still up and running today. Those links you put all over the place should still be working."
I think this is misrepresenting what the commenter stated. He appears to have stated the project hosting service "went away". This fits with the context of the OP which is comparing project hosting services, e.g., Google Code, Sourceforge, Github.
If the context was software archives, e.g., software mirrors, instead of project hosting, then we could indeed claim "Google Code" still exists. However, the context is project hosting. And no one can upload new projects or revisions to Google Code anymore. Google Code project hosting did in fact "go away":
He made that claim but then conflated it by talking about "those links being gone" which isn't true.
I'm going to defend Google on this. They don't need to maintain products forever but this case is a good way to shut down a service. Allow access to existing projects but make clear that active projects need to go somewhere else. The commenter can be upset that they can't use Google Code as a product but they shouldn't misrepresent the situation by saying the code is inaccessible. I checked a university project I created 15 years ago and it's still there. The commenter is objectively incorrect.
> Too much indirection
I don't think this is a valid criticism. The web is designed explicitly to do this. You can still access the code, that's good enough.
Sometimes businesses do things that they believe to be in their own self-interest, but is not.
Sometimes businesses do things to create good will (which has tangible value).
Sometimes businesses do things which destroy good will and create animosity (which has a tangible cost).
Google seems to have managed to have accumulated significant animosity by shutting down services that could instead have been left to die a slow death on a long tail. I still remember a time when I could plausibly believe that "Google Is Not Evil". Shutting down those services prematurely when people still depend on them is evil. That's the cost.
And, by the way, sometimes people do things for no other reason than because it is virtuous to do so. I suppose Plato does make the argument that you should do virtuous things so that you can hang out with other virtuous people, and not have to put up with *ssholes. Darwin would probably argue that people do virtuous things for free in order to increase the survival rates of their progeny. But those are both deep and nuanced arguments that are best left to incurable pessimists.
The web, i.e., HTTP and HTML, is designed so that Javascript is not necessary to redirect URLs or publish direct download URLs. But here a $2 trillion online advertising company tries to coerce the computer user into enabling Javascript for basic redirection.
Sure, but this is the danger you get when you rely on an outside vendor's service for anything. If you don't want to deal with this danger, then you should never, ever use an external vendor's service for anything; you should only use your own self-hosted solutions.
Of course, Google does have a worse track record than some when it comes to their services being EOLed if they aren't search, Maps, etc., but still, this can happen with anything: it can be shut down, or bought out by a competitor, etc.
>Also, "Google sunset their project really well" is damning with faint praise.
I don't think so in this case. I'd say Google has done a poor job of sunsetting other projects of theirs, but if this one actually keeps all the links alive albeit in read-only mode, that's really a lot better than most other EOLed or shut-down (like due to bankruptcy) services (from Google or anyone else), where it just disappears one day.
> Of course, Google does have a worse track record
Yes, that's the point of the above comments. The repeated lesson is that there's always a risk of shutdown, but don't trust google in particular to keep services running.
You have to "be a lawful permanent resident at the time of your naturalization interview" [1]. (On the other hand, you're eligible if "you served honorably in the U.S. armed forces for at least one year at any time.")
Proposal is that anyone can enlist, e.g. at the border.
Flooding your military with people who have no conception of the values and history that underpin your society seems like a really bad idea to me.
I do like the idea of military service as a route to citizenship though. But literally just signing people up at the border seems way too problematic and dangerous.
> I do like the idea of military service as a route to citizenship though.
A lot of Filipinos went this route in 70s or 80s (hazy on timeline here). They enlisted abroad as well, although I guess it’s a different situation when another country has Us navy bases.
In Starship Troopers (the book), I'm pretty sure the ptoagonist (was it still Rico?) was Phillipino. Almost wonder if Heinlein might have drawn on this episode as inspiration for his ideas around service for citizenship.
> Flooding your military with people who have no conception of the values and history that underpin your society seems like a really bad idea to me
I agree. I assume we'd use foreign recruits to make up for domestic-recruiting shortfalls. The lack of knowledge of our history can be fixed with education; values, with selection criteria. I wouldn't be surprised if these immigrants turned out not only to be great fighters, but among the more patriotic Americans.
Alternatively bringing in a flood of foreign fighters who can be abused and extorted into doing dirty deeds by politicians holding an extremely lucrative carrot (US access) and stick (deportation) sounds like a recipe for abuse of the soldiers, and likely anyone they’re deployed against.
Considering the history of the French Foreign Legion, I’m disinclined to believe in the best possible outcome here.
Between a quarter to a third of the union army was foreign born during the civil war (while the broader population was only about 10% foreign born).
That’s not to say all of them were non-citizens but the Union went out of its way to recruit abroad.
The scene in Gangs of New York where fresh off the boat immigrants were signed into the army was realistic. We have a long history of using freshly arrived folks in our military with no major problems.
I don't know enough about that to open my mouth much on it, but I'd say civil wars are a special case given they are often fought over specific principles, ergo, have a certain natural selection.
Further, you're talking about a time in America's history where standing armies were dispreferred, which is not what modern American militarism looks like at all.
Finally, as far as "foreign born" people go, as I said, I support the idea of military service being a route for them toward citizenship, I just don't think going down to the border and signing people up there is a good idea.
I think one interesting idea, although you might only be able to do it as a once off without creating too many bad incentives, would be to offer amnesty and a route to citizenship this way.
I don't have a dog in the fight though, I'm not American. The risks of making joining the armed forces a direct route to citizenship in one of the most desirable countries to immigrate to in the world is not negligible though, you need to be careful, lest your armed forces turn into green card mercenaries, with no value base.
The rest of the world is far more aware of American values and history, thanks to America's cultural imperialism and military hegemony, than the average American is of anything outside of their borders.
That's an extremely low bar given many of the Americans I've met.
Even in a comparitively similar country like Australia, where I live, Australians have a hard time understanding many basic American values, particularly political ones, in my experience
You can add test as requirement and pick top contestants, and you will have recruits who know American history, values, constitution etc better than Americans.
While I agree that many people would do well to have the kind of civic background knowledge they demand people acquire to gain citizenship, and it's an important part of integrating people into a society, there is also a lot that is acquired by living in a society for a time, experiencing and observing its contradictions and how it manages them personally, understanding how you navigate it and your place between two or more national identities and experiences, etc.
That said, I think there's a place for inviting people in. In America's case though, it seems like there's a huge reserve of people already in American society, both legally and illegally, that can be drawn on first. That to me seems like it should be the priority.
> experiencing and observing its contradictions and how it manages them personally, understanding how you navigate it and your place between two or more national identities and experiences, etc.
and serving in navy for 4 years is much smoother experience compared to green card lottery winners who are left on their own
> it seems like there's a huge reserve of people already in American society, both legally and illegally, that can be drawn on first.
I think the point is that reserve is not huge, because appeal is not that strong for those who are already in the US, hence navy drops requirements standards.
An extremely small outfit with extremely high selection criteria and a gruelling recruitment process, that's specifically structured to handle foreign recruits, and drills them extremely harshly in French language. Which offers a citizenship, that while nothing to sneeze at, is regularly not even taken up by some of its soldiers after they serve.
It's not a viable comparison to signing people up at the border to get US citizenship on any level.
However it could act as inspiration for any efforts to found a similar outfit in the States.
That's a really good point, although I think the smallness matters more in absolute terms, than relative terms. Both examples show that you can maintain a large foreign presence in your military though. The French Foreign Legion is highly, highly, selective though.
I don't know much about the Ukraine foreign legion, but being in an immediately existentially threatening conflict is a special case. I doubt the Ukrainians would wish for such a large foreign legion if they had the choice, although again, I don't know the history of its numbers prior to the war with Russia.
I have no damned clue how they made it work, but I had several illlegal-as-children immigrant friends manage to get into the military and earn citizenship. Perhaps there was an Obama era program?
Any argument of the form “if you knew that all along you’d be rich by now from playing the stock market” is fundamentally flawed because it overlooks one of the most well known dangers of the stock market:
“The market can stay irrational longer than you can stay solvent”
It absolutely was obvious ahead of time that most of the competing streaming services would fail because they couldn’t possibly recreate the infrastructure of Netflix, but it was not possible to predict when they would fail.
For a concrete example, before Paramount+ launched I predicted that it would be dead in less than a year.
Clearly I was wrong because it’s still going 2 years later. I still think it will die relatively soon, but predicting exactly when is virtually impossible.
This looks innocuous. It lets them consolidate cases of “substantially similar nature brought against either party by or with the assistance of the same law firm, group of law firms, or organizations.”
Each side picks eight cases while the others are held. Once those sixteen are decided the rest are resolved, collectively, taking those sixteen cases’ resolutions into account. At each step, you can dispute the characterisation, and Zoom pays the arbitration fees.
Dependency injection frameworks are a horrible idea.
They optimize for the wrong thing; making code easier to write but harder to read and edit.
Writing code is a one time cost whereas reading and editing it is an ongoing effort, so dependency injection frameworks are optimizing for the uncommon case at the expense of the common case.
Compile-time dependency injection frameworks are a big improvement over runtime dependency injection frameworks because you can at least read the generated code, but they are still a lot worse than manual dependency injection when it comes to editing code.
This has not been my experience with dependency injection frameworks in C# at all. You know what happens in a large code base when you tell all of the developers to do manual dependency injection? They don’t do it and instantiate their dependencies in the constructor because it’s easier.
So deterministic instantiation then, which I as a (predominately C#, currently) developer actually prefer - I find it much easier to follow unfamiliar code. But whatever work for your team ...
I work in a large code base where we've told all of the developers to use dependency injection frameworks.
We are now using a mixture of 3 different dependency injection frameworks, manual dependency injection, and instantiating dependencies in the constructor.
I'd prefer what you describe, because I would still be allowed to fix it (change it to manual DI).
I usually write manual DI when I want to iterate on the system and make sure each part does what it's supposed to.
Then once it works I convert it to Joe Armstrong's gorilla-holding-the-banana-and-the-whole-jungle (framework DI) so it gets past code review, and I hope to never touch it again.
I recognise that DI frameworks may have a place when working with large teams and large applications, but otherwise I discourage them for a few reasons.
The prerequisite knowledge problem:
"Manual" DI requires knowing the language. Framework DI requires knowing the language and the framework. This alone makes it harder for new people to approach the codebase if they have not familiarity with the framework, even if they have mastered the language. There are already several DI frameworks for golang, but which ones are your new hires familiar with?
The "how do I do X" problem:
If you want to do something with your dependency graph, it's usually straightforward to express with plain code, but it might not be immediately obvious how to accomplish the same with the framework. For example, having multiple dependencies of the same type. With "manual" DI this is totally unremarkable. With wire, it goes against its mechanism and requires a minor workaround.
The implicit graph problem:
A DI framework the frees you from having to think much about the dependency graph may cause you to accidentally create a messy, illogical graph. It's easy to end up cornered by dependency cycles, for example. With manual DI, a flawed graph is more obvious early on because it's code you have to read and write. Explicit, not implicit.
It's a pretty big assumption to say DI makes code harder to read.
Personally, a decade and a half ago I felt like it was pretty easy to understand what I was working with. I'd hope observability has improved since, that there's been further improvement.
There's a horrible reputation for DI, people with old scars, that seems like there's no escaping from. But my workplaces had a great time using a variety of DI tools, again and again. We got great monorepo code sharing across numerous projects & easy to understand parts. My experience has been great. I want to keep asking, what would make folks reconsider their negative attitude?
For me, it would take at least one positive and significant experience.
I would probably need to work on a team where at least some of my teammates had some mastery of the framework, including knowing how to use it effectively in the long term.
I could understand if the environment would depend on network loading speeds, and having to lazy load and cache/inject dependencies only when they are actually used (like in the Browser).
But with go as build environment this kind of contradicts everything that go is good at, so even after reading I'm asking myself for a legit use case for dependency injection in go (other than malware development or hijacking a loaded DLL of another program).
Not sure if I agree they’re horrible, but I think you should put it off until you really need it.
I disagree that they optimize for write: a DI is quite easy to real, but hard to debug. Adding @Inject(databaseHandle) makes it pretty clear you’re getting a handle to your database. That’s easy to read. When the database handle doesn’t work, suddenly it’s hard to debug.
I also disagree with others that it’s harder to learn. You can barely know a language and understand that a library is auto-magically injecting that database into that variable. New users can pretty quic Write code that relies on existing injections or copies other examples and it’ll usually work without flaw.
The problem with DI is when you exit the happy path: it’s really hard to diagnose what is failing, and the implicit ordering make it hard to figure out quickly. This could be worth it to reduce a ton of boilerplate on a large and mature monolith, or to speed up an agile team, but it could just give you one more thing to endlessly tweak and change.
I despise "magic" but DI has worked incredibly well for me for years. It almost always "just works". Even my homebrew DI framework I coded up in a couple of days worked extremely well. They're not that complicated. If you only have one instance of each object type it works nicely. If you need multiple then you need a bit of magic to pick one but even that isn't bad.
Thank you for this. I'd even say that dependency injection frameworks eliminate the most important thing of dependency injection: explicit dependencies.
Is still a class you can't instantiate without a correct instance of the given type.
(If you're talking about field injection, then I agree, that is the devil and must be purged with fire. Constructor injection or none.)
And when there's multiple instances of a given type available, a good framework refuses to guess. And I really like compile time DI for surfacing these errors far quicker than the traditional runtime approaches.
DI frameworks always make me deal with way more of the system than I want to.
I want to just be able to 'new' any class in the system, and start playing with it under test.
When I try to test a Parser class under a framework DI, it ends up instantiating the most fiddly bits of unrelated crap. I get null pointers in the database config, which had nothing to do with what I wanted.
It can be controlled, by adding even more annotations and mocking frameworks. But I'd rather take out annotations rather than put them in.
I disagree that they make code harder to read. It's the opposite in fact in my experience, especially with the prevalence of mature IDEs that allow you to navigate the graph and injection points. It's quite a nice experience.
Garfield’s version seems more complicated since you have to calculate the area of a trapezoid instead of the area of a square, but conceptually they are the same.