Merovius

I was referring to this sentence:

> The only risk I can think of is: if you push too hard, it can have the opposite effect of making the child hate it.

That seems like a weird "risk".

No, I'm suggesting that we shouldn't push for kindergarten kids to read and analyze Shakespeare, because reading is so important (and in the process de-emphasize other subjects). I'm saying that the level of math education happening early (though I can only speak for my home country) is fine, just like the level of reading education happening in the early years is fine. It is completely okay to only reach Calculus and math as a structural science in your late teens and believing that you can teach that widely to kindergarten kids just doesn't work out particularly well for anyone.

I find that a pretty strange approach to parenting. IMO you should optimize for happiness of your child, not for carefully manipulating them into the path you laid out for them. My perception of a good parent is to encourage your child to discover and pursue their own passions, even if they contradict yours. You can open doors, but they need to walk through it by themselves. YMMV.

> First, 16 is still pretty young.

Depends on what we are talking about. The post I was responding to was talking about "the first years of education" and with 16, we are way past that.

> Maybe I'm wrong, but I have always believed that if you want people to be good at math, it's their first years of education which are important, not the last ones. In other worlds, push for STEM should be present in kindergartens and elementary schools. By the time people go to high school it is to late.

I indeed believe you are wrong. I started getting interested in STEM when I was 16 and now have a masters in math on the one hand and work for one of the most prestigious Tech firms in existence on the other. Meanwhile, when I was young, I was encouraged to enter creative fields (mostly writing in my case) which I did have enthusiasm for but then dropped as a teenager. So I switched at least twice, what I wanted to do with my life and still turned out fine.

Honestly, the whole "you need to get them when they are young" idea never convinced me very much. It's never too late to learn a thing and often you need a certain age to actually appreciate something. You don't have to be a childhood prodigy to be good at something.

I rather find the idea pretty harming; I've met a lot of people who did not pursue the career they wanted, because they bought into the myth, that you need to start programming at 6 to get a job at a company like Google or Facebook.

Let kids be kids for a while. Don't worry, they can always figure out what they love later and it's never too late to reconsider.

It would be fair if WSJ would be asking for that. I agree, that if I already pay for a subscription, the results should be ranked accordingly for me. There is probably a simple, technical way to implement that.

But AIUI this is not what WSJ is requesting here. They want free ads for their product ranked high in the search results.

As a user, if I search for something, I want to get the information I was searching for, not an offer to buy that information. A link to a page where I can buy your product is not a search result; it's an ad. And it's totally fair (and possible) for WSJ to be required to pay for their ads on Googles result page, just like everybody else is doing.

(Disclaimer: Working for Google)

Of course they have that carte blanche, at least if you are not a citizen (and since you are travelling internationally, I'd assume that you're not a citizen on at least one of the legs). Normally, they can ask whatever the eff they like to decide whether to grant you entry or not.

The logical conclusion here, is to decide, what is more important: Gaining entry, or keeping your data. In the first case you're just fucked. If you get searched, you have to give up your stuff (even if you can claim you can't; they can then just not let you in). In the second, just encrypt your shit, rescind your request for entry when it looks like they might be interested in you and don't give up your password.

HN makes this much too complicated, again. And forgets that this is a legal and social problem, not a technical one.

> In 2016, Philip Koopman of CMU discusses that there are non-trivial engineering challenges of achieving safety in NHTSA Level 4 vehicle automation:

That seems like the most obvious statement I've read in the last year or so at least. I think the fact that Alphabet spent more than 10 years developing these self-driving cars already is a pretty strong indicator that there are non-trivial engineering challenges involved.

I don't know. I'm annoyed by sites doing that too, but I don't think the author appreciates the complexity of the issue. Two examples:

They choose Google search results as an example; but when I'm in the Netherlands, I definitely don't want them to exclude the website of a Restaurant or Tourist attraction from the results, just because I don't speak Dutch. That's what Google Translate is for, after all. On the other hand, when I Google for Recipes, maybe don't show me Dutch results even if I'm in the Netherlands; I might be able to have them translated, but I think there are enough English or German recipes for Tomato Sauce too that wouldn't need to go through this extra layer of indirection. So there definitely is a correlation between language settings and Geography - in some cases.

I'm also dissatisfied with Accept-Language. For example, I speak both English and German well enough that there isn't a huge difference in comprehension. If I just set Accept-Language to English and German with q=1, and visit pages of a German, a US and a Spanish University (assuming all three of them have all languages available), they should behave very differently.

