barnacled

No, not most, all.

Projects like the Linux kernel are equally highly selective and reject code that they don't like big or small, but they do at least sometimes accept significant changes.

As I responded in another comment, I accept that might be necessary to maintain the approach of the language but the go team seriously misrepresent this. That is my main issue with them.

How many people have put a lot of work in only to find out that actually the go team aren't accepting significant patches? Look to the go modules fiasco for a good example of this.

Honesty matters.

The thing is I wouldn't mind that and maybe that is what a programming language needs, but they constantly suggest otherwise. The modules situation was pretty shocking to me. Just tell everybody this is how it is and it's all good. I wonder how many people have wasted time suggesting more significant features/changes under the impression they would be listened to?

While I am a fan of go and like it's simplicity it does sadden me the degree to which it is a 100% google project on any significant change like this. It is not an open source project in the sense of most major open source projects and if you don't work at Google on the go team you are highly unlikely to be involved in any significant changes.

I worked on the compiler in 2011 as an open source contributor and firmly got this impression back then which seriously put me off and the absolute farce of how modules were handled (community heavily involved put a ton of work in then out of nowhere Russ Cox just did his own thing anyway) suggests to me nothing has changed.

Generics have been heavily discussed and desired from the beginning of the language and many have contributed thoughts and concepts. At first the designers said more or less 'nope not needed' which changed to 'if somebody suggests a good implementation we will do it'. But would they really? If this design document had come from outside the go team would they even give it a glance?

I like the language and the team are clearly talented but it is a pity that the project is quite so proprietary.

While I think there's some sense in the analogy and you get real insights using new languages, I do find that 'beating the averages' article really unconvincing.

Firstly there's the obvious observation that Y Combinator companies very rarely use lisp, but there's also really a lack of any solid evidence of any kind anywhere that language choice has such a big impact.

I am a fan of exploring languages and making a good choice for the problem at hand and always remaining open-minded but I can't stand the religious flame war side of it and I really do not think that article helps, at all.

To me languages are always a trade-off between abstraction and control, to which each problem has an appropriate range of languages to apply.

I also think the concept doesn't apply here as go is certainly less powerful and has fewer abstractions than Haskell (by design) - so if anything it is the 'blub' language* according to the article here (my point being not to criticise go but rather to point out how silly the beating the averages concept is).

I don't think his original piece was arrogant, I think this is something of an overreaction and a problem with assessing any language - adherents meeting criticism with 'you just have to use it more' can use that excuse indefinitely. Better to address individual points.

* I love go and contributed to the core compiler back in 2011/12 so this isn't an attack on it.

Absolutely wonderful! This is getting ever more close to the joy of the original home computers, and a great setup for a kid to start with especially with the book provided. The RPi4 is also an impressive bit of kit. Bravo RPi foundation!

Could you give some more details in that? Interesting!

It does somewhat amuse me to see the degree to which people rationalise Apple's ongoing, consistent control freakery with excuses and justifications. Every time a story like this comes up the amount of people defending what they do really shocks me.

I used to work for Imagination Technologies, whose GPU all Apple mobile devices are based upon. I was at the company when Apple announced that they would no longer require IMG and would be using their own entirely independently developed GPU (knocking 75% off the share value of the company and effectively bankrupting them).

Looking from the inside of the story, the degree to which people both here on HN and in the media at large including, amazingly, the BBC, a state-funded UK news organisation took Apple's side of the issue when they were very clearly talking complete nonsense shocked me.

Apple simply relied on the fact that a. they'd poached a ton of top people at IMG b. IMG could not afford to battle the decision in court (an aside - IMG and Apple have quietly signed a deal for IP again recently - hardly suggesting that Apple have gone entirely independent of IMG). We could get into the fact that the 'independent' GPU was bug-for-bug identical to IMG HW, or documentation for it literally referenced PowerVR enums but I don't want to dwell too much on that.

My point is that Apple have for years taken an approach of trying to vertically integrate EVERYTHING and gain independent control of EVERYTHING. Many suppliers went the way of IMG, and this lack of repairability is in my opinion simply the latest episode of Apple not wanting anybody else whatsoever involved in their products.

The trend continues with Apple moving to all-ARM chips (we'll see what happens with ARM IP, nvidia can fight longer in court so perhaps Apple will leave that alone) and will, in my opinion, continue in all areas for all of their products.

Whether you think it's right or wrong it surprises me that people seem to lose sight of or deny this ongoing trend.

I think you misinterpret what I said, it is the edge case scenarios where fatalities tend to occur. Of course in humans that can be due to drunkeness or distraction or confusion, nobody is claiming human drivers are perfect, but if it is the 'weird' situations that tend to result in accidents and deep learning tends to make mistakes in 'weird' circumstances, that doesn't fill me with confidence.

Also it is not at all obvious that self driving cars will do better than humans. Perhaps they will, but it isn't just about numbers. As I alluded to in another comment, imagine if they had 50% of the human death rate but it was all small children and occurred seemingly randomly. Do you think that would be acceptable and a better outcome? These things are less black and white than they might seem.

Another factor is that with deep learning it is fully a black box. It is very difficult to understand WHY a particular course of action was taken, whereas in human cases you can usually determine this. The why might also be limited, e.g. 'human child was mislabelled as stop sign' or similar, which just causes further questions.

The fact that you have scenarios the car will definitely not know how to handle combined with a deep level of inscrutability makes it difficult to have confidence in issues being resolved or the technology improving on a safety basis.

I think firstly it's going to be tough with long-tail edge case deaths to really be sure the numbers will be less than human drivers until self-driving cars are unleashed in sufficient numbers.

Secondly, even if you're right (and you may well be) - imagine that a common edge case was a small child jumping out in front of the car. Would we want to accept a vehicle that consistently ran them over? The raw numbers might be better but that doesn't fully paint a picture of what those numbers would look like.

I also think the 'will randomly kill people, but rarely' aspect of self-driving cars will be majorly off-putting on a very human level.

And finally there's a perception issue here - the self-driving hype is around the idea that the car is effectively being driven by a far better driver than a human, the second it turns out it does really crazy things sometimes (doesn't even have to involve fatalities necessarily) is also going to put people off I think.

