> Furthermore, the units are used only at compile time. At run time, a Length<Inch, f32> value is stored in memory as just a single f32 floating point value, with no additional data. The units are “phantom types” that are never instantiated and have no run-time behavior.
I love that you get all of this safety with zero runtime cost.
Systems work is the only good reason I've heard not to use Haskell but it's not a good reason for not having learned Haskell.
I've heard from people that learned Haskell independently or went through my guide alike that benefited greatly from having learned Haskell despite not using it at work.
Types are a more compact and faithful representation of code semantics than what most non-Haskell programmers are working with internally. Haskell also teaches you, beyond thinking in terms of types (heh), how to identify patterns & abstractions that most languages wouldn't allow you to credibly leverage.
>I've heard from people that learned Haskell independently or went through my guide alike that benefited greatly from having learned Haskell despite not using it at work.
Could also be a failure to admit they wasted their time, because of sunk costs et al.
Not meaning it as snark -- it can always be a valid hypothesis when we're talking about people.
I've been using Haskell "at work" on my side projects (which involve other people and a live website, not just toying around), and I'd say that having learned it has impacted the C that I write in my day job. I wouldn't say I'd wasted the time, with or without an impact on my C code.
No, I know what you mean and I've run into that. I take people don't use/write Haskell regularly and claim to understand it less seriously for this reason.
But people that I think got something out of it seem to be benefiting. One is a startup CTO that was using Clojure before - he's ship-of-theseus'ing his way out.
I worked on a side project once where I forced myself to use Haskell for everything: build scripts, RabbitMQ consumer, web app. Basically as systems-y as you could get. Once I got over the pain of learning new APIs, I didn't regret the decision once. Being able to distinctly isolate side-effects from pure code made the code more readable and modular. Bonus: trivial parallelization.
>build scripts, RabbitMQ consumer, web app. Basically as systems-y as you could get.
What? Systems programming means things like OS kernels and language runtimes. Places where garbage collection is not acceptable, and assembly language is not unheard of. Places where Haskell would be useless.
When you did that, did you use Shake[^1] for the build scripts? If not, check it out! It lets you easily say things like "bundle.tar.gz depends on the file MANIFEST and on every file mentioned in it", for example.
I think he was making a more general statement than just in regards to the article. Being able to use a subset of the awesomeness of Haskell in a systems language is very refreshing.
You're at least being honest by saying it's about fear - because it is.
I teach Haskell to experienced programmers and people that have never written code before. I know nothing about math, I dropped out of uni after one quarter, I have not studied math since that time. Most of my students didn't know any math and weren't any worse for it.
To add to this, fear is one of the reasons I've been procrastinating about finishing a type-class related exercise in Beginning Haskell.
There is something terrifying about feeling like you won't be able to solve a problem. However, from experience I know how much better off I'll be after getting over that and solving the exercise ;)
Not really a great reply as 'phantom types' are possible in the majority (all?) of typed languages with generics. Even C++ has them - that is mentioned in the article.
What I think the OP was expressing is that the various articles written on people writing great code in Rust inspires people to work with it. Admittedly phantom types are not a distinguishing feature of Rust, but it still makes a nice read that people are elegantly solving real problems in the language.
1) Not algol derived syntax (check)
2) Speed (check -- I don't care about the: "you can write it totally unidiomatic and squeeze it to almost C or even better for some microbenchmark" situation).
3) Degree in type theory (meant as a joke anyway, refers to the steep learning curve of the tons of concepts introduced).
4) Laziness (don't care about the "you can switch it off" situation).
5) Has a GC (check).
Is there anything I really missed? In real life, classical use, as opposed to "if you really try and want it, you can also do it this way"?
I love that you get all of this safety with zero runtime cost.