Now, let's complicate things by throwing politics into the mix; choose the wrong language or show the wrong results and suddenly you are offending one subset of people or the other.

Languages, Countries, Politics and Humans in general are inherently messy and complicated. If you see a problem that has to do with any of those and you start a sentence with "just do X", then it is very likely that your Engineering brain is oversimplifying things (and also, FWIW, you are showing your privilege in not having to consider that other people might work very differently).

> Switzerland is trilingual.

*quadrolingual

Don't forget about that pesky Romansh ;)

No, it wouldn't require special-case syntax. It could just pass it's argument to '/bin/sh -c'. You'd have to shell-escape the pipeline, though.

But it makes a philosophical difference to the involvement of the company, of the people working on it and also a practical difference, because products and non-products have very different launch-requirements. You are perceiving Google as far more monolithic, than it really is; the difference between a product and a non-product is how different employees of the company interact. To the outside world, that might or might not have any meaning. But I feel for the original comment that I replied to, it does.

There is a difference between "a Google Product" and "Code to which Google holds copyright". Most importantly, the latter may include all code written by any Google Employee during their employment.

Several questions, some minor, some major:

AIUI, the keyserver is centralized in two regards: a) if it's down, I can't access anyone's data and b) it centralizes trust, key.upspin.io has complete control over which key belongs to which person and where the data is, so it can just take over accounts. Why not use a federated model, e.g. putting the directory into the DNS or have the directory server listen on a well-defined port or something? Or, if you want the usability of not having the E-Mail hoster necessarily deal with upspin, do the federated thing first and if that fails, fall back to the centralized keyserver?

There seems to be a 1:1 mapping of usernames to keys, meaning I have to share my private key with all my devices. If one device gets lost or compromised, I now have to revoke my key and rotate it on all devices. Why not putting in a 1:n mapping of usernames to keys, so that each device gets its own key?

Why store the upspin-specific keys in ~/.ssh? I won't use them to ssh anywhere and there already is a perfectly fine directory ~/upspin for upspin-related data.

The way sharing works means, that storage for a file grows linearly with users that a file is shared with. This would seem to preclude from sharing files with large non-public audiences (say, I have a group for all employees of my company, or members of my hackerspace, or attendees of a conference…).

It's not a Google product. So no. (not that I'd agree with it not adhering to those roots currently. Just that this project has nothing to do with company policy)

> It was unfortunately obvious that the writer had insufficient tech chops when use the phrase

That's a direct quote from the linked page. Unless you are suggesting that the authors of fuchsia have "insufficient tech chops".

Have you looked at vimeos business model? It is the opposite of youtube. On the latter, you get paid for uploading videos, on the former you pay for uploading them. And you pay quite heftily and even their most expensive option, from what I can tell, can't sustain even a moderately large youtube channel.

> the weak typing

What do you mean?

> nonsense around no-generics

What nonsense?

> error-prone switch statements

What makes them error-prone?

> lack of control-of-the-language

What do you mean?

> not large. Service-units in a large system, sure, which is likely what many will use it for, but it's just not friendly to millions of lines of code and tens or hundreds of developers.

There are go-projects like this on github. Not to mention the fact that several large companies run central parts of their infrastructure on go (I recently started working on a go-project that qualifies). I think your belief that the flaws of go disqualify it for large projects is biased on a certain, subjective perception to do things, not the objective absolute truth you are trying to make it out to be.

But even if it was correct, at best you are arguing that their efforts to focus on large software was in vain, but claiming that they don't focus on large software at all is, again, simply completely false. Please try to be constructive, here.

> Their solution to things getting out of hand or having performance problems is to divide the system, not to have a system that can handle it.

Can you give an example?

> As it did with e.g. debugging, for which their official stance is "use GDB, which doesn't really work".

I don't believe that's the official stance anymore. And IMHO, most large applications don't particularly profit from an interactive debugger anyhow (I can't just attach a debugger to a server serving thousands of requests per second and have any hope of getting useful answers). The debugging story of go is much more bound to things like "import _ net/http/pprof" and the like and systems like stackdriver.

Anyway. All of this is pretty off-topic, anyway.

> But as working engineers, focusing on the practical problems is, well, the practical thing to do.

Well, yeah, I'm an engineer too (just educated as a mathematician) :)

