My interview performance actually got better once I stopped overdressing. I got more offers wearing a grey hoodie and jeans. And this was at big tech (not just startups).
The FIU bridge is truss bridge, not a cable-stayed bridge, see this NTSB update [1]. The bridge collapsed because it relied on a single truss with no backup to support the weight if it failed. This created a single point of failure where the collapse of any member (diagonal segment) would collapse the entire bridge.
There is no indication that ACB contributed to this collapse, rather, this was a faulty design that would have also posed a risk using traditional construction techniques.
There's a lot of talk here about TCP vs UDP vs SCTP vs x protocol.
It's important to keep in mind that this is all optimization. Don't lose sight of the big picture.
On one RTS we ended up just serializing world state over a TCP socket. If you can get away with the brute force approach then just do it. Don't optimize until you have a measurable performance problem.
Yep. The WHATWG recommends just using the term URL instead of URI.
> Standardize on the term URL. URI and IRI are just confusing. In practice a single algorithm is used for both so keeping them distinct is not helping anyone. URL also easily wins the search result popularity contest.
The biggest thing for me is that you can use secure WebSockets (wss://) without having to setup TLS on your origin server. This greatly improves the ability to establish WebSocket connections across proxies.
> Code defensively, and don't get fancy unless you need to. You're not just complying with the language spec, you are communicating your intent to the other developers who will read and maintain your code.
Leaving out semicolons actually makes the intent more clear. People run into problems with semicolon insertion when they try to create an unnamed expression, i.e:
["joe", "bob", "ann"].forEach(call);
If you use a no-semicolon style, though, you must name all your expressions, which makes your intent more clear:
var employees = ["joe", "bob", "ann"]
employees.forEach(call)
I agree, there aren't that many problems in IP compared to the www stack. Imagine if we had bytecode instead of Javascript, the web would be years ahead in terms of being able to create games, video editors, etc. and other high performance apps in the browser. Javascript has basically become a poor substitute for an actual assembly language.
> Mistake or not, allowing all pointer types to be `nil` seems like simplification from things like option types. How do you see nil as adding complexity?
Whenever you have null in a language, for every function you call that returns a reference, you have to check the documentation to see whether or not it will return null. You cannot know from only the function interface whether or not you have to deal with an optional value.
Option types move this checking to the compiler. The function declaration explicitly shows the presence of an optional value. You don't have to read the documentation or investigate the function implementation - the information exists in the function interface itself.
Given, Go tries to deal with this by using the multiple return idiom. By convention, you should only have to deal with null if you have a function with multiple returns. However, I think that compilers, not conventions, should enforce language rules. Leaving it up to conventions opens the window for human error.
> I've never heard of `if ok` being an idiom _as opposed_ to `if !ok`.
Go still has some unecessary sources of complexity, for example:
1. It uses null (the billion-dollar mistake) to indicate optional values. A better designed language uses an option type.
2. It has conflicting idioms for conditions. Error types use the `if err != nil` idiom while map access uses the `if ok` idiom. This means that you read the main execution path downwards and the error path to the right, unless you access a map, then the execution path goes to the right and the error path goes downwards.
3. The `:=` operator declares new variables, unless you use it to declare multiple variables where one already exists in the same scope. As a result, you don't know if you have actually declared a new variable using `:=` unless you read upwards to see if a declaration for the same variable name already exists.