Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Type-safe GraphQL with OCaml

andreas.github.io

Post reply on HN
Print view View original

71–80 of 102 posts

Re: Type-safe GraphQL with OCaml

#71

Post by kornish »

ernst_klim wrote: post #64
kornish wrote: post #41

Earlier quoted context omitted.

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…

>crontab parsing and execution 10 minutes with angstrom and unixlib? Sure, ocaml does not have javascript/go-style libs like leftpad, but it provide a great ability to solve generic tasks with more generic libraries like angstrom, menhir, faraday, lwt or react. >I can't in good faith recommend it for building production systems to interact with the outside world Why is that so? I believe in exactly opposite. We are b…

Totally fair - no experience here in deploying OCaml for production. Agreed that the language and major libraries are phenomenal. My intuition is that the maintenance time cost of writing and extending these abstractions from scratch in the face of changing business requirements is higher than the time cost of using a less perfect language but richer ecosystem; but that could be totally wrong.

Glad the language is shining in your situation. Can you elaborate more on team composition, tenure, learning curve, and use case?

> 10 minutes with angstrom and unixlib?

https://github.com/robfig/cron is ~1.5KLOC - sure, it's Go, but that's a bit more than 10 minutes in any language, especially to change gears and think through edge cases. I'd prefer for things to Just Work.

> low quality third party libs (which are usually provided by go)

My experience with Go libs is that because the ecosystem is large and expanding fast, a surprising number of problem domains have one or two great standout libraries among a ton of noise. But it turns out one or two great libraries is frequently all you need. I dislike the language from a theoretical standpoint but after working full time in it for several years, can't deny that it's good for Getting Shit Done.

Re: Type-safe GraphQL with OCaml

#72

Post by ernst_klim »

kornish wrote: post #71
ernst_klim wrote: post #64

Earlier quoted context omitted.

>crontab parsing and execution 10 minutes with angstrom and unixlib? Sure, ocaml does not have javascript/go-style libs like leftpad, but it provide a great ability to solve generic tasks with more generic libraries like angstrom, menhir, faraday, lwt or react. >I can't in good faith recommend it for building production systems to interact with the outside world Why is that so? I believe in exactly opposite. We are b…

Totally fair - no experience here in deploying OCaml for production. Agreed that the language and major libraries are phenomenal. My intuition is that the maintenance time cost of writing and extending these abstractions from scratch in the face of changing business requirements is higher than the time cost of using a less perfect language but richer ecosystem; but that could be totally wrong. Glad the language is sh…

>requirements is higher than the time cost of using a less perfect language but richer ecosystem; but that could be totally wrong.

Believe me, breakdowns will cost much more, especially if your device has no ssh, connected via ASI/some military obscure one-directional interface. I found that in many fields it's incredibly hard to approve third party libs usage, even some basic stuff like boost.

>~1.5KLOC - sure, it's Go, but that's a bit more than 10 minutes

Well, it is Go.

This is go json parser:

https://github.com/buger/jsonparser/blob/master/parser.go

And this is angstrom:

https://github.com/inhabitedtype/angstrom/blob/master/exampl...

cron should be easier, it's either vars or cronlines, which are trivial. I prefer to write it in angstrom than to catch some unexpected panic in go because of type coercion or similar shit.

Re: Type-safe GraphQL with OCaml

#73

Post by z3t4 »

johntran wrote: post #56
z3t4 wrote: post #38

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…

https://blog.acolyer.org/2017/09/19/to-type-or-not-to-type-q... TL;DR: both Flow and TypeScript are pretty good, and conservatively either of them can prevent about 15% of the bugs that end up in committed code.

Thanks for finding the study! And it actually is sponsored by $M no wonder the conclusion is that using a $M product will help catch bugs.

Re: Type-safe GraphQL with OCaml

#74

Post by raphinou »

nozzlegear wrote: post #29
jordwest wrote: post #23

Earlier quoted context omitted.

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…

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.

I would be interested to know how you share code between client and server. Can you share info/code?

Having one code base like with ocsigen would be even better. Anything like that available?

Re: Type-safe GraphQL with OCaml

#75

Post by tom_mellior »

KirinDave wrote: post #48
z3t4 wrote: post #38

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…

Dear z3t4, I write this letter from the distant past, late in the month of November in the distant pass of 2017. From your lofty throne upon a future so bright, I urge you to remember the sad lives we lead as a return code type mismatch caused every Mac OS X machine running modern software to be accessible by anyone with physical access by typing "root" into the login field then hammering on the Enter key like a 9 ye…

> a return code type mismatch caused every Mac OS X machine [...]

I don't doubt you, but I was just trying to read up on details of this and the internet is so full of fluff pieces that I can't find anything technical real quick. Would you have a link to a writeup of the bug behind this issue?

Re: Type-safe GraphQL with OCaml

#76

Post by c-cube »

hajile wrote: post #58
aaron-lebo wrote: post #2

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.

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 littl…

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)

Re: Type-safe GraphQL with OCaml

#77

Post by masklinn »

baddox wrote: post #51
kbenson wrote: post #45

Earlier quoted context omitted.

> 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. That's interesting, as being forced to use the same operator for addition and for concatenation (and what's more with the result of mixed types if allowed often d…

Couldn’t the type system still allow using the + operator, but requiring the values on both sides to have the same type? You could do more magic like having int + float return a float, but I’d even prefer typing “int.toFloat + float” than “int +. float”.

> Couldn’t the type system still allow using the + operator, but requiring the values on both sides to have the same type?

'course it could, multiple languages already do that e.g. Rust (https://play.rust-lang.org/?gist=530fa94d3f451e896ac0d3ddeaf...), Haskell (https://repl.it/repls/FrozenBlondUmbrellabird), Swift (https://repl.it/repls/LuckyNaiveBream)

Re: Type-safe GraphQL with OCaml

#78

Post by StreamBright »

ernst_klim wrote: post #64
kornish wrote: post #41

Earlier quoted context omitted.

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…

>crontab parsing and execution 10 minutes with angstrom and unixlib? Sure, ocaml does not have javascript/go-style libs like leftpad, but it provide a great ability to solve generic tasks with more generic libraries like angstrom, menhir, faraday, lwt or react. >I can't in good faith recommend it for building production systems to interact with the outside world Why is that so? I believe in exactly opposite. We are b…

And I consider this as a great thing. It is much better to have a few rock solid libraries than a massive amount of subpar ones.

Re: Type-safe GraphQL with OCaml

#80

Post by runeks »

kbenson wrote: post #45
kcorbitt wrote: post #4

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 implic…

> 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. That's interesting, as being forced to use the same operator for addition and for concatenation (and what's more with the result of mixed types if allowed often d…

> Not allowing the addition of floats and ints together is less of a fundamental issue, but it also helps quite a few problems.

Needing to use +. to add two floats seems odd to me as well, and I believe this is what OP was pointing out. I would agree with you that adding and int to a float should require conversion of one of the arguments, but I see no need for a separate + operator for floats and ints.

Post reply on HN