FWIW, I tried to solve an engineering problem, namely "how can we get the advantages of SemVer, while working around human deficiencies in setting and maintaining them". Or "why should a human need to figure out a version number, if a computer can do it for me". But, the thing is, that this turned out not to actually be an engineering problem, but a political problem; if there is no obviously correct interpretation of "breaking change", then for a tool to be acceptable, you'd need to get people to accept it's limited implementation of "breaking". I simply wasn't willing to put up with this political challenge (others where) :)

> If what you're thinking is "well in that case, people should agree that adding methods/fields is OK," I think they do, and, e.g. https://golang.org/doc/go1compat spells out that methods may be added and how that can interact with multiple embedding.

True. AFAIR that section was added around the time I wrote that article (I believe it was in tip a couple of days beforehand).

> Practically, I don't want my upstreams to stop adding methods or fields to structs or to create an extra step they have to go through before adding one. That slows down upstream dev; it's not a net win for me as a downstream or a cost I want to impose on (sometimes-unpaid) OSS maintainers.

I agree.

> I also don't want a tool to flag every upstream field/method addition as a breaking change, because that's noise to me in the common case where the change doesn't break _my_ program. Really, if I want a back-compat test, I should upgrade and try to run my code's tests since that can shake out many more kinds of break, including ones due to my bugs/my dependencies on undoc'd stuff

But you, as the author of a package, are not really the target audience either. You are able to fix compilation bugs, but your users likely are not.

But yeah, you probably also just aren't the addressee of my article. It is mostly addressed to people claiming that versioning in go is a solved problem and SemVer is the solution. It's not.

Your observation is pretty much the point of the article; a breakage happens, iff my code doesn't work anymore with an upgraded dependency, not more, nor less.

> Again, you did make a clever observation of a potential build break; I'm just saying I don't think that Go library authors need to spend more time worrying about potential name collisions with multiple embedding, or that people should specifically build workflows and tools around it.

Here, I disagree. Tooling to work around breakages would be excellent. As you mentioned yourself, for most breakages you just have to make the compiler happy and for most breakages it's pretty trivial to figure out what's needed. And at that point, there really should be a tool to do the job; after all, you should never send a human to do a computer's job. :)

> they seem to focus their decisions on small-ish scale projects at the expense of large / longer-term ones, and this is the natural consequence.

This is - excuse me - a pretty ridiculous claim, given the explicit design goals of go. https://talks.golang.org/2012/splash.article You might disagree, that their choices are furthering these design goals (I don't), but claiming that they focus on small-ish projects is just non-factual, most design decisions are driven by a focus on large (both in problem- and code size) projects.

> A lot of the problems are solved by "hit it until it compiles"

Neither do I want to need to fix compilation errors in software that I use, nor do I want my users to have to do it. This is not a solution to the problems at hand.

> The rest (adding methods -> you may collide with an interface which you didn't before) can probably be detected

No, they can't. From looking at your code you only get an outwards pointing import-arrow. There is no way for you to know which code actually relies on your API and in what way. You might, say, limit your guarantees to packages on godoc.org (which is indeed what I do in practice), but it's still hardly a solution to the problem.

> If you manage to limit most of your changes to "can be automatically changed / detected", you have a fair bit more freedom.

This is indeed the path I'm currently following; for every breaking change, provide an automatic fix. It still isn't an actual solution, though, just a halfway decent workaround. It especially doesn't work without https://github.com/golang/go/issues/18130 and a couple of other needed changes.

Luckily, go has immensely powerful tools to perform these kinds of rewrites (much more powerful than any other language I'm aware of) and I'm thus pretty optimistic that this will provide a good way forward soon (now that the need for gradual repair is officially recognized).

> Yes but only in Go.

I don't believe this to be true. I'd say at least most languages/projects would have exactly the same kind of problems (some of them at runtime, some of them at compile time), it's just that in practice they don't really matter. So you don't know about it and it seems, to a casual observer, to work just fine.

> The problem is that Go apparently doesn't let you reliably add things either.

Neither does, at least, C. I'd guess that python also doesn't let you do it. I don't know enough about java, but I'd assume that it has the same problems.

What you need to understand is, that I applied an extremely nit-picky interpretation of stability. It's not like any of the things I mentioned are learned from experience or practical problems; I just understand the go type system enough and thought really hard whether there is an obviously correct and useful interpretation of API stability under its constraints and came up with a (mostly theoretical) result. Most projects in go that use SemVer apply a more generous and naive notion that works well enough in practice. C projects do exactly the same.

> It's not a problem in languages that come with a package manager, or at least promote a specific one to handle dependencies.

No. It is pretty much only a problem in languages with a package manager. Languages without the notion of package versioning don't run into the issue of needing to have a notion of what a version is, clearly. A package manager just helps automatically enforce versioning, it does zero to help you figure out what the correct version is.

Yes, not coming with versioning and a package manager comes with its own disadvantages and pain, no doubt. And we can surely debate which pain outweighs or is worse. But claiming that package managers would solve this problem just isn't true (I wrote the article when the whole "SemVer and package manager for go" debate was taking off and I tried to come up with a better approach).

> It's only a problem in languages where developers thinks "you don't need that". There is this weird belief in the Go community that Go is a miraculous language where good programming practices don't apply because Go magically make them irrelevant.

Can you source that? I am one of the most vocal opponents of package managers and versioning in go, but this contradicts everything I believe about it. My believes aren't, that go doesn't need it, but that a) it comes with its own set of problems, that b) those outweigh most of the benefits, IMO and c) that by considering and discussing it carefully, we might be able to come up with an actually innovative new solution to the problems.