I personally prefer the idea of driver assists (responsibly developed so drivers aren't just distracted) aiding driver safety while we work on a supplemental self-driving solution, or perhaps as discussed in the article create some infrastructure along roads to make things more certain.

I am far from being against self-driving cars, I just feel the timeline is longer than currently hyped.

I am extremely skeptical of the boring project. The claimed money saving (a 10x improvement vs. every single tunnel digger in the world without any evidence to back it up?) the safety issues of a car breaking down in a tunnel or being brought up and down, the enormous cost with digging deeper tunnels, etc. etc.

Road tunnels exist and have been built all around the world, these kinds of ideas have been tried and ultimately general underground road tunnels are just not economical or particularly safe.

Thunderf00t has done a series of videos debunking these claims [0,1,2]. Unfortunately Elon has a habit of frankly lying which I think does serious harm to public perception of these things.

These kind of infrastructure problems are just hard and have a ton of trade offs, there is no silver bullet.

[0]:https://www.youtube.com/watch?v=HBtL3qDvdZc [1]:https://www.youtube.com/watch?v=0ezF7NmwQZs [2]:https://www.youtube.com/watch?v=Hyy-19qyNWE

I like Filip Piekniewski's take on this [0] - deep learning is appropriate for environments where the cost of mistakes is low (or the errors are reversible) and you're able to 'average them out'. Self-driving cars are absolutely not in that category.

"If your errors are irreversible and you can't average them out, and your application is in open domain where there will never be a shortage of out of distribution samples, you are royally screwed. That is why I'm so skeptical of self driving cars, since that is exactly the application described."

For me it's obvious the real issue are the edge cases - of course a self-driving car does fine in 99%+ of cases, but those small % of outlier cases are the ones where people potentially die. I suspect an entirely different approach is required to supplement/supplant the deep learning one and fully autonomous vehicles are still quite some way off.

I do like all of the driver assist advantages coming out of this work however! I don't think you can underestimate the value of having technology that works _with_ a driver until the point where self-driving cars become viable.

[0]:https://blog.piekniewski.info/2020/06/08/ai-the-no-bullshit-...

The HBO show literally talks about an explosion 'equivalent' to a MT bomb. There has been ongoing misinformation about Chernobyl and a potential nuclear explosion had the melted core reached the flooded basement, e.g. https://www.youtube.com/watch?v=ZKV1piLjoa0

I remember thinking this before I saw the thunderf00t video on this. Misinformation like this sticks.

The article is less clear (though they specifically say 'bomb' further perpetuating the myth), but it opens by referring to the HBO special as if it were fact. I think you're probably right (and the author is probably just equally confused as I was previously) but their intent doesn't change the fact that misinformation is being perpetuated.

I get frustrated that artistic license is taken with stuff like this and end up perpetuating harmful misunderstanding. HBO made a great entertaining show but they probably should have been more careful on this side of things.

"HBO’s Chernobyl gave us a raw glimpse of the devastating consequences a nuclear reaction can have."

It really frustrates me when a show that contains many significant factual errors [0] (e.g. the exploding like a nuclear bomb thing, a very harmful error) is then used as a basis for a factual column.

Now I don't really trust the contents of the article.

And here we see the same kind of misrepresentation:

"but they also spread these pieces all over the street on the way to the dumpster and left basically a bomb of cobalt-60. Bear that in mind."

This 'nuclear energy is like a nuclear bomb' delusion is really harmful and pushes a narrative that many ordinary believe - if you use nuclear material for non-weapon purposes it risks behaving like a nuclear weapon. Journalists should take some responsibility for this kind of thing - it has very real impacts on public perception of nuclear and therefore govt decision making.

[0]:https://www.youtube.com/watch?v=SsdLDFtbdrA

It strikes me as ironic that an architecture that used to pride itself on being RISC and simple is heading in the same direction as intel-levels of masses of specialist instructions.

I don't mean this as a criticism, I just wonder if this is really the optimum direction for a practical ISA

Personally I have found a rather different factor has been at play in my career - I have been in the industry for 15 years and made several side-steps, including working as employee #1 at a startup (which I cashed out from a buy-back), working at a GPU company on the driver and much else. I've also contributed to the linux kernel, chromium, the go programming language and a number of others.

I have never lacked the ability to make a change in my career even when it was scary, including taking the early stage startup job at a >30% reduction in pay + they only had 2-3 months money in the bank max.

However I've found that my career progression has been stalled by each and every move. I'm back at the bottom of the ladder and those years of experience? Worth absolutely nothing.

It's felt like every move to another position for whatever reason (typically to have a more interesting, fulfilling career in my case) has absolutely reset my career every time.

I'm 39 years old and last week a 25 year old was promoted in my company above my position after he'd been there for 3 years. It's pretty galling to think that I could be in the same position as not far off a graduate engineer in my early 20's.

My experience has consistently been that only your experience at $CURRENTJOB counts for anything when it comes to progression.

By all means, seek out the best job for you, but don't be surprised if there's a cost in progression of any kind. I don't regret taking risks and aiming for happiness but I do regret that I was naive about how to do it in a smart way.

I think part of the issue is that many technical roles (note: I have never worked for FAANG so maybe different there) do not have a well-defined or sensible technical promotion route, so only managerial experience matters in terms of progression.