Static checking of units in Servo(blog.mozilla.org)
blog.mozilla.org
Static checking of units in Servo
https://blog.mozilla.org/research/2014/06/23/static-checking-of-units-in-servo/
26 comments
This is the difference between types and tags (sometimes they're conflated).
This code is buggy because they are using floats internally. A 32bit float can not represent the exact measurements specified.
This is a perfect example of why just statically type checking your code does not make it correct.
This is a perfect example of why just statically type checking your code does not make it correct.
Every time I read about Rust I have to fight the urge to drop everything and just chase it. So much awesome going on over there.
We've been using stuff like phantom types in Haskell for years, where have you been?
http://www.haskell.org/haskellwiki/Phantom_type
http://www.haskell.org/haskellwiki/Phantom_type
I have mad respect for Haskell as an idea incubator, but it's not what I'd reach for as a systems programmer: https://news.ycombinator.com/item?id=7895890
Rust is awesome because it's bringing powerful ideas like this to a systems language.
Rust is awesome because it's bringing powerful ideas like this to a systems language.
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.
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.
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.
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.
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.
[^1]: https://github.com/ndmitchell/shake
[^1]: https://github.com/ndmitchell/shake
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.
Being scared away by laziness, monads, and people generally talking like math geniuses, I guess.
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.
https://github.com/bitemyapp/learnhaskell
If you start going through the guide and get stuck, I will help you.
Only fear can stop you, be brave!
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.
https://github.com/bitemyapp/learnhaskell
If you start going through the guide and get stuck, I will help you.
Only fear can stop you, be brave!
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 ;)
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.
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.
>We've been using stuff like phantom types in Haskell for years, where have you been?
Lusting over a language that borrows its syntax from the Algol we all love and doesn't require a degree in Type Theory?
Oh, and without laziness, and with speed and no-GC guarantees...
Lusting over a language that borrows its syntax from the Algol we all love and doesn't require a degree in Type Theory?
Oh, and without laziness, and with speed and no-GC guarantees...
Have you looked at D yet? It scores 4/5 by your mark, and they're working on the fifth point.
Here's the documentation for the proposed units module. I believe it has the same principles as Boost units:
http://klickverbot.at/code/units/std_units.html
Here's the documentation for the proposed units module. I believe it has the same principles as Boost units:
http://klickverbot.at/code/units/std_units.html
The language in common use with the closest syntax to Algol is probably Bourne shell.
One or two of your five objections are valid and not because you're well-informed.
Let me know if you'd like to know more.
Let me know if you'd like to know more.
Let's see:
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"?
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"?
Boost has a neat library that does this and more: http://www.boost.org/doc/libs/release/libs/units/
But C++ is not cool so who cares.
I love that you get all of this safety with zero runtime cost.