Nowhere do I claim that go doesn't have those problems, on the contrary. I'm just arguing that, traditionally, go is a language that prefers doing things right over doing things like they were always done.

You are interpreting me correctly :) Indeed, the article was written when I started writing that tool and quickly figured out that it was impossible to do satisfactory.

I'm a mathematician, so the only satisfactory solution to me would be one that is "clearly correct". As soon as you need to first get agreement about the definition you are using, you are probably not designing a clean and beautiful thing :)

What I was trying to illustrate is, that the notion of versioning is broken in and off itself. By the lessons of the article, pretty much every API change is a breaking change, so you would constantly need to increment the major version, if you take SemVer seriously, meaning minor versions don't exist, de facto. And if you now imagine that you'd need to touch your code every time one of your dependencies increments their minor version (I mean. Likely you can't, because you have no notion of how often that happens, because currently all your tools just ignore those changes), lest people can't build your software because the packaging tool needs to assume an incompatibility that needs manual resolving, you will see how useless this makes versioning.

Now, there are two ways out of this mess: One is to ignore it and just assume that, in practice, some things will are more likely to break consumers than others and just apply a reasonable case-by-case judgement. It's what's happening right now in probably ~every language for ~every tool out there. I think it's reasonable, but I personally dislike it, because for one, humans eff up all the time, so relying on them having a good notion of what breaks and applying it consistently and timely leads to pain. This whole article is born out of the idea, that these things should be codified and then automatically applied, I shouldn't even have to need to know what version my package currently is, IMHO.

The other way out is much more complicated: Transition to a notion of breakage not by versioning APIs, but by defining it in terms of pairs of packages. This also has a bunch of definite and obvious deficiencies (for example that you don't have access to all the code that imports you. Or the combinatoric explosion).

Currently, my personal hope is that this can be solved by supporting gradual code repair (see, e.g. https://github.com/golang/go/issues/18130 for what this means and how this is currently progressing) and then add good tooling (I'm working on something, but I have limited time and brain space). We'll see :)

The issue is that even if you only consider keyed initializers, adding fields is a breaking change, strictly speaking. I tried making clear that I use the compatibility guarantee as a basis in the introduction and I mention this exception more thoroughly in the section about adding fields.

The article was created because I was starting to write a tool to do this. After sitting down and thinking about it quickly, I came to the conclusion in the article: There is no non-breaking change (or rather: That determination can not be made from the package you are looking at). At that point I put the idea to rest :)

> The practical backwards compatibility things that I have seen come up

Yes, I'm not really talking about practical problems :) This article is mainly a response to various people claiming, "backwards compatibility is easy, it's a breakage if you are breaking the build".

FWIW, most of the scenarios you mention I wouldn't really call a backwards compatibility issue either, though. I'd say they are bugs that are exposed by a change in API.

Author of the article here. Weird to be on HN ^^ If you have questions, shoot away.

Unlike f2f I do believe this should be possible without a lot of problems. NaCl isn't that special magical technology and everything that is special needs to be in an RC anyway. And even if you have any implementation bugs; the way NaCl works, this would, in the worst case, mean that the program gets killed because it contains invalid machine code or makes invalid syscalls (this confidence comes mainly from the fact that go uses the unmodified NaCl runtime for execution, which contains the appropriate check and is QA'd by the chrome team).

I assume that, so far, just no one did the work, they don't want to spend the additional resources on separate playgrounds or the go team doesn't consider it a good enough idea. I'd recommend either E-Mailing golang-nuts or directly opening an issue (after checking, that there is none so far).