GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
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.