88 ms·

Type-safe GraphQL with OCaml

207 points by cuvius 9y ago

aaron-lebo 9y 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.
- lilactown 9y 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/ https://reasonml.github.io/
  - noncoml 9y ago
    I really don't understand why they had to invent a brand new syntax.
    - ch4s3 9y 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__ 9y ago
        Yes, many devs know stuff with C/Java/JavaScript like syntax.
        ch4s3 9y 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__ 9y ago
        I used LiveScript until ES2015 was a thing and found ML syntax rather nice.
    - quicksnap 9y 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/ https://reasonml.github.io/guide/ocaml/
      - noncoml 9y 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 9y 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 9y 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.
        jordwalke 9y ago
        > “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.” ... Except in OCaml modules/files where you don’t use “in”. OCaml still has “semicolons” for let bindings - but they are just spelled as “in” or “let () =“ depending on the the context. All but one of these “semicolon” forms have nothing to do with language semantics and are only used to help the parser figure out how to group bindings and values. It doesn’t make OCaml’s core semantics worse or better- though it might make it harder to learn initially or copy/paste code between different contexts. The point of ; in Reason is merely for consistency - to have exactly one way to form bindings whether you are in a module or expression, allowing you to copy paste lines between the two contexts. Compare that to OCaml which requires different syntax depending on the context and copying values from module bodies to expressions requires a lot of editing. There may be other ways to achieve the same kind of consistency without semicolons and we are open to them - just so long as they are consistent across all contexts and easy to learn. (And as long as they don’t have major foot guns like JS’s ASI). (Often people object to ; as a parsing separator because they think it means “side effect”. It doesn’t. Not in Reason. Not in OCaml. OCaml features ubiquitous use of semicolons for everything from arrays, lists, to records field separators, all things that have nothing to do with side effects. And if you still haven’t had your fill, there’s the ;; double semicolon - which actually does typically imply side effects).
    - abiox 9y 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.
- noncoml 9y ago
  +1 It's an awesome language, but the lack of libraries make it pretty much useless for small teams.
- apatil 9y 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 9y 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-interface.html https://realworldocaml.org/v1/en/html/foreign-function-inter.... Wonder if this could be used with the go/rust compiler?
    - apatil 9y 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.
- StreamBright 9y 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 9y 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 9y ago
      Do you have concrete examples of things you are missing?
      - kornish 9y ago
        My biggest gripes are, in order: lack of library documentation, discoverability, maturity, and existence. Disclaimer: this is all anecdotal and the last time I dove into OCaml for side projects was about a year ago. 1. Documentation. Anecdotally, when you find a library that's not by Jane Street or top-20 starred on GitHub, the odds are low of finding a useful README or example code. God bless the developer if there are tests, but that seems to be rare as well. 2. Discoverability. OCaml's ecosystem sees tons of code for useful but non-major tasks floating around in various GitHub repos, where installation is tricky. I want to use a part of speech tagger? Great, I found a library with no documentation on GitHub - now how do I get it into my application? Why isn't it in the OPAM repo? I found an elasticsearch client library with no documentation on GitHub? Great - now why isn't it in the OPAM repo. 3. Maturity. Of the myriad library code floating around on GitHub, very little of it is what I would consider production-ready, by merit of lack of testing, lack of community, lack of documentation, and lack of frequency of updates. 4. Existence. Frequently, libraries don't exist which do in other languages. In the past couple weeks, I've pulled in Go and Java libraries for crontab parsing and execution, a MySQL ORM, inflection of English words, and various NLP utilities like the Stanford parser. All languages have these problems to some degree, but the fact of the matter is that while OCaml is a beautiful language for closed domains, I can't in good faith recommend it for building production systems to interact with the outside world. Other languages give you many of the benefits of the type system with much less of the hassle (looking at you, Kotlin). Writing production systems in OCaml can be done, absolutely - my hat is off to Yaron Minksy and the folks at Jane Street - but there are tradeoffs. And we're not even getting into developer tooling; this is just libraries. All counterarguments welcome; it'd be wonderful to hear that OCaml is gaining in developer productivity and production readiness over time. I have great faith that ReasonML can get lots of Javascript folks more interested, and the increased demand for libraries should hopefully lead to the filling of holes in the ecosystem. Most of OCaml's problems stem from it being simply unpopular.
