
F* – An ML-like functional programming language aimed at program verification - philonoist
http://fstar-lang.org
======
infruset
This post describes how Mozilla is incorporating F* verified cryptographic
code into Firefox: [https://blog.mozilla.org/security/2017/09/13/verified-
crypto...](https://blog.mozilla.org/security/2017/09/13/verified-cryptography-
firefox-57/)

------
Jaxan
A nice project using F* is the project Everest: [https://project-
everest.github.io](https://project-everest.github.io) . They implement HTTPS
and all of its crypto, completely verified.

~~~
qualitytime
"Current status - We generate a C library, but the verification is not
complete."

~~~
catalin_hritcu
One can always look at the empty part of the glass, but the quote does
continue with a big full part:

"The TLS 1.3 handshake verification is work in progress and still relies on
the OCaml extraction mechanism of F* ; thus, the C library still encapsulates
the OCaml runtime system.

We have completed verification of the TLS 1.3 record layer it currently
extracts to C.

The AES and SHA2 cryptographic assembly routines are verified and extract to
assembly via Vale.

HaCl* provides verified C code for multiple other primitives such as
Curve25519, Chacha20, Poly1305 or HMAC.

Our test client implements TLS 1.2 + TLS 1.3 Draft 18 and successfully
connects to TLS 1.3 test servers. We have a prototype integration of miTLS
within libcurl that one can use to git clone a remote repository."

------
philonoist
One thing I am amused is the behemoth support by Microsoft Research. Why is it
still dormant? [https://www.microsoft.com/en-us/research/project/the-f-
proje...](https://www.microsoft.com/en-us/research/project/the-f-project/)
[https://en.wikipedia.org/wiki/F*_(programming_language)](https://en.wikipedia.org/wiki/F*_\(programming_language\))

~~~
tom_mellior
Microsoft Research is also behind Dafny and Lean and a whole bunch of more
specialized tools: [https://rise4fun.com/](https://rise4fun.com/)

They are very wisely not claiming that any of these is _the_ verified
programming language to rule them all. There is still a lot to learn.

~~~
sevensor
Much of this uses Z3 under the hood, and Z3 is made of pure wizardry.

------
beurdouche
One cool thing with F* is that it starts bringing real contributions such as
the HACL* formally verified cryptography to Firefox.
[https://blog.mozilla.org/security/2017/09/13/verified-
crypto...](https://blog.mozilla.org/security/2017/09/13/verified-cryptography-
firefox-57/) Realistically, even if F* is not fully foundational it seems to
be a very good compromise to write security sensitive applications in terms of
proof effort...

------
jonwinstanley
Why was it not named FML?

~~~
52-6F-62
Phrasing?

I wish they at least named it Fasterisk

~~~
ainar-g
"Faster and with less risk!"

------
7kmph
Can't wait to see someone write some kind of checking program with the name
F*ck.

------
corey_moncure
Is it easier to write a program that behaves the way you want and a
verification to prove the program behaves the way you want, or to just write
the program? What if you goofed writing the verification, and now you have a
program that is guaranteed to misbehave? How do you verify the verification?

~~~
cmrx64
Validation vs verification. Validation: "is this the right spec",
verification: "does this meet the spec".

Turns out once you have a formal specification, you can do all sorts of things
with it that you couldn't do with just the code sitting alone. You can prove
properties about your specification. For example, seL4. Even the abstract
specification is quite big and can be hard to reason about in complex cases.
How do you know that spec is the one you want? Well, they wrote down some
security properties they'd like it to have, and then proved that the abstract
spec has those properties (eg, you can configure it to act like a separation
kernel; it enforces isolation given an isolated initial condition; it enforces
integrity).

How do you know those are the right properties? Well, that's the challenge of
software validation isn't it :) Ultimately formal methods doesn't make that
problem much harder. You just need to figure out a way to formally phrase the
properties you want. A lot of software has very fuzzy validation criteria, and
isn't necessarily suited for formal verification for that reason.

------
ainar-g
Why didn't refinement types find their way into mainstream languages yet? It
seems like it would have a tremendous impact on how programs are written and
tested.

~~~
pjmlp
Because major organizations only want replaceable developers, as cogs in the
enterprise machine.

Better quality of software is irrelevant unless they get fined, like it
happens on medicine or aeronautics industry.

~~~
kakarot
Those "major organizations", with the exception of Google and Apple, aren't
spearheading language design.

Their point of view has no impact on the evolution of language paradigms, and
if you told them they could save money on QA and increase the reliability of
their product for virtually no overhead with new paradigms, I don't see why
many people would reject the idea.

~~~
pjmlp
Google, as in Go?

"Type system tyranny", page 8 -
[https://talks.golang.org/2009/go_talk-20091030.pdf](https://talks.golang.org/2009/go_talk-20091030.pdf)

"Programmers working at Google are early in their careers and are most
familiar with procedural languages, particularly from the C family. The need
to get programmers productive quickly in a new language means that the
language cannot be too radical."

[https://talks.golang.org/2012/splash.article](https://talks.golang.org/2012/splash.article)

~~~
fauigerzigerk
This is a convenient explanation and you will find a lot of evidence for it,
but I think it's superficial.

The real question is, why can they afford to take this approach without being
outperformed by companies that use better languages and better developers?

For those of us who enjoy exploring more powerful/innovative languages, there
is a convenient explanation and a not so convenient explanation.

The convenient one is that the success of these "Blub companies" is largely
determined by factors unrelated to software development.

The inconvenient one is that all these interesting and powerful language
features do not significantly improve software development outcomes.

I think it is remarkable that some of the companies that are on the Blub side
when it comes to software development are among the most cutting edge,
research oriented companies in other regards, such as AI.

Also, companies like Google can not only choose among the best candidates,
they also have a lot of influence on what people learn before they even apply
for a job there. So I simply don't buy the familiarity excuse, at least not
for the entire workforce.

I also don't buy the large existing codebase excuse as that would apply
equally to new Blub languages and new PL research based languages.

There is simply very little faith in any positive impact of PL research
innovations on software development outcomes. And this lack of faith cannot be
explained away by claiming that all those lacking faith are simply
incompetent.

The likes of Google and Microsoft can and do hire competent PL researchers,
just as they hire competent AI researchers. And they do have a massive
incentive to improve software development quality and productivity.

I think the truth is that PL researchers simply haven't made the case for the
effectiveness of their work.

In part because it's extremely difficult to make that case empirically. All
the empirical studies I have seen suffer from huge and mostly unfixable
counfounders.

But I think another reason is that PL researchers seem to largely ignore
cognitive science and sociology. I haven't seen much discussion about the
impact of particular PL features on developers' state of mind in any realistic
context.

Nor have I seen much debate about programming languages as group communication
tools or about the different roles in which people interact with code as part
of a software development process. All of that is apparently considered out of
scope.

And that, I think, is the reason why it is so easy for many practitioners to
dismiss PL research out of hand. Even where PL research is being picked up
decades later it appears more fashion driven than evidence based.

~~~
pjmlp
If we look at blub engineering regarding mankind's history, impressive pieces
of work were build by recurring to thousand of workers each doing his/her
little thing across several years, even generations.

Yet, most likely we would use heavy construction building machines nowadays.

Niklaus Wirth admits on one of his papers that he expected developers would
pick Oberon by caring about tools for quality in software engineered, but he
was wrong about it.

Hoare has a similar remark on his Turing award speech.

So from my point of view it is a mix of sociology, fashion driven development
and office politics.

------
ernst_klim
I've always dreamed about ML language with verification support and dependent
types. Does it have something like Haskell's typeclasses or OCaml's modular
implicits? Does it support ad-hoc polymorphism in any way?

~~~
saosebastiao
It's not intending to be a general purpose language, and as such doesn't have
a lot of features that make software engineering easier. In fact, it
intentionally has a phenomenally slow compiler, because the compiler is
solving or attempting to solve various NP-Complete problems simultaneously.

Think of it as a language that will help build tools, analyzers, and possibly
linkable libraries for small scale but highly security-critical components,
but not necessarily the language you want to use to build an app server.

~~~
platz
although, if you don't use any refinement types in your program, i don't see
why you can't write general purpose programs and extract code to Ocaml and F#

------
fsloth
How does this compare with other verification tools such as TLA+ or Coq?

~~~
tom_mellior
Compared with Coq, F* makes it easier to write programs with side effects,
i.e., actually mutate variables and memory. There is a language fragment which
amounts to programming in a subset of C (and this is used for generating C
code for the verified crypto stuff in Project Everest mentioned in other
comments).

Also compared with Coq, proofs rely heavily on SMT solving with Z3 instead of
lots of manual tactics (yay!). On the other hand, where SMT solving fails, you
can _not_ resort to manual tactics because there is no tactic language. You
have to write proof terms without interactive support. (This may have changed
in the last few months, but I'm almost sure it hasn't.)

I wrote a bit about my experiences trying to prove things in F* two years ago:
[https://news.ycombinator.com/item?id=10984306](https://news.ycombinator.com/item?id=10984306)

Don't rely on any of that though, things will have changed in the meantime!

I'm optimistic about F*, but at the moment you have to be quite determined to
try to use it for fully verified programming. The same is true for Coq,
though.

~~~
gnulinux
Which language, do you think, is most practical for writing formally verified
programs?

~~~
neel_k
Probably the four most well-known pieces of software with end-to-end
verification of functional correctness are the CertiKOS microkernel from Yale
(verified in Coq), the SEL4 microkernel (verified in Isabelle), the Compcert C
compiler (verified in Coq), the CakeML ML compiler (verified in Isabelle).

Stopping short of full end-to-end functional correctness, there are lot more
notable examples, such as the Verve system at MSR (verified type/memory safety
using Boogie), and the Bedrock system at MIT (functional correctness down to a
fairly low-level IR, done in Coq), the miTLS/Everest TLS stack (protocol
correctness verified in F-star, most of the way down to a C-like
implementation), and the Iris project (a toolkit for verifying higher-order
concurrent programs, currently being used to formalize Rust including unsafe,
in Coq).

In machine-checked proof, the three biggest successes are the verification of
the Odd Order Theorem (in Coq), the Four Colour Theorem (in Coq), and the
Flyspeck project verifying the proof of the Kepler conjecture (in HOL).

In hardware verification, there has been a huge amount of work using ACL2 and
HOL, but I don't know this space as well.

Basically, Coq and Isabelle have the most actual successes, but other things
like F-star, Boogie and HOL have all worked as well.

~~~
logicchains
CakeML was verified in HOL ([https://hol-theorem-prover.org/](https://hol-
theorem-prover.org/)), not Isabelle.

~~~
neel_k
Yes, you're right. Thanks for the correction!

------
ZenoArrow
In terms of buzzword bingo, F* is as close to my ideal programming language as
I can think of, but I do wonder if it'll ever get the tooling support to make
it more attractive as a general purpose language.

~~~
tytytytytytytyt
What is it missing that something like SML has? Why couldn't I just switch
from another language to this today, assuming I don't care about IDE support
for it?

~~~
ZenoArrow
If you're interested, and you don't care much about tooling, go for it:

[https://github.com/FStarLang/FStar/blob/master/INSTALL.md](https://github.com/FStarLang/FStar/blob/master/INSTALL.md)

------
make3
...it's unfortunate the name kinda looks like a censored bad word

~~~
quickthrower2
It's compatiable with Coq

------
smsm42
What is it with this trend of giving languages unsearchable names?

~~~
viach
Searching for "f*" gives correct link in 1st result in Google. Do you use
Yahoo or other search engine?

~~~
ainar-g
I am not the other person, but when I try to find a JSON decoding module for
F* with "f* json", I get almost completely unrelated results. So, either there
is no JSON codec for F* (I guess they could use the F#'s one) or Google can't
find it.

~~~
arkkh
you would just type "fstar json" instead, just like you'd type "fsharp"
instead of "f#"

------
BLanen
Making another new language with such a short un-search-enginable name is not
a good idea imo.

~~~
abrookewood
Well, type "f*" into Google and it's the second result ... Why Facebook is
first, I have no idea.

~~~
splintercell
I believe that Google might have created a rule for that, because when you
type this in Yahoo [1] (or I believe even Solr, ElasticSearch or any of the
other full text based database search engines) you won't find this as a
result.

1\.
[https://search.yahoo.com/search?ei=UTF-8&fr=crmas&p=f*](https://search.yahoo.com/search?ei=UTF-8&fr=crmas&p=f*)

