HN Gopher Feed (2017-11-30) - page 1 of 10 ___________________________________________________________________
Type-safe GraphQL with OCaml
116 points by cuvius
https://andreas.github.io/2017/11/29/type-safe-graphql-with-ocam...___________________________________________________________________
rawrmaan - 1 hours ago
If you're interested in typed APIs, also check out RESTyped:
https://github.com/rawrmaan/restypedIt's an end-to-end way to type
check REST API calls and responses using TypeScript.
habitat_mike - 38 minutes ago
We're using restyped over at habitat in production - makes API
integrations a breeze!
kcorbitt - 2 hours ago
If ReasonML is able to form a real community, I have high hopes for
its long-term prospects. Such an enjoyable language to use! I think
their general approach of bootstrapping a community by lowering
impedance with the JS ecosystem is a decent one.In case anyone on
the OCaml team is reading this though, there are two language-level
changes that I think could do wonders for wider adoption. The first
is modular implicits: it feels so kludgy to have to type `a + b`
for integers, `a +. b` for floats and `a ^ b` for string
concatenation. I know it sounds like a small thing, but it makes
the language feel inelegant, and aesthetics are important. The
second is a good concurrency story, ideally one that is compatible
with JS-style async/await keywords for easy interop.I know those
are both being worked on; I just hope they become available in time
to coincide with the wave of interest in ReasonML!
jordwest - 53 minutes ago
You might like to try Fable and F#. I?ve been looking at it since
playing with Reason and Bucklescript, and so far I?ve found Fable
much easier to use and more featureful. The syntax is essentially
the same as OCaml, plus it?s whitespace aware.F# has implicit `+`
for basic types (though it?s not quite modular implicits). It
also has a really nice syntax for async computations, similar to
`async/await`. JS interop is much easier too. It can also run on
the server with .NET core if you don?t want to use node.The
output JS is slighter heavier and less optimised than
Reason/Bucklescript, and compile times slighter slower, but at
the moment those are trade offs I?m happy to make
bad_user - 16 minutes ago
The "+" in F# is really awkward because it tries catering to
both the ML type system it got and to the .NET type system
underneath, inherited from C#.This is a problem because when
type inference kicks in for plain functions, usage of that "+"
will make the compiler assume "int".But worse, "+" in C# is not
a method, but a static method and the compiler basically does
magic, because you don't have this behavior for plain static
methods and you don't have a generic interface in the language
for "+", there's no Number, no Monoid and static methods
themselves in C# can't be polymorphic.The whole notion of
"static methods" is broken btw and have nothing to do with OOP.
The only purpose of static methods is to enforce visibility
rules and this made some sense in C++, where you could have
functions living outside of classes, but even there the real
problem is the lack of useful namespacing.And F# inherited this
behavior, F# inherited static methods, along with math
operators described as static methods.So in order to abstract
over things that have "+", which is really needed in F#
otherwise you can't express really basic things for an FP
language like "List.sum", you have to (1) use inline functions,
which aren't translated directly to .NET functions and (2) use
a really awkward signature that instructs the type system that
the type has a "+" static method that it can use, e.g... >
let sum x y = x + y;; val sum : x:int -> y:int -> int
> let inline sum x y = x + y;; val inline sum : x: ^a
-> y: ^b -> ^c when ( ^a or ^b) : (static member ( +
) : ^a * ^b -> ^c) So this signature is really interesting
? the type system is saying that our "sum" needs either an A
type or a B type and one of them should have a static "+"
defined, doesn't matter which one.This is close to how type
classes work in other languages, however for the F# compiler
this is magic that doesn't scale and making use of "static
methods", a flawed concept, a signature that can't be encoded
in .NET's type system and therefore the function is forced to
be "inline".Which is another problem, because in F# inline
functions are more like macros, or in other words these
"inline" functions are not values. As soon you try using one as
a value, it gets materialized and you loose the type info. So
it is very ephemeral.Given this, frankly, I would rather have
OCaml's operators. At least they are plain functions.
nozzlegear - 25 minutes ago
I'll second the recommendation for F# and Fable. I'm currently
working on my first project with it, where both the client and
the server run F# and can share code/types. I haven't been this
happy with a stack in a long while. My one complaint is how...
salty some members of the F# community can be, mostly regarding
the rest of the Microsoft-backed .NET ecosystem.
StreamBright - 1 hours ago
I think the exact opposite. Finally a language where floats and
integers cannot be mixed together accidentally.
masklinn - 48 minutes ago
Haskell does not allow accidentally mixing floats and integers
together. In fact it doesn't even allow mixing finite and
infinite-precision integers together, despite using the same
operator for all number additions: Prelude> (3::Int) +
(4::Integer)
:2:13: Couldn't match
expected type ?Int? with actual type ?Integer? In the
second argument of ?(+)?, namely ?(4 :: Integer)? In
the expression: (3 :: Int) + (4 :: Integer) In an
equation for ?it?: it = (3 :: Int) + (4 :: Integer) It's not
by any means the only language with that property either.
kcorbitt - 1 hours ago
The type checker is capable of disallowing `float + int` while
still allowing `int + int` and `float + float`, which is what I
want.
k__ - 1 hours ago
I think the problem isn't that + +. and ^ look different, it's
that they are symbols.That's also what makes scala so
unapproachable, you get stuff like ++> or =*= that doesn't make
any sense.x + y makes sense to most peoplex ^ y not so much
s4vi0r - 41 minutes ago
Do you write Scala, or have you even looked at Scala code any
time in the past few years? I'm curious where this habit of
spreading FUD over Scala being operator heavy came from. Maybe
it was back when it first started reaching the HN front-page or
something?Scala is a super approachable language, without any
(that I can think of) strange operators in the stdlib. You
could make a case for Cats, I guess, but writing purely
functional Scala isn't necessary at all, and is something you
can approach when or if you feel comfortable to do so.
overtowed - 48 minutes ago
I'm a JS developer who tried to adopt Reason for a full stack
side project in September. There is so much to love about the
language and ecosystem. After about a week I decided to start
over in TypeScript for a single reason: the awkward interop with
promises compared to async/await, which is now available in
evergreen browsers and Node 8 without compiling down. I'll
definitely try again once this is ready.
aaron-lebo - 2 hours ago
I wish OCaml had the libraries and community of Go or Rust, I think
it'd be the most useful all-around language out there.
kornish - 21 minutes ago
It'd be great to have a good multicore concurrency/parallelism
story too. Looks like Multicore OCaml is slowly and steadily
making progress.
StreamBright - 1 hours ago
What exactly are you talking about? OCaml has decent libraries
for almost everything that you want to do. What exactly are you
missing?
kornish - 24 minutes ago
"decent" and "almost" are generous, and it's completely
realistic to say that Go, Java, Python, and Ruby's ecosystems
far outshine OCaml's.Love it as a language, but the ecosystem
and community have a ways to go before even slightly widespread
adoption.
Drup - 16 minutes ago
Do you have concrete examples of things you are missing?
lilactown - 2 hours ago
I'm hoping the movement around ReasonML[0] could lead to both the
web community being able to reap the benefits of OCaml's
fundamentals, while also giving people a point of introduction to
the OCaml community through web dev.It has been my experience
that the ReasonML community is incredibly welcoming to new
comers, and is moving at a break-neck pace to find the right
target of being approachable for people who are familiar with JS,
but also empowering users to use all of OCaml's power to create
web apps that are more simple and correct than they would
otherwise be.[0]: https://reasonml.github.io/
noncoml - 1 hours ago
I really don't understand why they had to invent a brand new
syntax.
ch4s3 - 1 hours ago
Probably because they were first trying to sell an ML
internally and it sounded like OCaml/Bucklescript didn't
catch on. I think the new syntax is the raison d'etre to some
extent.
k__ - 1 hours ago
Yes, many devs know stuff with C/Java/JavaScript like
syntax.
ch4s3 - 1 hours ago
Yeah, for better or worse that's ort of the default. I
think ML syntax is fine, and in some cases great. However
very few CS programs seem to teach MLs and AFAICT no
bootcamps do so these languages tend to get picked up by
dedicated autodidacts and academics. ReasonML might be a
nice bridge,
k__ - 46 minutes ago
I used LiveScript until ES2015 was a thing and found ML
syntax rather nice.
quicksnap - 1 hours ago
The short answer is that Reason's syntax is simpler and more
enjoyable to use. I simultaneously learned both OCaml and
ReasonML syntaxes and find Reason to be much easier to work
with.Perhaps people in Reason core will chime in with a more
detailed answer. Here's some official information:
https://reasonml.github.io/guide/ocaml/
bad_user - 2 minutes ago
OCaml's syntax on the other hand is stable, whereas it is
my impression that ReasonML changes with the same frequency
that JS libraries are changed.And the differences are very
superficial. What trips people is not the actual syntax,
but the concepts learned, the rules of the type system,
scoping rules, etc, which don't change.I'm glad that
ReasonML exists, but personally I would use OCaml instead
of risking that my codebase gets stuck with an old release
after only six months because the current version now has
different opinions about how to express anonymous
functions.
noncoml - 1 hours ago
Yeah, I guess the complaint comes from a guy that was
already familiar with OCaml's syntax.I guess if you don't
know OCaml, maybe the Reason syntax is more appealing.
lilactown - 1 hours ago
I do miss a lot of the parentheses-less-ness of OCaml
(and the old Reason syntax), but I'm honestly a lot more
comfortable at least broaching the topic of using it on
some work projects now that it's more JavaScript-y.
jordwest - 1 hours ago
I learnt Reason syntax first, then OCaml second. I prefer
the OCaml syntax, it seems simpler, cleaner, and doesn?t
hide the nice things about the language behind JavaScript
semantics.The biggest example I can think of is that
OCaml uses let..in, which reminds you that every function
is a statement. By contrast, the `;` in Reason hides that
fact.That said, it was the Reason syntax that first
brought me to the ecosystem, and I think it?s going to be
the catalyst that makes OCaml a big player in front end.
abiox - 1 hours ago
to varying degree, syntax matters. (for better or worse.)
the nice thing is that the semantics of ocaml haven't been
changed by reasonml.
apatil - 1 hours ago
I wish OCaml could just use the libraries of Go and Rust. They
can both compile to object files, and their type systems can be
mostly modelled in OCaml's.
tonyhb - 1 hours ago
OCaml can call external libraries via FFi functionality. I've
only done this with Bucklescript (which makes it easy, the JS
doesn't need to be compiled) though RWO walks through binding a
C library: https://realworldocaml.org/v1/en/html/foreign-
function-inter.... Wonder if this could be used with the
go/rust compiler?
apatil - 1 hours ago
It's definitely possible today, I just wish it were closer to
seamless. For example, it seems like it would be possible to
write a utility that takes a Go source file and emits a .cma,
and maybe an .mli so you can see what's in there.
noncoml - 1 hours ago
+1It's an awesome language, but the lack of libraries make it
pretty much useless for small teams.