- kornish 9y ago
  It'd be great to have a good multicore concurrency/parallelism story too. Looks like Multicore OCaml is slowly and steadily making progress.
- hajile 9y ago
  I wish SML were more popular. The syntax is much better and regular. I'll be done teaching you advanced SML language features before I could finish teaching the basics of ocaml. SML also has a multithreaded implementation in polyml and a better compiler in mlton. The standard library is not big enough, but at least there aren't 4 like in ocaml (std, core, batteries, and container). The only issue is that just a little more syntax would be nice, but the next gen group is working on that.
  - c-cube 9y ago
    Nowadays, OCaml has so many more syntactic sugar and typing goodies compared to SML, that it's not fair to compare them anymore. I'm no expert in SML, but from what I know: - OCaml's pattern matching is more powerful (more or-patterns, lazy, matching records with field-puning): `match x with lazy {x; y; z=(None | Some 0); _} -> x+y` - GADTs along with phantom types: many things are now type-safe (including the builtin format strings) - inline records in sum types: `type 'a tree = Empty | Node of { left: 'a tree; mutable key: 'a; right: 'a tree; }` also, I prefer `let x = y in …` rather than SML's equivalent which forces nesting because of the final `end`. In addition, flambda generates very good code. I don't know if it's as good as MLTon, but it's definitely an improvement. (edit: formatting)
    - hajile 9y ago
      Ocaml is a mess. Just like C++, PHP, or Perl, it's spent way too much time bolting extra stuff here and there until different codebases can look like completely different languages. Ocaml's features don't flow well together and make it very hard to teach the language (as used in the real world) to new developers. Golang has fewer features than Ocaml and is worse in almost every way, but people love it's simplicity. The best language features are the ones you can add without significantly increasing syntactic complexity. I agree that Ocaml has some great features that the current SML spec lacks. That spec is 20 years old now. There's plenty of room to look at Ocaml features and pick a good set that does enough of the things without blowing up the complexity. SML's let expression is definitely superior to Ocaml's. Ocaml has two different `let` expressions -- one for top-level and one for sub-expressions. To borrow from a comparison [here](http://adam.chlipala.net/mlcomp/ http://adam.chlipala.net/mlcomp/) (* Ocaml *) let six = 6 let rec fact x = if x = 0 then 1 else x * fact (x - 1) let six_fact = let six = 6 in let rec fact x = if x = 0 then 1 else x * fact (x - 1) in fact 6 (* SML *) val six = 6 fun fact x = if x = 0 then 1 else x * fact (x - 1) val six_fact = let val six = 6 fun fact x = if x = 0 then 1 else x * fact (x - 1) in fact 6 end SML groups multiple declarations together which provides greater clarity IMO while having an end keyword helps identify the let block.
- ernst_klim 9y ago
  >I wish OCaml had the libraries and community What's wrong with the libraries and community? There are thousands of libs in opam repository and although community may be smaller than Go's, the quality of OCaml community is incredibly high.
- Nelkins 9y ago
  Take a look at F#. Huge library (all of .NET), cross-platform, has JS as a target, and is a great community.
kcorbitt 9y 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!
- k__ 9y 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 people x ^ y not so much
  - s4vi0r 9y 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.
    - k__ 9y ago
      Last time I used Scala was 2010 or something. I never was a fan of the JVM stuff and Scala seemed like a reasonable alternative to Java, but I never got it.
    - 9y ago
rawrmaan 9y ago
If you're interested in typed APIs, also check out RESTyped: https://github.com/rawrmaan/restyped https://github.com/rawrmaan/restyped It's an end-to-end way to type check REST API calls and responses using TypeScript.
- habitat_mike 9y ago
  We're using restyped over at habitat in production - makes API integrations a breeze!
michaelsbradley 9y ago
Would wiring up ocaml-graphql-server resolvers to OCanren[+] have any interesting use cases? [+] https://github.com/dboulytchev/OCanren https://github.com/dboulytchev/OCanren
z3t4 9y ago
Having spent my entire career, 15+ years, in "weakly typed" or whatever you call it, languages, such as basic, vbScript and JavaScript I don't get this type hype. In "unsafe" languages that have overflows I get it will help to make it less unsafe, but in high level languages such as JavaScript why do you even need static (not sure I'm using the right vocabulary) typing !? Such as HypeScript, err I mean TypeScipt. Is there an entire field of programmers out there that get bugs because they are mixing numbers and strings !? I also did that a lot as a beginner in JavaScript as the plus sign is used both as concatenation and addition. I read a study here on HN a while ago (that probably was sponsored by $M) that stated using TypeScript would prevent most of the bugs found on GitHub, but of course there where no examples of where type annotation would have helped. So what's with this type frenzy ?
- TheAsprngHacker 9y ago
  If you don't make type mistakes, good for you, but why not let the compiler or interpreter provide a safety net, just in case? In addition, static typing makes refactoring easier because you can confidently redesign your code and let the implementation tell you which types you haven't yet adjusted. Besides, type inference means that you do not even have to write out the type yourself in many cases. (However, to do so is better for documentation.) Also, why do you think that Microsoft is secretly pushing static typing? /Maybe/ it's shilling for TypeScript, but there are a lot of other statically typed languages that compile to JavaScript, such as Elm.
  - z3t4 9y ago
    I have nothing against type inference, static analysis, or type notation for the sake of performance optimizations. For a high level language I think it's up to the compiler to figure out the right type to use and keep things safe. And I think static typing is over-hyped as the holy grail of programming. And you can still use type annotation for documentation in a dynamic language by naming the variables such as nFoo = 1, strFoo = "foo", arrFoo = [], although I advocate just giving the variables prober names such as age = 1, name = "foo", friends = [] JavaScript is the perfect enterprise language. And that's where $M makes most of it's money. But they do not fully control JavaScript, and they have little control over NodeJS. So what do you do ? Embrace, extend, and extinguish! You add enterprise feature! That will convert users back into your ecosystem again! While at the same time trying to hurt JavaScript and NodeJS. Interestingly though Samsung recently bought NodeJS and their new devices does have JavaScript support, so hopefully NodeJS and JavaScript will not be too easy to extinguish.
