`Void` is not equivalent to the unit type. Haskell _has_ a unit type, called `()`. A return value of `Void` represents a function which is unimplementable, or which never terminates. It can also represent an unreachable possibility, e.g. in the type `Either Void a`.
Yeah - I just wanted to emphasize that this article will be confusing for most developers. Since most are used to void from languages like Java. And the meaning of that void is different from the one in Haskell.
The second. Because everything in Haskell is immutable, it can take a _lot_ of liberties in terms of letting structures share parts of one another, in the case where one version is derived from the other.
Conversely, in the case where something like a list is modified in entirety (e.g. with a `map` function), if the compiler can determine that the original is no longer needed, it can run the map operation in place - much like you might do on an array in C - avoiding the need for a second copy of the structure in-memory.
Quite a few of Rust's features were borrowed from or inspired by ones in Haskell - albeit often modified to be more suitable for systems programming (and systems programmers!).
I am (or used to be) a Haskeller, and I just can’t get over how spectacularly ugly Rust’s syntax looks compared to Haskell or SML and finally force myself to learn it. Call me shallow, but it’s true.
I love how Haskell splits the type definition and function definition into two lines. It’s so readable that way. Also enables outlining your program first with just type definitions, and then going back and filling in the function definitions later.
No, you're not shallow. Rust's syntax has put me off a lot. I was looking to learn an alternate Erlang VM language and liked Gleam, which originally had a Haskell/ML syntax, but they've decided it's a popularity contest, so they chose to go to an Algol, C, Rust looking syntax. Shame. I was learning LFE (Lisp Flavoured Erlang), buecause Lisp, but then Elixir took off because all of the Ruby programmers took to it (and it's got a lot of other stuff going for it, but it's closer to Ruby than LFE!).
I think Rust's features were actually inspired by OCaml rather than Haskell. Rust was originally written in OCaml, and OCaml feels a lot more similar to Rust than Haskell does.
Of course Haskell is heavily influenced by ML so it also has a lot of the same features.
Traits are definitely inspired by Haskell typeclasses (according to Graydon), but you are right that many other similarities are also shared with ML languages.
> I think Rust's features were actually inspired by OCaml rather than Haskell
The old alpha/beta rust docs specifically referenced Haskell all over the place, and I don't recall them mentioning OCaml.
> OCaml feels a lot more similar to Rust than Haskell does
I disagree very strongly with this. OCaml doesn't even have type classes/traits! Rust lacks polymorphic variants, functorial modules, etc. It's really nothing like idiomatic ocaml, whereas I think it's pretty reasonable to describe Rust as "what Haskell devs would make if they weren't allowed to heap allocate". Maybe they'd also add a few more gizmos to the type system :)
It doesn't have to be one or the other :). OCaml and Haskell are two great languages that the Rust designers were familiar with.
The big thing IMO that makes Rust feel like Haskell is the pervasive use of traits and `#[derive(...)]` which is directly analogous to the pervasive use of typeclasses and `deriving` in Haskell.
IMO, that's too superficial to compare them. So what if both have a bunch of similar looking constructs? Rust is imperative, and sequential, and nearly everything is mutable, hence the borrow checker. That makes programming in Rust rather different.
I get what GP is implying. The way you program (and think) is entirely different if you are working with immutable data structures and functions versus safe mutability.
Rust is immutable by default. You have to deliberately opt in for mutability. When you don't opt in to mutability the programming styles are very similar at a basic level.
First the type system is very similar with the capability of building sum and product types with recursive values. Second pattern matching over sum types is also very very similar.
Rust is like the bastard child of C++ and haskell.
Rust's new claim is now that references isn't immutable, it's shared by default. There is no concept of immutable data in rust. All data is mutable in various ways and that is a product of the binding not the data, from the cell interior mutability eupphamisn to shadowing in the same frame: (`let x = 2; let x += y;` is valid even though x isn't defined as mutable. The mental gymnastics a rust parishioner has to go thrown to shout down other languages while theirs fills with the same concepts is growing by the hour.
You can build "product types with recursive values" in any language that remotely descends from C or Algol. Pattern matching is not wide spread, but --while nice to have-- it's syntactic sugar.
>You can build "product types with recursive values" in any language that remotely descends from C or Algol.
You cut off the part where I said sum AND product types. Variant and union are post C++11 and not traditionally part of Algol style languages. Even nowadays the only time I see variant is from some haskell engineer stuck on a C++ job.
>Pattern matching is not wide spread, but --while nice to have-- it's syntactic sugar.
No pattern matching is a safety feature. Most of rust code should be using pattern matching as much as possible. In fact there's a language called Elm that achieves a claim for code that has ZERO runtime exceptions via the pattern matching feature. See: https://elm-lang.org/
Don't believe me? You know about programmings biggest mistake right? Null? Well C++ sort of got rid of it by discouraging it's use but even with optionals the issue is still there because optionals can still crash your program.
With rust, optionals never crash unless you deliberately ask it to via unwrap. If you use pattern matching exclusively to unroll optionals a crash is virtually impossible. Try it, and try to guess how pattern matching prevents optionals from crashing your program in rust, while in C++ the lack of pattern matching forces empty optionals to crash when you try to access it.
>Rust's whole shtick is safe mutability.
Yes, but at the same time it's opt in. Algol languages are by default mutable and you have to opt in for immutability via keywords like const. Rust offers extended safety via a single usage mutable borrow ans single usage mutable ownership but this is opt in. You should avoid using the keyword mut as much as possible.
In most Haskell codebases most code is written imperatively and executes sequentially.
It is very rare that anyone is actually using the truly advanced techniques like knot tying or TARDIS monads which are truly impossible in other languages.
Having used Haskell in industry, I can say it's actually _surprisingly_ good at boring run-of-the-mill software. The strong focus on correctness and the ecosystem-wide consistency of it's core design patterns means you spend a lot less time debugging things, and a lot more time writing the thing you actually want to write.
That said, the type system _does_ stand in the way of learning it - though it's very powerful once you get your head around it - and lazy evaluation means you do spend more time than you'd generally like hunting down space leaks if you're writing the sort of code that's capable of getting space leaks.
Definetly not true. This can be the best password in certain conditions.
You should not put your "good" passwords to any shady site out there. You have no idea how passwords are stored on all these platforms one is registering to.
If you can live with the fact, that an account may be hacked, then go for a super easy password if you want.
Excusing the fact it was a joke, on the serious side, a person shouldn't have any kind of set of "good" passwords. They should just have secure passwords they have auto-generated and have some way of retrieving the password from where they are stored when needed.
Or, just have a unique password for every site stored in a password manager, and then they can all be “good” passwords, with no big concerns about how they are stored!
"Our customers' passwords remain safely encrypted due to LastPass’s Zero Knowledge architecture."
I take your point but I'm not aware of any hack of a major provider which resulted in exfiltration of decrypted customer secrets. Providers often enumerate how they prevent exactly this scenario [1][2], but you'd be correct that if your endpoint were compromised, it's probably game over. To be fair in this scenario just typing in your password (not using a manager) would also be game over.
If you want other options, it is possible to self-host (i.e. Vaultwarden). Personally I've been using 1Password for a long time, and their "Families" offering [3] is exceptional for me and has meaningfully improved my family security since the UX is easy enough my loved ones don't find a unique password per site "a chore".
The one you linked is close to how you'd write this in idiomatic Haskell. The paper is describing a particular technique, and using FizzBuzz as an example problem, not suggesting that the technique is a good way to solve FizzBuzz.
I don't _think_ Accenture were the original or primary contractor. I'm Australian and interviewed with Digital Asset for that project - as far as I'm aware, DA were the main company responsible, although from what I've heard from people working on it, a lot of the failure stems from mismanagement on the ASX side.
Haskell's syntax without Haskell's type system sounds like a nightmare. The type system is what makes me at least vaguely confident that the incomprehensible string of symbols that make up a good chunk of Haskell expressions are at least close to being correct.
(And to be clear: I use Haskell professionally and love it - but the syntax is _not_ why most people use Haskell).
I can’t identify with this description (“incomprehensible string of symbols”) at all, unless maybe you’re talking about Lens-based code or something.
I think most people who complain about the readability of a language like Haskell are confusing familiarity with clarity. We learned Java or C++ or whatever in school, and despite the fact that those objectively have more complex syntaxes and more meaningless symbols, they are “easier to read” because that’s what you started with. Haskell has a higher semantic density with fewer boilerplate symbols - surely easier to read from a first principles standpoint. If you started from a math background and are comfortable thinking in terms of equations, it’s almost certainly easier to read.
You can write Haskell defensively on the syntax level.
But it's much more common, at least for me, to eg just guess at operator precedences and leave out parens, because for the most part the type system will yell at you, if you get it wrong.
This is in stark contrast to the likes of C or C++, where the rule of thumb is 'when in doubt, add parens', because even when you get the precedence right when writing the code after looking it up, you'll most likely will have forgotten by the time you or someone else reads the code again; so you save everyone time with the extra parens.
The main thing I'd want from a better Python syntax would be to make more constructs in the language expressions with values instead of statements. For example, if-then-else. And introduce pattern matching.
The surface syntax might want to take more inspiration from Lisp instead of Haskell. Lisps are traditionally dynamically typed, so you can look at quite a few already thought through solutions.
I dabbled a bit in dogelang and the "great" thing is that it almost is Haskell but not. You can deconstruct tuples which looks like pattern matching but it isn't. You can use generator lazyness which looks like lazy and non-strict evaluation but the generator has an internal state.
It's amazing if you really try to write something haskell-like where it actually breaks.
