Tech has a diversity problem: marginalised people are being pushed out
of the industry; their voices and experiences are erased. Open Source
is particularly bad, with too few contributors who aren’t white, male,
cisgender and able-bodied.

What if things were different? What if we could create spaces that are
welcoming, where we show empathy and compassion? What if those
qualities could reflect in our work, ultimately helping us create
better software?

In this talk, you will hear stories of first-time contributions,
successful examples in supporting and mentoring newcomers, and find
out steps you can take as an Open Source contributor or maintainer to
make your community more inclusive.

Bringing new technologies to large-scale enterprises is a challenge in
which we are involved quite often. In this talk we will reflect on our
current experience with Reason based on a real implementation.

Today every major language has some kind of library that helps a
developer formatting his or her code. Tools like Prettier, Gofmt and
Refmt are setting new standards and have a deep impact on our day to
day programming.

But what does it actually mean to format code? Does it mean pressing
a magical button to align your code? Is it more than the automatic
insertion of trailing commas your colleague always seems to forget?
Why are we even doing it? How is it going to impact us as programmers
to get better?

“Code formatting” is an opaque ocean, we’ve done a really poor job
at explaining what code formatting actually means in today’s
world. The recent hype around code formatting tools defaults us into
thinking that we can’t live without them anymore. We need to stop and
ask why we’re using these tools. Is it really the best course of
action?

Based on my experience contributing to Reason over the past 1.5 years,
this lightning talk will be a short, critical deep dive in the past,
present & future of our beloved Reason formatter Refmt.

Traditionally, soundly typed-language are warm and cozy in their own
world, but as soon as they have to deal with the outside world (say,
talking to a REST API), the pain quickly sets in: trying to keep a
type definition in sync with a moving external service, manual
conversion back and forth, and lots of boilerplate.

Well no more! Proper GraphQL support in ReasonML libraries means that
we can have full-stack safety, knowing that if our programs compile,
the server can satisfy our requirements! And on top of that, we get
all the other GraphQL goodies, like tooling, in-editor auto-complete,
and fantastic compile-time optimizations, for free!

But what about the server-side, you ask? There are so many places
things can go wrong when trying to maintain the promises you give to
your GraphQL clients, I hear you cry out.

Dry your eyes, friend, for ocaml-graphql-server is here to guide you
to the happy full-stack GraphQL+Reason world you’ve been dreaming of,
where whole classes of errors are eliminated.

As in any good talk however, we’ll also take a look at some of the
painful points of this approach, and how ReasonML might make some
tasks more difficult, so that you can leave with a confident
understanding of whether this new frontier is one you want to
brave any time soon.

Reason community is growing rapidly, and a lot of people are
interested in leveraging it on their servers. One way to achieve this
is to use native OCaml compiler. It produces exceptionally performant
binaries, but the native ecosystem is scarce, and you will struggle
with finding solutions for very common tasks.

Another option is to use BuckleScript and compile everything to
JavaScript. You would regain access to the vast Node.js ecosystem but
would have to sacrifice performance. It seems that you have to choose
either ecosystem or performance.

In this talk, I will show how to preserve both by compiling Reason
code to native Node.js addons. I will present a toolkit that makes it
easy and fun, walk through its features and examples and talk a bit
about its internals and advanced OCaml features used.

Would you rather have a community like npm, where there are hundreds
of thousands of packages, but very few feel stable, or one like opam,
with only a few thousand packages and a much more rigorous vetting
system? How do language and community decisions affect the pull
between security and freedom, safety and agility? Can we design a
system that gives us both?

Come learn about how tools, language features, and community
structures all impact the “feel” of a developer community, and what
tricks Reason could borrow from other communities to ensure that we
can have freedom to publish without fearing change.