I didn't know Jony Ive was involved. That may explain why it looks so disappointing.
Jony Ive is a brilliant example of the role selection plays in evolutionary processes. It is the sorting method that punishes bad ideas with death and allows good ideas to survive. After Jobs passed away the selection mechanism that only let Ive's good ideas pop through disappeared. It is popular to accuse Jobs of credit hoarding, but in that relationship he was the talent. Ive just someone who could generate ideas for him to choose from.
More than a mutation agent, less than a good designer.
What makes Ive bad for Ferrari is that he operates under the delusion that he is a great designer. This makes him arrogant. Arrogance paired with mediocrity isn't the best of combinations. And Ive sans Jobs is mediocre on a good day. But his myth is persistent.
Ferrari has a long history. Ive completely ignored it and designed a mediocre bar of soap.
If he did so out of an abundance of arrogance, or simply because he actually doesn't understand Ferrari is unclear. But it is an undeniable fact that the car neither looks like a Ferrari, nor is it a particularly elegant car. If you saw it without knowing what it was you could be forgiven for thinking this was a more modestly priced asian mass market car.
For admirers of a brand that aspires to make iconic cars this is, of course, a disappointment.
I did like the instrument cluster though. It dials back the somewhat childish and gaudy displays that sports car manufacturers have offered for the past couple of decades and replaces it with something that is more tastefully retro. A lot of older Italian cars had beautiful dashboards that give off strong race car vibes. (for instance the Bertone-designed Alfa Romeo GTV from the late 60s and early 70s - those had gorgeous instrument clusters)
"Systems program" or "systems programming" is a meaningless term because people use it differently. Discussing what it means is a waste of time. It is better to be specific.
You have those who obsess over feature lists for languages and then you have those who obsess over friction, productivity, ease of use and developer ergonomics.
If I were uncharitable I might call the categories "people who are somewhat removed from reality" and "people who inhabit observable reality". Avoid the former, treasure the latter.
Languages evolve for a reason and nobody should give a shit about people who do not understand why.
I’d argue that this is wrong. Having a conservative standard library that aims to contain most things most people need is preferable to third party libraries in 90%. For the 10% that isn’t covered to your liking by the standard library you can turn to third parties. You get both a practical standard library and third party options.
I did a lot of cryptography over the past couple of years. Go has that in the standard library. For the last decade and a half cryptography is something that every developer has to deal with at some point, and it NOT being the awful pain that it is in just about any other language, is a good thing. Sure, it does not contain every algorithm and mechanism in the world, but it contains everything you need for 90% of cases. That means that most of the time you don’t have to do the extra work of ensuring you have an out if the library you depend on should go away/bad, bugs will be fixed, people speak a common language and you don’t have to do twice the work in terms of risk assessment.
People keep forgetting that you have to evaluate these things in the real world. In practical real-world situations. The real world is not about what works in theory but what actually provides value for actual people working on actual projects.
You seem to imply that it doesn’t have any cost. It does. You have to make decisions and, in the case of C++: sometimes you have to deal with a lot of really ugly code to make it “automatic”. And if you really have to count bytes and carefully manage stack sizes because you are writing code for a constrained device, you have to pay even more attention than you would in C.
GC’ed languages have memory related challenges too. But it simply isn’t true that these are on the same order of difficulty as the difficulties that do arise in C++.
For the vast majority of software you want a managed runtime.
Some of the problems Rust “solves” are problems you shouldn’t be having in the first place because we mostly write software that doesn’t need direct control over memory. Borrow checking isn’t something you want to have to deal with - it is something you have to accept when you have chosen to manage memory. That choice has a high cost that cost never gets paid off in most projects that could work just as fine with managed memory.
I’m a Go programmer, but this article reminded me that I should have more experience with Rust. From my perspective Rust seems a bit less practical. The standard library lacks support for cryptography, for instance. The compiler is slow, which is a productivity killer. Overall concurrency seems like a bit of an afterthought. Again.
What makes me want to try Rust in production are things like option types. Those would be nice to have in any language. Any issues that can be caught by the compiler are a plus. Getting rid of nil would also be a plus, but to be quite frank, I don’t experience that many nil pointer errors.
The author does nod to the static analysis tools for Go. Yes, they are not part of the compiler (for good reason), but they do a pretty good job in practice. So you get more than the compiler can promise at a fraction of the cost (measured in build time). That’s a much bigger deal for actual developers than we generally give it credit for.
Then there’s the stuff that makes me less convinced in terms of arguments. For instance the fact that Go didn’t have generics early on and that the standard library doesn’t use them. Generics were not as important as people thought they were. In practical reality. The fact that the standard library doesn’t make wide use of them is not a weakness, it shows restraint. They didn’t go overboard and prematurely plaster generics all over the place as soon as the language supported it. This is the kind of restraint you want to see. Remember how horrible Java was after everyone started abusing generics? A brief generation of software that was significantly worse, and less maintainable resulted from this exuberance. For the ultimate example of what happens when you give people every feature they wish for: look at C++. It´s not a very good language because it is many languages. Just because there are standards and recommendations doesn’t mean that all code magically gets rewritten to a narrower definition of the language. It means that we accumulate intermediate forms. I expect people who are interested in languages to understand these dynamics.
Rust's stdlib is small, Go took more of Python's "batteries included" strategy.
So in that sense it seems like a category error to try to look for crypto stuff in the standard library. Of course this brings the well known problem of "okay, but then which one should I use?". Nowadays this is largely solved by a few web searches and LLM queries, and people are quite helpful at https://old.reddit.com/r/rust/ .
Go was shaped by the needs of Google, Rust is a wildly successful amazing experiment in programming language and compiler design that really got out of hand :) (A bit like JavaScript! Or even C#! Or Python. Same growing pains (async/await!), but arguably on different levels.)
It turns out that the needs of Google overlaps significantly with the needs of software engineers outside Google. That argument could have been valid for a while after its initial release. But now it is just a lazy argument today.
I think batteries included is a better strategy. To the degree where I think Rust should reconsider this decision.
Rust likes to do things neat and proper and inclusive and community and zero-cost (or ALARA [as low as reasonably achievable]), and so on.
But there's no theory of standard library that they could implement. Shipping things together makes sense, but the maintenance burden is already significant, and there's also no theory of "ethically cloning open source maintainers".
I'm also quite squeamish when I think about all the unvetted dependencies, so yes, there's definitely a need, but I don't think slapping a stdlib tag on millions of lines of code would lead to great things.
But sure, I think someone could champion the case to introduce a process for adding projects to the standard packages. The projects would need to show some competence, commitment to quality and security. And the process obviously needs to have an orderly procedure for deprecation, and for "non maintainer updates" (like Debian has, for example).
It also means that everything is (over) optimised for Google's usecases, but not general purpose applications
I came across this problem pretty directly a couple of weeks ago - I wanted to see if I could port a small C program to Go, where one of the needs is to create gzip archives. But the Go stdlib insists on extraneous padding that breaks the backwards compatibility requirements of my program.
The padding isn't needed, it isn't useful, and you can't opt out of it. So the whole program went in the bin and I have resumed maintaining it in C
This is one of dozens of situations I've experienced where Go's allegedly pristine stdlib design has kicked me in the nuts
Somebody at Google decided this is how they wanted it to work. They don't have to explain why and they don't have to fix this deficiency until it becomes a problem for Google
It seems the problem here is that they didn’t “fix” whatever you thought was “broken” and you are upset. And somehow you extrapolated that to mean that Go only follows Google’s needs.
Be a bit more precise. What exactly are you talking about and and what do you think Go does wrong and why have they chosen to do it that way?
Rust has clearly opined that they prefer a small standard library and a "choose your own libraries" vs "batteries included" approach.
If Rust included a crypto lib and a vulnerability was discovered, many fixes are backwards incompatible. Rust maintains strict backwards compatibility, which means updating the relevant crypto functions in the std lib would necessitate a major version bump. By keeping crypto outside of std, it allows the community to make backwards incompatible changes at a higher pace.
Python handles backward incompatibility changes via multi-year deprecations. I'm not familiar with Golang but a quick Google search reveals that it deals with this by using feature flags via GODEBUG. Excessive feature flag use is a bad pattern in my experience years ago, but I don't know if that's applicable here.
I prefer the trade-offs of a "choose your own lib" approach, but I understand the advantages and preferences of those who prefer a "batteries included" approach.
In general, I get your argument, but cryptography is the perfect example for something so well-specified, well-understood, and extremely widely used, that these arguments do not really apply. You are not going to have to make backwards-incompatible changes to SHA256 or Poly1305, etc. It has minimal API surface too, and is not going to be a large maintenance burden. But nearly everybody is going to need crypto at some point. It is great to have blessed and well-audited standard implementations that people can rely on, without even having to make a choice. This it is not something where you want “the community to make backwards incompatible changes at a higher pace.”.
Crypto is something any modern language should include in the stdlib, imo.
Proviso: you do cryptography in the stdlib if you have the means to do it well. Go did; Filippo Valsorda has built a whole company practice on keeping that library excellent.
Certainly, that's a better outcome than just providing bindings to OpenSSL, which is what most other languages do.
I think I agree, but I am not sure I understand what "the means to do it well" actually means. I would think of it more as a community decision: let's focus efforts on doing X well in the standard library since X is important and people shouldn't have to ask "ok, so which third party library is the best choice right now".
Let me be the first to point out that this is not an easy thing to do since it depends heavily on the community/team/maintainer dynamics. Even agreeing on the goal or scope can be really hard. But if the Rust community is as good as people say it is, that should be doable, right?
On the other hand it wouldn't have to be definitive and exhaustive. Just a safe default. Like http muxers in Go: the one that came with the standard library was fine for a lot of uses, but people generally used third party muxers. I certainly did. And then one of the most used third party ones became shaky as it was no longer being maintained (now it is again, I think). Eventually the one in Go was improved to where I'd prefer to use that since it represents a "safe default" (and I am probably not going to need whatever extra features or performance third parties can provide).
Also note that I see myself first and foremost as an _engineer_. I care less about purity in theory than what things mean in practical terms. And in practical terms I appreciate Go for having so much useful stuff in the standard library. Stuff I kind of think we should take for granted in any serious language today.
What I don’t get is why the publishing industry never got its act together, listened to customers and got its act together.
Yes, like many industries I have worked in I can imagine that they are unable to cooperate because of petty greed and short-sightedness: they would rather have the whole market taken away from them than endure the possibility that some of their direct competitors get a small, temporary advantage.
It should not be hard to create truly interoperable systems that can cut Amazon out of the equation. It isn’t a technology issue. We have technology that easily solves every conceivable aspect of distributing, paying for and consuming ebooks.
This should be the ultimate opportunity for the publishing industry. Especially given that Amazon isn’t investing much in development of devices.
I'm not very familiar with anti-cartel laws (in any country), but I wonder if there would be legal issues preventing publishing companies from working together in such a way even if they otherwise had wanted to?
(Though even if that is the case, I'd still think they could have at least agreed on open standards to use, to prevent anyone like Amazon from creating vendor lock-in.)
But Amazon had advantages from its size. In terms of economies of scale for device manufacturing, publishers could have somewhat caught up if they pooled money to invest in a co-owned company that made devices (though still wouldn't have had such an advantage as Amazon, who could share R&D and production costs with any overlaps to other devices such as smart home speakers, Android tablets, etc.) But Amazon was also able to take a bigger picture approach, using cheap Kindles/ebooks to attract people into their ecosystem and then converting a not-insignificant amount of them to buying other stuff on Amazon.
Collaboration need not be subversive. In fact, it can be the opposite. As you point to, by using open standards.
Devices are not a real problem. You don’t need scale to get hold of affordable readers in bulk. There’s lots of them available and if the market were to grow, there would be even more devices. Today these devices are not very useful as putting content on them is awkward and fragmented. If that pain went away, there would be a huge market.
I think the problem is that Amazon would retaliate. And the publishing industry are too afraid of challenging them. Because they have never been able to get their act together before.
> I'm not very familiar with anti-cartel laws (in any country), but I wonder if there would be legal issues preventing publishing companies from working together in such a way even if they otherwise had wanted to?
Then all syndication services would have been banned, including Spotify, Netflix, and so on.
There definitely are ways that publishers could have avoided falling foul of anti-Cartel legislation (my question was about where the line is, ie if they did it legally would it actually benefit them), but...
Spotify and Netflix aren't owned or created by a syndicate of all the major publishers, so that's not actually a counter point. There's a huge difference legally speaking between a company negotiating with lots of rights holders to offer customers all of their content in one place, vs. those rights holders co-creating that platform and running it themselves.
(Not that the distributor has to be owned by a cartel of the rights holders to still abuse their position illegally, eg https://www.justice.gov/archives/opa/blog/e-book-retailers-d... - it's just that the cartel aspect is the bit I had been talking about.)
Have we really come to a point where the only business structures we can envision are huge monopolies playing zero-sum games?
Imagine if every publisher offered every book to every service that sells it to consumers? And are free to sell their own and other publishers books? They could even include Amazon. Yes, it would require DRM and a bit of software infrastructure, but guess what: they could choose to fund development of an open source system for managing this.
They can do this. But they won’t. They’d rather be beholden to Bezos and not even try.
I’ll repeat myself: they’d rather get collectively screwed than risk that a competitor might get a small advantage.
Yes, this struck me as rather odd and unprofessional too. Do you really want to depend on a company where customer facing representatives can’t handle people being upset? Especially when to company has just announced changes that limit what users can do with their products.
The older I get the less I want to deal with companies that act like primadonnas and the technologies they make. This is also why I don’t do phone apps: your market access is 100% controlled by two companies that can wipe out your business overnight.
Imagine having to work with these people professionally. With real money involved. While probably not as high risk as mobile development, their customer representatives seem like real primadonnas. You’ll be happier without these people in your life.
> Yes, this struck me as rather odd and unprofessional too. Do you really want to depend on a company where customer facing representatives can’t handle people being upset?
I’m actually fully in favor of empowering customer-facing representatives to put reasonable limits on responding to customer abuse.
It should not be the job of a forum moderator to take abuse. Warning them about the rules of the forum and then enforcing the rules is forum management 101. It’s getting silly that people are attacking this person specifically for just doing their job.
When a company screws over entire segments of their customers people get angry. And they don’t get less angry when their frustration is belittled by someone how essentially says “your dissatisfaction means less to us than the words you choose to describe it”.
I don’t want to register for this forum and I’m having trouble finding any kind of a sort. But are you referring to this comment?
* First, any bad language or abusive behaviour towards AMD, is not acceptable. If continued, we will proceed to block your profiles altogether.
If you are not happy with the new tier licensing flow, no one is stopping users (Students etc) to continue using the current versions of Vivado (any Vivado version prior 2026.1) and develop using free Vivado ML Standard Edition.*
If so, I have a different take on this. It could have been worded better, but I don’t think Anatoli is a native English speaker. Based upon a reply to @mkru, I also don’t think they have much visibility into marketing or if they do, they’re not very interested.
* For your specific question: Why is Linux not supported in the BASIC tier?
This is AMD's marketing decision.*
None of this is great, but English isn’t the easiest language to learn and de-escalation involves a specific speech pattern. And of everything they said in the answers I’ve found, ‘this is AMD’s marketing decision’ is the most blunt. Everything else has more information attached except for the little takedown at the beginning.
I know that’s a lot of words to say that I think belittling is a little strong. But brevity is a juicy topic… :)
Communication is tricky because it isn’t just about the words, but how they land. On the surface it may not seem like belittling someone’s pain. In reality this is exactly what it feels like for those on the receiving end. It also doesn’t help that it was delivered with a threat of expulsion. It communicates:
- we don’t care about your pain
- those in charge find it below their dignity to explain the decision to you
- we don’t feel we owe you an explanation, but we’ll take your license fees
- we care more about how you say things than what you say
- you are helpless and we can take away your voice (here) if we want to
Now, the problem isn’t just that some people are not native English speakers — quite a few in our industry come across as not being able to “speak human”. Which makes us prone to put more emphasis on words than how different people in different states of mind read those words.
> Communication is tricky because it isn’t just about the words, but how they land
Please mind that English is not my native language, but as I aged, I found that to be true less and less. Exact word choice does not matter as long as the intent is conveyed properly. With some leeway, maybe benefit of the doubt. And misunderstandings can be cleared up.
In this case, customers are unhappy with the decision. No amount of weaseling around with any kind of word combination is not changing the decision. Whatever tone he might have used here would not help anyone or clear up anything. There is no further misunderstanding.
Whether it's directed at you or not, as an employee it's still stressful AF and these people are like getting paid kinda shit wages to put up with people all day long.
I'm not arguing about whether or not this particular instance contained "uncivil comments" (do the mods have the ability there to delete the comments if they are uncivil?)...
But day in day out, on a mass level, it's such a goddamned drag, even if it isn't directed at you, it's energy and emotional bullshit. Every job has it, sometimes it's your boss or shit coworkers... But customer facing is such an awful position for the wages they usually make. Even if it's "good" wages. Even if they don't primarily face the public, but still have to engage in a secondary support role.
I can't imagine what it's like to deal with this as a job when you're on the front line with an angry mob coming at you.
Again on this particular case I'm making no judgement, but it IS a stressor, regardless if directed at you, or not.
Especially in a high volume environment that probably has more incoming vectors of commentary/attack/vitriol than just the single comment thread.
If you want my opinion I think what these mods said had nothing to do with the stress of the environment, they’re just following something of a community moderator trope where they maybe aren’t even employees and at all but enjoy the authority of moderation.
They have no authority or knowledge of the topic at hand at all but can’t resist weighing in and throwing authority around.
> Whether it's directed at you or not, as an employee it's still stressful AF and these people are like getting paid kinda shit wages to put up with people all day long.
You know, it used to be "The customer is always right".
But it's become "Whaat? Are you talking to us you uncivilized, stinky hippy peons? How dare you? We serve only the rich corps now, we don't care about you or your money."
> But customer facing is such an awful position for the wages they usually make.
So you're saying that rich AMD doesn't pay their employees enough and for this reason, their unsatisfied customers should be careful not to say bad things about the company to the employees mistreated by that same company... There are too many logical errors here to describe in a short comment.
> Yes, this struck me as rather odd and unprofessional too. Do you really want to depend on a company where customer facing representatives can’t handle people being upset
Typical phone CSR boilover from covid days. Most places I call these days have a message saying that they will hang up on you if you act pissy.
> have a message saying that they will hang up on you if you act pissy.
When I had some influence over customer support at a company once I set a similar expectation. We didn’t advertise it up front but if a customer was being abusive over support channels they could be cut off.
Big morale boost for customer support. Abusive customers are rare but they can think it’s their job to attack, threaten, and be uncivil. Being stuck in a position where you’re forced to placate angry man-children sucks.
It’s sad that there are so many comments here trying to attack the forum moderator for moderating the forum.
This person had no hand in the decision making. No reason to treat them as an outlet for anger.
If customer support employees don't want to deal with angry customers they should take a job whose purpose is not dealing with unhappy customers. If you as a company have too many angry customers the response should be to fix your product/service, not to find excuses to ignore those customers.
All you're doing to forcing your customers to find other ways to fix their problems - either by finding someone higher paid than customer support and wasting their time instead or by going to a competitor and telling everyone to do the same.
It is not «a foundational principle of computer science».
reply