Pure speculation on my part, but I've noticed Go has generate and build as separate steps and it's standard to check in generated code. This split no doubt makes compilation a lot simpler/faster, but perhaps it's a reflection of standard practices the language authors were used to.
I've been curious about the Dark Crystal - was it particularly groundbreaking when it came out? I watched it after watching the more recent Netflix series and found the story pretty dreary.
Similarly, I've heard Tron was almost revolutionary by the standards of the day, but the CGI is almost comical to watch now.
My disappointment with Rust, that in no way diminishes how much I enjoy using it in my own time, is that I have a hard time recommending it for microservices, which are arguably an average project at an average company. The ecosystem just doesn't feel as fleshed out or complete as in Go. It's a shame because there's libraries in Rust that I adore like clap, serde, and diesel but when I last wanted to write something that integrates with AWS, I found a deprecated unofficial crate and a non-production-ready official crate from AWS.
I don't know whether to attribute this disappointment to the breadth of what Rust can be used for and the difficulty in doing all of them well, or a lack of wider/corporate buy-in for these use cases. It's a pity, because after getting past the initial learning curve I struggle to find anything wrong with the language itself.
Y'know, now that you mention it, I don't recall changing the default editor in Ubuntu. I think I first noticed vi or vim as the default editor in Fedora around 6 years ago, and maybe also in git bash on Windows. Beyond that, my memory is hazy, but I think vi or vim is the default in Debian and RHEL/CentOS, but I wouldn't put money on it.
Most of the time I've seen people get stuck in vim is when they use "git commit" which opens up whatever you have $EDITOR set to. The default value in most distros I've used in vim/vi and I can't recall seeing usage help in that scenario.
It's not strictly true to say a credit card number is not a number. It can be validated by Luhn's algorithm which is numeric in nature, but not in such a way that you would treat it as an integer.
I was a little curious about this too. It's contrary to what I see in the Go and Rust compilers. My understanding was that it's good to have a go at parsing all input if possible so the end-user can batch fix mistakes, but it's unreasonable to expect error checking in post-parsing steps to occur if there are parse errors because the AST is almost certainly incomplete.
The committee took a decision that the package manager /doesn't/ support.
If I've learned one thing, it's that there's very little that software can't be made to do. Whether it should is an entirely valid question, and hopefully figured out before assessing the "could" aspect.
If you're using plain Go, you get static binaries for free. If you're linking against so C library you might be out of luck. You can try setting CGO_ENABLED=0 in your environment, but I've had mixed success in practice.
It's easy to forget, but the last 2 elections were based on getting Brexit done. The first one did not go terribly well for Theresa May, the second went well for Boris. The difference was the leader of the party - the policies were not radically different to a layman. It's hard to see it as more than a popularity contest.
I'm not sure Theresa May gets any real credit for Brexit as a concept. She didn't campaign for it; she was just daft enough to think anyone could negotiate something that satisfied the multitude of unworkable or contrasting promises.
HP did the same for 15.0.0.0/8 and 16.0.0.0/8 until the HP/HPE split at which point I think they couldn't figure out who should get the address space. As 2 x /8 is pretty valuable, they sold off chunks of it and are presumably still doing so.
Ironically, having such addresses was sort of useful when companies got acquired and teams got shifted around. Starting to use an acquired company's network that was never designed with "what if we get acquired and have to play nice with others" in mind causes all sorts of routing pain.
Bicester (Bister) and Gloucester (Gloster) are another couple of gotchas off the top of my head, and it's not like it even stops with places with *cester in the name.
I have no clue how widely implemented it is, but as far as NTP is concerned we're currently in era 0 which spans from 1900 to 2036. When we reach 2036, we just move to era 1 and have another 136 years until we reach era 2. NTP itself should be resilient to this kind of issue by design.
You (or possibly your employer) own the copyright to the code you produce. And you are fine to say something like "copyright $me $yearIMadeACommit". What you can't do is claim copyright on work you did not produce or remove existing copyright notices.
For your criticism regarding reproducible builds, I'm not sure it's entirely correct. The impression I got from a skim was that version control metadata was being embedded, such as the git commit hash or maybe a tag. Both of which are static within the constraints that builds are generally reproducible across. However, if it includes timestamps or some generated metadata, then I wholeheartedly agree with your concerns.
I use vendoring in Go because my team's builds happen within a huge, complicated corporate network that has been known to break arbitrarily in new and interesting ways (or rather when something gets changed unexpectedly and then it takes days/weeks to navigate outsourced IT and change it back). Vendoring deps doesn't save me all the time, but I've generally found it helps. Plus builds are a bit quicker because I can download everything in one go (via git clone) rather than pulling everything in at build time. It also helps when the linter decides it wants all the dependencies downloaded before doing anything and then we find it has a relatively short timeout when the network gains a lot of latency without notice.
On reflection, it seems more like I'm papering over network issues. Perks of working in an enterprise company I guess.
Maybe I'm different, but if the repo has some dozens of issues open, I take it as a sign of health. It means people are using it enough to find problems or ask for more features. If there's no issues, it tends to mean I'm treading on new, untested (or at least less tested) ground.
It still is controlled by the US government. I've spent the last 2 months integrating with a system that performs export checks on software to confirm we're allowed to send certain software from one country to another and we're not allowed to export to Iran, North Korea, etc.
To me, Somali origin but British citizen implies they were born in Somalia and then immigrated to the UK and later gained citizenship. Regardless, the term is designed to point out that the person is foreign and that's something that the public should inexplicably be concerned about.
For the type after identifier, the converse is what you see in C family languages. For example:
// in C
int x = ...
// in Rust
let x: i32 = ...
There's a couple of things that Rust can do better than C here. First, is that Rust is easier to parse because you know that let begins a variable declaration. If we look at C, maybe it's a variable, maybe it's a function and you have to get past the identifier to figure that out. The second more user-facing change is that you can omit the type in Rust if you can derive it from somewhere else, e.g. the return type of a function call or a primitive.
I really like the thiserror crate for cutting down boilerplate and you can add annotations to automatically implement From. However, if you want to handle errors with more granularity, e.g. IO errors as noted elsewhere in the discussion, then you'll need to implement From yourself.
And as others noted, .map_err(...) is slightly better than .or(...) for wrapping errors.
The downside to derive_more from what I can tell is that it impacts compile times fairly noticeably compared to the equivalent handwritten code. YMMV, but I've seen it removed from some crates for that specific reason.
I would guess null is the default because many of us start out with languages like C or Java. I've seen some interns have FP experience with Haskell, but it tends to be a single module and they often don't appreciate the nuance and FP is still not particularly mainstream in industry.
More generally, I don't think many programmers get to see the better way because they're not exposed to it. I can rhapsodise about Rust, but I doubt my company is going to buy into it because they already picked Go.
I always understood the glibc versioning problem to be solved by just building on the oldest common ancestor. If you have rhel5 through 8, you build on rhel5 and move on. If you depend on more than glibc... Well rhel5 is less fun.
Because it's distributed and the larger the spread, the smaller the obvious scale.
For example, let's say I'm a murderer and kill ever resident of a single street, one household a day. That's way too much of a coincidence to ignore. But if I did the same number across a larger area, maybe you get different police forces that haven't thought to talk to each other and no one spots the connection until much later.
The same applies here. If you personally have faulty software, it's not great, but you probably move on. If your employer buys the same software for all of its employees, then the scale of the problem is much more obvious and the actual cost of the problem is a lot larger to a single entity.
I always find Confluence to be the place where docs go to die. There's very little motivation to keep it up to date and tends to be one or two people driving it. When they move to another team or job, then it gets abandoned.
The things my team uses GitHub pages for tends to do better because devs don't object too heavily to writing code comments (for generated docs), markdown (for design docs), or API specs (for API docs). The last two in particular have become a big part of the design process, so it's been bought into heavily. Whether those stand the test of time remains to be seen - they're relatively new.
You having your car stolen, and software used across a company having a vulnerability are different in terms of scale though. If a whole shipment of cars was stolen due to a lock flaw (which is admittedly contrived), then I'd imagine whoever owned the cars would have a problem with the maker of the cars.