deleted 9y ago
[deleted]

207 points by cuvius 9y 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.

lilactown 9y 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/ https://reasonml.github.io/
- noncoml 9y ago
  I really don't understand why they had to invent a brand new syntax.
  - ch4s3 9y 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__ 9y ago
      Yes, many devs know stuff with C/Java/JavaScript like syntax.
      - ch4s3 9y 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__ 9y ago
        I used LiveScript until ES2015 was a thing and found ML syntax rather nice.
  - quicksnap 9y 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/ https://reasonml.github.io/guide/ocaml/
    - noncoml 9y 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 9y 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 9y 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.
        jordwalke 9y ago
        > “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.” ... Except in OCaml modules/files where you don’t use “in”. OCaml still has “semicolons” for let bindings - but they are just spelled as “in” or “let () =“ depending on the the context. All but one of these “semicolon” forms have nothing to do with language semantics and are only used to help the parser figure out how to group bindings and values. It doesn’t make OCaml’s core semantics worse or better- though it might make it harder to learn initially or copy/paste code between different contexts. The point of ; in Reason is merely for consistency - to have exactly one way to form bindings whether you are in a module or expression, allowing you to copy paste lines between the two contexts. Compare that to OCaml which requires different syntax depending on the context and copying values from module bodies to expressions requires a lot of editing. There may be other ways to achieve the same kind of consistency without semicolons and we are open to them - just so long as they are consistent across all contexts and easy to learn. (And as long as they don’t have major foot guns like JS’s ASI). (Often people object to ; as a parsing separator because they think it means “side effect”. It doesn’t. Not in Reason. Not in OCaml. OCaml features ubiquitous use of semicolons for everything from arrays, lists, to records field separators, all things that have nothing to do with side effects. And if you still haven’t had your fill, there’s the ;; double semicolon - which actually does typically imply side effects).
  - abiox 9y 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.
noncoml 9y ago
+1 It's an awesome language, but the lack of libraries make it pretty much useless for small teams.
apatil 9y 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 9y 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-interface.html https://realworldocaml.org/v1/en/html/foreign-function-inter.... Wonder if this could be used with the go/rust compiler?
  - apatil 9y 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.
