HN user

tyrankh

118 karma

Software Engineer at Google.

Posts2
Comments40
View on HN

https://www.apple.com/ios/ios-13/features/ new redirects to https://www.apple.com/ios/ios-14/features/, which seems like an unnecessary hacky way to get your SEO up.

Separately: is it just me or has Apple lost its innovative edge? Widgets and app drawer, that's the huge new update? Android has had these for, like, 5+ years.

Not that android has had anything super exciting lately, either. Maybe phone OSes have kind of implemented most of the obvious great features, I guess.

They were doing fine until Chrome ate up all the market share.

Like, 10+ years ago...?

Google is destroying Mozilla. Their monopoly is making the web worse.

What in the heck are you talking about. Google doesn't directly make money from Chrome - it's free!

In fact, Mozilla's bills are being paid in large by Google paying for them to use google.com as the default browser.

Mozilla has always struggled to make money. This is not some new phenomenon with the company, and certainly is not because of Google making a good browser.

Google shouldn't have been allowed to do that. It's very anti-competitive for them to have a browser that defaults to Google search and disables plugins that support adblocking.

I mean... what? They shouldn't have been allowed to do that... because why? Because a browser defaults to a specific search engine?

C'mon now. Google built a great browser that users loved, and they flocked to it. It was faster than all the competitors at the time - including firefox - and had much better word-of-mouth traction. Firefox always had a "techie expert" connotation back in the day, and it bit them in the butt when it came to the average joe deciding which browser to use.

End of story.

There's no sinister anti-competition plot here. For heaven's sake, Google pays loads of Mozilla's bills, and collaborates with them on loooooads of projects!

I think this post summarizes to,

- I don't like the file-related packages

- What's up with this random 7 star library having a lot of transitive dependencies

- Rust for life

- In summation, Go is the worst

This is ludicrously false and not at _all_ why Google hires people. They hire people because - big surprise - there are projects that need staffing.

"At this stage, if Google hires you, you are almost certainly being used to aid in the retention of somebody else. You’re going straight for the bench."

I mean, just wow. Do you really believe this? This is fantasy to an incredible degree.

Maybe that's what vgo needs, a way to specify a conflict bound

This is a valid idea; you should make a proposal or issue for it. Alternatively, it seems like something that would be easy to add separately - I personally like the idea of vgo as more of a simple, unix-like building block that you'd build on top of. Adding a small utility CLI checks incompatibilities with `vgo list` + some incompatibilities.txt file would be pretty easy.

Preface: vgo _specifically_ calls out the fact that maintainers of libraries have to be backwards-compatible within a major version, and that the onus is on users to put their trust into libraries not to break them appropriately:

Modules are assumed to follow the import compatibility rule—packages in any newer version should work as well as older ones—so a dependency requirement gives only a minimum version, never a maximum version or a list of incompatible later versions.

(https://research.swtch.com/vgo-mvs)

Back to the article - it seems predicated on this scenario:

“Our project depends on X@v1.5.0 right now, but it doesn’t work with X@v1.7.0 or newer. We want to be good citizens and adapt, but we just don’t have the bandwidth right now.”

If your deps + your transitive deps for some package are:

- 1.5.0 (you)

- 1.5.1 (some transitive dep)

- 1.4.7 (some transitive dep)

vgo will choose 1.5.1.

However, if your deps for some package are are:

- 1.5.0 (you)

- 1.5.1 (some transitive dep)

- 1.7.3 (some transitive dep)

vgo will choose 1.7.3 and presumedly your app will break.

In other dep managers, you might specify <1.7.0. How would this work? Grab two versions of the package (1.5.1 and 1.7.3), rewrite the import paths of the stuff that requires 1.7.3, and kind of opaquely have two version of the same thing? Or perhaps modify the way the import "xyz" works to be more opaque to solve this problem somehow? There's no nice solution to this.

This seems a fairly reasonable tradeoff; on the upside is a _very_ fast, very simple, and very predictable dependency manager. On the downside is that I have to really think about which libraries I trust not to break me instead of relying on my tool to specify ranges and the like.

Generally though, the ask from vgo is that folks care about backwards compatibility and think about trust, rather than covering up the issue. It's not going to be great for everyone, but I like the straight forwardness of it.

Couple of quick notes from my phone, as a googler gopher:

- IIRC package management was historically left to the community to solve for, rather than the go maintainers mandating how package mgmt should be done. Many languages have followed this model. I've never heard of it having to do anything with our mono repo model. The community never ended up standardizing on a model; since then, the go team has endorsed godep as the official experimental package manager, whose learnings were used to design vgo. Vgo is very new, and still being iterated on; check it out though!

- vgo removes the need for GOPATH

- There is a one-line installer to set up your env. It's very useful and simplifies a lot of what this blog talks about.

Sorry I don't have links - on phone at airport! All the above should be easily googleable though! :)

It is. It removes the color and nuance from typed communication. There's a lot of metadata in typos.

Oh puh-lease. Are you seriously trying to argue that TYPOS are the anchor upon which genuine human interaction hinges on?

I mean, wow. If you're trolling that's amazing.

I am far more afraid of technology we can't control that works for an ad company, not for us, than moving technology forward a little bit slower.

I'm not sure what you're arguing for - that you wish companies weren't driving technological advancement? That Google specifically shouldn't?

Also, it's very, very conceivable that there are people for whom this technology DOES work for. The mute, for example. I'm not sure it's appropriate to speak for all of "us".

What I can see is a bunch of ways to avoid human contact including no longer calling people like a real human or not even choosing my own words in an email.

Auto-complete is hardly "avoiding human contact", is it?

Regardless, these features are all optional - if you feel as though you're avoiding human interaction by using auto-complete, why not just... not use it?

Go's New Brand 8 years ago

I read the "brand guide." It's exactly what I expect from a professional design firm: meaningless noise, carefully typeset.

It's not helping the discussion to disregard an entire profession. Re-read what you wrote; it is _extremely_ heavily biased, angry venting at some corporate construct you've invented.

at least it had some character, which likely comes from the talent of a real artist.

This is just mean.

Go's New Brand 8 years ago

A clear nod to the linux penguin. And a secret totem to those who have been initiated. A hieroglyph for the high priests. No text necessary.

That's... looking into it quite a lot, isn't it? It seems like just a playful mascot.

I'm not trying to be facetious, but isn't this something you learn in junior-level stats? I had this drilled in in both undergrad math courses and grad machine learning courses; I'm confused to see it warrant an article.