That's a very good point -- I've never had any issues with it, but I've also not used it very extensively, so my anecdotal experience doesn't count. If it's true that it's more broken and unreliable than alternates, then I'd agree with you.
2,952 karma · joined May 3, 2012
I'm earnestly trying to avoid downplaying your comment, but you sound like you have no clue how much engineering effort and talent is actually required to build and maintain a reliable, functional, production-grade package manager that a huge number of people use.
Being able to completely implement and support a sophisticated software product end-to-end is a FAR better indicator of engineering talent than isolated algorithm puzzles on a whiteboard. Whiteboard problems are used in interviews simply because individually executed complete projects are so rare (at all, let alone publicly visible).
In fact, whiteboard interviews have all but been proven to be among the least useful at distinguishing good vs bad candidates. The only reason it works is because everyone knows it's a game, studies the game, and gets tested at the same game. It's essentially a disguised IQ test that you have to study for.
The problem is, if you don't study for it specifically, you're at a huge disadvantage. This leads to famous engineers (clearly talented) getting rejected because they don't practice jumping through the particular hoops the company makes everyone jump through.
It seems there are more than several cases where Google needs a high profile engineer more than that engineer needs Google, and as a result the engineer doesn't study the hoop-jumping Google wants. Google rejects them out of bureaucratic process, and loses out on a good hire.
On the opposite side: I'm not a famous engineer, so I suck it up and practice whiteboard algorithm problems like most everyone else -- and as a result, I've never had a problem passing coding interviews. But just because most everyone jumps through hoops to play the game, doesn't mean everyone should have to.
I'm really looking forward to tinkering around in Zig, for my next hobby project(s).
P.S. In fact, I'm going to 'put my money where my mouth is' and contribute via Patreon[1]. Zig is incredibly high quality and well-designed, despite being achieved from the spare time of so few; it deserves better funding.
FWIW, an anecdote from my experience: Of all the companies I’ve ever applied to, Google is the only one that required unofficial course transcripts and GPA.
P.S. Starting a comment with “Ummm?” doesn’t really add much value to the discussion.
The problem isn't where police are good; the point is to design a system that inherently protects against abuse by the very small percentage of LEOs that do become corrupt and abuse their special powers that civilians do not have. How do we protect against this?
Perhaps the simplest and most robust way to protect against this abuse is simply to limit the magnitude of power imbalance between the government and the people! One could argue that this principle applies to physically defensive equipment as much as it does to computer and information systems, and any other mode of power. Additionally, this notion is encoded into our country's constitution at least in some ways.
Therefore, this leads to the question: Can a civilian buy an MRAP? If so, I think your argument works very well -- especially since they're defensive machines. If a civilian cannot buy one though, I could see the argument against police using them gaining favor.
It was clearly demonstrated that all Google cares about is money, when they canceled project Maven immediately after protest, yet refuse to back down on Dragonfly. The only difference? Dragonfly promises to be immensely profitable, whereas Maven was small enough that the employees lost over it was assessed to cost more than the project’s profit.
So you really think that Google would then suddenly develop the moral fortitude, out of thin air, to reject bad ads in China that are nonetheless profitable? Even if their policy is to do so now, don’t expect that to stay — remember, their policy used to be ’we will not be complicit in censorship, because it is morally wrong, period.’
And even if it did, many would argue that it’s still a bad idea to seek a short term good at the expense of the long term. Enabling state censorship by giving the state more advanced censorship tech, could be seen as akin to enabling a heroin addict by giving them more heroin. Sure, they’ll feel good and they won’t suffer withdrawal. But overall it’s going to lead to a very dark place that ultimately yields extreme suffering and often even death.
Because — A lot of the time when you see a company complaining about how difficult it is to hire “good engineers”, when you look closer, what you’ll really see is manager(s) (in denial) who really want to hire top-20% engineers at bargain rates.
If an engineer can get a job at one of these companies, and work on exciting & fulfilling work, what’s the incentive to work elsewhere if you get paid a fraction of what you’re worth?
That’s not even what a fresh college grad would make in total compensation at Facebook, Apple, Amazon, Google, Microsoft, etc, let alone “mid level”.
A senior engineer at one of those companies would make several times that in total compensation.
P.S. The biggest common mistake I see in salary comparisons is the omission of scheduled stock grants, which sometimes can comprise even the majority of one’s compensation.
I find it very strange that you are effectively calling culture “brainwashing”. Would you prefer we have no cultural values at all? How do you think that would even play out? Without a shared value system, you cannot have civilization.
That said, your overall point is correct: Sometimes cultural value systems differ in incompatible ways, unless reconciled somehow. Often, this means being faced with the cold, hard reality of weighing the cost vs benefit of “acting out” against a law or moral code expected of you by the other party (whether or not your culture agrees with those laws or morals is irrelevant, when we’re purely talking about tangible consequences).
If there are no consequences from us, I don’t think it’s fair we “play the victim”. If we (the US) don’t want this behavior to continue, we must specify and enforce a policy of tangible consequences that will occur in retaliation for every single instance of IP theft that occurs.
So the reality is that there’s no such thing a no-compromise dev setup: Either you optimize for a desktop setup, or for portability, or somewhere in between. If you have the ability to have both a desktop and portable setup, such a pair I almost always going to be superior to just one medium sized laptop: Your desktop experience will be better with massive high resolution monitors, and your mobile experience will be better with a lighter, slimmer device and longer battery life etc.
https://www.amazon.com/Dell-Monitor-43-Multi-Client-P4317Q/d...
(I use this for work, and absolutely love it.)
For portable use though, I think an iPad could very well be superior to modern laptops. The hardware of Apple’s iPad Pro is certainly well beyond that of ultraportable laptops on the market now. The only missing piece is the software.
While I agree there are rare cases where .unwrap() is the right thing to do, I actually disagree here that it’s anywhere close to 10%: If you want to write a function that accepts only non-null values in Rust, you simply write it as such! In fact, this is the default, and no cognitive burden is necessary: non-nullable T is written simply as “T”. If you have an Option<T> and want to convert it into a T in Rust, you simply use “if let” or “match” control flow statements.
I actually think using .unwrap() in Rust anywhere but in test code or top-level error handling is almost always a mistake, with perhaps 0.001% of exceptions to this rule. I write code that never uses it, except those cases mentioned; while I’ve run into situations where I felt at first .unwrap() was appropriate, I took a step back to think of the bigger picture and so far always find safer solutions to yield a better overall design.
The cognitive burden from Rust comes not from this, but almost entirely from the borrow checker (a completely different toptic), and in some cases, arguably inferior “ergonomics” vs how Zig or Kotlin handle optionals.
For example, in some null-safe languages, you can write:
if (myObject) { myObject.mehod(); }
if let Some(x) = myObject { x.method(); }
IMO it’s not a huge deal, but certainly Rust could benefit from some syntax sugar here at least. Either way, both examples here are safe and statically checked by the compiler.
I’ll have to read more about iSH to learn if it’s a “true” shell, or effectively just emulated or with strict limitations, but either way the potential inspires of how great it would be to have a true shell and/or dev tools for iPads.
It may seem to be just semantics, but it’s really quite important that the default (and most concise) way in these languages to read optional values is to check if they’re null/None first in an if statement, after which you can call “object.method()” all you like. It’s important that you can’t just forget this check; it’s essential to using the content of the optional, unless you explicitly type something like “.unwrap()” — in which case there’s almost no chance the programmer won’t know and think about the possibility a crash. Take this in contrast to the chance of crash literally every time you type “->” or “.” in C++, for example.
For example, most older languages with “the billion dollar mistake” have no complaint whatsoever when your write “object.method();” where it’s unknown at this scope whether “object” is null or not.
The fact that such code compiles is the billion dollar mistake; not the fact that the pointer is nullable.
I don’t care if you want to write nullable references everywhere, or whatever else you prefer or your application demands. That’s fine, so long as:
1. Non-nullable reference types must exist.
2. Nullable references types must exist as statically distinct from #1.
3. The compiler must not let you write code that assumes a nullable reference is not null, unless you check via a control flow statement first.
Now to take a step back, the principle behind this certainly applies beyond just nullability (if that was the point you were trying to make): Generally, dynamic, untyped invalidation states are dangerous/bad, while statically typed invalidation states are ideal. And yes, this does include bad states internal to a non-null reference, just as much as to a null reference.
Sum types are the key to being able to statically declare what range of values a function may return (or accept), and ensure at compile time that these different cases are all accounted for. If you aren’t aware of how elegantly sum types solve this, you should look into it — and I suspect it will be quickly clear why nullable references are useless, outdated, and harmful.
But at the very least, we’ve solved the pain of null dereference — and virtually without compromise. So, it’s irresponsible or ignorant IMO to create a new language that doesn’t include this solution in its core.
Rust, Zig, Kotlin, Swift, and many other modern languages can express the same concept of a null reference, but in a fundamentally superior way. In modern languages like these, the compiler will statically guarantee the impossibility of null dereference exceptions, without negatively impacting performance or code style!
But it goes beyond just static checking. It makes coding easier, too: You will never have to wonder whether a function returning a reference might return null on a common failure, vs throw an exception. You’ll never have to wonder if an object reference parameter is optional or not, because this will be explicit in the data type accepter/returned. You’ll never have to wonder if this variable of type T in fact contains a valid T value, or actually is just “null”, because the possible range of values will be encoded in the type system: If it could be null, you’ll know it and so will the compiler. Not only is this better for safety (the compiler won’t let you do the wrong thing), it’s self-documenting.
It blows my mind that any modern language design would willingly think nullable object references is still a good idea (or perhaps its out of ignorance), when there are truly zero-cost solutions to this — in both runtime performance and ease of writing code, as you can see for example from Zig or Kotlin.
[1] https://www.infoq.com/presentations/Null-References-The-Bill...
This is somewhat subjective of course, but from what I’ve seen, Zig has just the right set of features to modernize systems programming, without making the language too complex or difficult to write (which arguably Rust’s “borrow checker” system does), and (like Rust) gets rid of some huge legacy language design mistakes most people agree on today (e.g. nullable-by-default pointer types, or no way to know at compile time or at a glance what range of exceptions a function may throw).
And of course, the “automatic” interoperability with C is an essential part of any C/C++ replacement contender.
I like Rust and other modern languages too, but Zig strikes me as just about the best possible contender for a true C/C++ replacement (due to seamless interop, and a very practical and well designed simple language core — as opposed to the complexity of something like Rust, for example).
I understand the place for rapid prototyping etc., and that not every software application deals with life-and-death situations — but even those that aren’t, I think our industry suffers a bit here. For example, to this day the Windows 10 start menu refuses to open sometimes (randomly) when I click on it, even multiple times. You could argue that this isn’t a huge deal, because within 30 seconds it usually “fixes itself” (or something like that), but it still doesn’t shake the overall feeling that we’re tolerating way too much shoddy software in 2018 than we should.
Or in terms of performance: I know not every application needs bare-to-the-metal speed, but something feels wrong with the world when my “supercomputer” (compared to a 1990s PC, for example) literally lags when I’m typing or scrolling in some apps, when a 1990s era PC could respond to essentially the same content interaction with almost zero latency.
Some few decades ago, we had far more klunkier programming languages, far slower hardware, and yet somehow yielded better tangible/functional results in some cases. Therefore, I’m very much in favor of anything that moves us towards higher quality software, and Zig (and Rust, and others) are all exciting examples of that.
And don’t try to argue how Intel’s $1700 18-core CPU is faster than AMD’s similarly priced 32-core CPU because Intel’s has slightly faster per-core performance. Such an argument would be absolutely absurd: the point of an 18-32 core CPU is NOT the single threaded performance :)
I’m not aware of any major tech company in the US that doesn’t offer excellent health insurance and retirement plans. And the quality and availability of healthcare in the US is arguably the best in the world, if you are insured (that’s the ‘catch’ I suppose).
The “thumb on scale” approach does work in some cases, I think, but it’s important that there be a “de-escalation” (or “de-thumbing”?) endgame strategy. What you don’t want is a situation where there are thumbs on each side of the scale, and each side is telling the other to remove pressure but neither side wants to because it’ll benefit the other.
For many on the spectrum (though certainly not all; it’s called a “spectrum” for a reason), this notion of “emotional content of <word>” is simply an alien concept! I know this is quite hard for a “neurotypical” person to truly accept (let alone empathize with), but it’s true: Which words are emotionally charged, and which aren’t, must be learned by rote memorization, and this can take a great deal of effort.
In this “neurotypical” world we live in, those of us on the spectrum must put a lot of effort into “acting neurotypical”, since “being yourself” just doesn’t fly when it means you can accidentally hurt others feelings (and we certainly don’t want that either).
Nobody is perfect though, and mistakes do happen. What’s unfortunate is that the kind of mistakes often made by people on the spectrum aren’t naturally tolerated or forgiven by most people, because the behavior is often seen as so far beyond the norm that “surely malice must be the only explanation”. Therefore, forgiveness and tolerance is often bypassed entirely.
Of course, I’m not trying to make excuses arguing that hurtful behavior should be tolerated; rather, I’m agreeing with the original point that we should help teach people how to behave well first, rather than dropping some kind of “ban hammer” on the first offense. Responding with the maximum penalty at the first offense is not only unfair, but creates a culture of fear and terror and anxiety, at least among those who aren’t the best at predicting what may or may not be seen as an offensive statement.