StreamBright 9y 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 9y 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 9y ago
    Do you have concrete examples of things you are missing?
    - kornish 9y ago
      My biggest gripes are, in order: lack of library documentation, discoverability, maturity, and existence. Disclaimer: this is all anecdotal and the last time I dove into OCaml for side projects was about a year ago. 1. Documentation. Anecdotally, when you find a library that's not by Jane Street or top-20 starred on GitHub, the odds are low of finding a useful README or example code. God bless the developer if there are tests, but that seems to be rare as well. 2. Discoverability. OCaml's ecosystem sees tons of code for useful but non-major tasks floating around in various GitHub repos, where installation is tricky. I want to use a part of speech tagger? Great, I found a library with no documentation on GitHub - now how do I get it into my application? Why isn't it in the OPAM repo? I found an elasticsearch client library with no documentation on GitHub? Great - now why isn't it in the OPAM repo. 3. Maturity. Of the myriad library code floating around on GitHub, very little of it is what I would consider production-ready, by merit of lack of testing, lack of community, lack of documentation, and lack of frequency of updates. 4. Existence. Frequently, libraries don't exist which do in other languages. In the past couple weeks, I've pulled in Go and Java libraries for crontab parsing and execution, a MySQL ORM, inflection of English words, and various NLP utilities like the Stanford parser. All languages have these problems to some degree, but the fact of the matter is that while OCaml is a beautiful language for closed domains, I can't in good faith recommend it for building production systems to interact with the outside world. Other languages give you many of the benefits of the type system with much less of the hassle (looking at you, Kotlin). Writing production systems in OCaml can be done, absolutely - my hat is off to Yaron Minksy and the folks at Jane Street - but there are tradeoffs. And we're not even getting into developer tooling; this is just libraries. All counterarguments welcome; it'd be wonderful to hear that OCaml is gaining in developer productivity and production readiness over time. I have great faith that ReasonML can get lots of Javascript folks more interested, and the increased demand for libraries should hopefully lead to the filling of holes in the ecosystem. Most of OCaml's problems stem from it being simply unpopular.
