To me it's not the trivial cases like this that make type inference useful. It's when you get longer types like `Arc<Mutex<HashMap<String, String>>>`. Granted, that could be solved with a `type` declaration (or `typedef` in C++) but it's still convenient to be able to say: `let mut x = Arc::new(Mutex::new(HashMap::new()));` and let the compiler figure out the rest based on usage.
I've been coming back to Haskell sporadically over the past couple of months. Every time I do I find the documentation for things like Prelude to be excellent since that's stuff that I already understand but when trying to dive head-first into a new library I end up with 50 tabs open at various points in the doc to try to keep track of all the different parts. For libraries like megaparsec that have not only great documentation but tutorials and examples available it's often much easier to go in and read the "raw" documentation. Haskell isn't like C++ or other imperative languages in that you don't have "these are the method you can use on this class. Good chance you can figure it out from there". That's why I think that Haskell benefits from good example more than "conventional" languages.
> Haskell isn't like C++ or other imperative languages in that you don't have "these are the method you can use on this class. Good chance you can figure it out from there".
No, but for this case, type holes are much more powerful. You always have an I have X, I want Y, what functions are there that are X -> Y?
Hoogle is more powerful than anything I've seen on any other language. (If I could only make it use all the local packages, instead of the pre-built index. I'm sure there's a way.)
Haskell has also more need for documentation than most other languages, so hoogle is still not enough. That's the problem, not lack of docs.
I've been following futures since the announcement blog post came out (and had been using rust for several months before that) and I've never found a group of crates that intermix so well together. Simple stuff like tokio-tls implementing the Io trait from tokio-core so it can easily be used in bind_transport to secure the connection makes working with tokio and futures so nice. Thanks so much to the people working on this!
It's a far cry from Haskell but I've found Rust's type system to be a breath of fresh air coming from C++. Stuff like destructuring assignment and matching on enums (or anything really) while not as powerful as their equivalents in Haskell, are still much nicer than what you can do in C++.
There's nothing preventing Whatsapp from releasing an update that has a flag on your phone number/id that turns off e2e for messages that you send. If their software was open source we would be able to verify what we are running but as it stands, it's not and I doubt it will ever be.
Open source is a red herring. You're downloading WhatsApp from an app store (or, at least, the overwhelming majority of users are). If you can't verify what the binary is doing, the source code doesn't make a difference.
Beyond that, despite the repeated claims of open source advocates, there's nothing preventing people from taking the app store versions of things like WhatsApp and reverse engineering them.
If builds were reproducible (i.e. binaries would be identical if recompiled with the same toolchain on a different machine), then all it would take is N independent builders to verify the app store binary matches their locally built binary to greatly decrease the likelihood of tampering.
So, while being open source is not the complete answer, it certainly doesn't hurt.
The App Store run by a central authority with complete control over what can even be available and the ability to modify the delivery at their own whim is certainly a big issue in terms of trusting the integrity of the apps running on a device.
If you suspect yourself to be a selected recipient (e.g. you're Edward Snowden) I reckon you should compile your own binaries. Or read 'Reflections on Trusting Trust'.
Forget the software, the firmware running on the baseband processor can read system memory and send it over the network without you knowing. But that takes lots of effort to target a specific person.
So what do you do? It comes back to making sure that 'they' can only hack some of the people all the time, and all of the people some of the time. It's preventing them hacking all the people all the time I worry about.
I don't think it hurts! All else being equal, I'd rather have source than not have it. What I don't accept is our supposed helplessness in detecting backdoors in secure messaging software.
Or we could have build systems that weren't even more convoluted and fragile than they were 50 years ago and just release software in the form it's supposed to be in.
Obviously the app maintainer could push an update that simply leaks your keys and stored messages. Doesn't matter if it's open or closed source.
However, open source does give users some real recourse in the event that the project moves in an undesirable direction. I don't like what's happening, I can fork it without your permission and still have access to the same development environment and build tools the original project had. I think that's important and valuable.
A major problem with your approach is that it assumes analyzing a binary for correctness or security is equivalent to analyzing well-documented, high-level source. It's not. It takes much more work to discover vulnerabilities in assembly or even correctness failures. That's because it lacks the context for how the software is supposed to operate.
I can read a commented Python or BASIC program with almost no effort unless it's very sloppy. I can tell you a MISRA C or SPARK program with associated static checks is immune to entire classes of errors without analyzing the source myself. I can tell you what information flows can or can't happen in a language like SIF implementing information-flow security. I can do all of this while expending almost no effort. So, I'm much more likely to do it than if I had to decompile and reverse-engineer a binary from scratch with analyses using the tiny information in a binary.
So, every time you say that, what you're really saying is: "Anyone could do this if they spent enormous time and energy. Sort of like they could hand-compile their C code each iteration. They probably won't but I'm countering your wanting for source because in theory they could do all this with assembly with enough effort."
It's definitely not true for correctness as assembly lacks what you need to know it's correct. It's probably not true for security as correctness is a prerequisite for it. In any case, economics is important where the effort required to achieve a thing determines whether someone will likely spend that effort. In case of binary analysis, it's apparently a lot less than source analysis.
Similarly, the word "loanword" (used to describe words borrowed from other languages) is gairaigo 外来語 which is literally 外来 (gairai) "foreign" + 語 (go) "word/language". Japanese is filled with words where you can often figure out the meaning purely from the characters used!
I think that one of the other reasons that people are discouraged from continuing their programming is the information overload that you go through when learning something new (Especially something so large and complicated). I know that many of my friends have shied away because they felt like they where good enough enough to understand the information they where finding online. Hearing discouraging comments from others just helps reinforce that sense of inadequacy.