kornish 9y ago
It'd be great to have a good multicore concurrency/parallelism story too. Looks like Multicore OCaml is slowly and steadily making progress.
hajile 9y ago
I wish SML were more popular. The syntax is much better and regular. I'll be done teaching you advanced SML language features before I could finish teaching the basics of ocaml. SML also has a multithreaded implementation in polyml and a better compiler in mlton. The standard library is not big enough, but at least there aren't 4 like in ocaml (std, core, batteries, and container). The only issue is that just a little more syntax would be nice, but the next gen group is working on that.
- c-cube 9y ago
  Nowadays, OCaml has so many more syntactic sugar and typing goodies compared to SML, that it's not fair to compare them anymore. I'm no expert in SML, but from what I know: - OCaml's pattern matching is more powerful (more or-patterns, lazy, matching records with field-puning): `match x with lazy {x; y; z=(None | Some 0); _} -> x+y` - GADTs along with phantom types: many things are now type-safe (including the builtin format strings) - inline records in sum types: `type 'a tree = Empty | Node of { left: 'a tree; mutable key: 'a; right: 'a tree; }` also, I prefer `let x = y in …` rather than SML's equivalent which forces nesting because of the final `end`. In addition, flambda generates very good code. I don't know if it's as good as MLTon, but it's definitely an improvement. (edit: formatting)
  - hajile 9y ago
    Ocaml is a mess. Just like C++, PHP, or Perl, it's spent way too much time bolting extra stuff here and there until different codebases can look like completely different languages. Ocaml's features don't flow well together and make it very hard to teach the language (as used in the real world) to new developers. Golang has fewer features than Ocaml and is worse in almost every way, but people love it's simplicity. The best language features are the ones you can add without significantly increasing syntactic complexity. I agree that Ocaml has some great features that the current SML spec lacks. That spec is 20 years old now. There's plenty of room to look at Ocaml features and pick a good set that does enough of the things without blowing up the complexity. SML's let expression is definitely superior to Ocaml's. Ocaml has two different `let` expressions -- one for top-level and one for sub-expressions. To borrow from a comparison [here](http://adam.chlipala.net/mlcomp/ http://adam.chlipala.net/mlcomp/) (* Ocaml *) let six = 6 let rec fact x = if x = 0 then 1 else x * fact (x - 1) let six_fact = let six = 6 in let rec fact x = if x = 0 then 1 else x * fact (x - 1) in fact 6 (* SML *) val six = 6 fun fact x = if x = 0 then 1 else x * fact (x - 1) val six_fact = let val six = 6 fun fact x = if x = 0 then 1 else x * fact (x - 1) in fact 6 end SML groups multiple declarations together which provides greater clarity IMO while having an end keyword helps identify the let block.
ernst_klim 9y ago
>I wish OCaml had the libraries and community What's wrong with the libraries and community? There are thousands of libs in opam repository and although community may be smaller than Go's, the quality of OCaml community is incredibly high.
Nelkins 9y ago
Take a look at F#. Huge library (all of .NET), cross-platform, has JS as a target, and is a great community.

kcorbitt 9y 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!

k__ 9y 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 people x ^ y not so much
- s4vi0r 9y 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.
  - k__ 9y ago
    Last time I used Scala was 2010 or something. I never was a fan of the JVM stuff and Scala seemed like a reasonable alternative to Java, but I never got it.
  - 9y ago

rawrmaan 9y ago

If you're interested in typed APIs, also check out RESTyped: https://github.com/rawrmaan/restyped https://github.com/rawrmaan/restyped It's an end-to-end way to type check REST API calls and responses using TypeScript.

habitat_mike 9y ago
We're using restyped over at habitat in production - makes API integrations a breeze!

michaelsbradley 9y ago

Would wiring up ocaml-graphql-server resolvers to OCanren[+] have any interesting use cases? [+] https://github.com/dboulytchev/OCanren https://github.com/dboulytchev/OCanren

z3t4 9y ago

Having spent my entire career, 15+ years, in "weakly typed" or whatever you call it, languages, such as basic, vbScript and JavaScript I don't get this type hype. In "unsafe" languages that have overflows I get it will help to make it less unsafe, but in high level languages such as JavaScript why do you even need static (not sure I'm using the right vocabulary) typing !? Such as HypeScript, err I mean TypeScipt. Is there an entire field of programmers out there that get bugs because they are mixing numbers and strings !? I also did that a lot as a beginner in JavaScript as the plus sign is used both as concatenation and addition. I read a study here on HN a while ago (that probably was sponsored by $M) that stated using TypeScript would prevent most of the bugs found on GitHub, but of course there where no examples of where type annotation would have helped. So what's with this type frenzy ?

TheAsprngHacker 9y ago
If you don't make type mistakes, good for you, but why not let the compiler or interpreter provide a safety net, just in case? In addition, static typing makes refactoring easier because you can confidently redesign your code and let the implementation tell you which types you haven't yet adjusted. Besides, type inference means that you do not even have to write out the type yourself in many cases. (However, to do so is better for documentation.) Also, why do you think that Microsoft is secretly pushing static typing? /Maybe/ it's shilling for TypeScript, but there are a lot of other statically typed languages that compile to JavaScript, such as Elm.
- z3t4 9y ago
  I have nothing against type inference, static analysis, or type notation for the sake of performance optimizations. For a high level language I think it's up to the compiler to figure out the right type to use and keep things safe. And I think static typing is over-hyped as the holy grail of programming. And you can still use type annotation for documentation in a dynamic language by naming the variables such as nFoo = 1, strFoo = "foo", arrFoo = [], although I advocate just giving the variables prober names such as age = 1, name = "foo", friends = [] JavaScript is the perfect enterprise language. And that's where $M makes most of it's money. But they do not fully control JavaScript, and they have little control over NodeJS. So what do you do ? Embrace, extend, and extinguish! You add enterprise feature! That will convert users back into your ecosystem again! While at the same time trying to hurt JavaScript and NodeJS. Interestingly though Samsung recently bought NodeJS and their new devices does have JavaScript support, so hopefully NodeJS and JavaScript will not be too easy to extinguish.

deleted 9y ago

[deleted]