[peterhunt]

I want Go but with a really strong static type system. What do I use?

Haskell's Hackage seems to be full of broken packages.

OCaml seems to be stuck in 1999.

F#/Mono is pretty great, but tough to find quality libraries that work with the tools I use (postgres etc)

Anything I'm missing?

[silentOpen]

You're missing that OCaml isn't stuck in 1999. OCaml now has an excellent package manager, cool new features, lots of system libraries, and a growing community. What do you find out-dated about it? Check out http://www.realworldocaml.org

[peterhunt]

I want to serve a JSON response over HTTP, preferably from a standalone server (like django etc). Later I want to talk to Postgres and memcached.

Do I use this thing? http://ocsigen.org/ocsigenserver/ All the docs either don't do what I'm looking for (i.e set up a web server to serve some static files) or are broken links!

OCaml is actually what I'd prefer to use (since I had a blast with SML/NJ)

I'll check out that book, thanks! But I did just skim the ToC and it has nothing about serving HTTP. Serving HTTP is like my #1 use case for anything these days :/

[djs55]

For HTTP I always use 'ocaml-cohttp' (opam install cohttp):

https://github.com/mirage/ocaml-cohttp/blob/master/examples/...

For JSON I normally use 'Jsonm' but I've heard good things about 'Ezjsonm':

https://github.com/samoht/ezjsonm

I've not personally tried them but 'postgresql-ocaml' and 'ocaml-memcached' look plausible.

[lpw25]

I think all the pieces are there to do that (e.g. cohttp, yojson, atdgen, PG'OCaml), although perhaps not in a single easy to use framework.

Maybe http://rgrinberg.com/blog/2014/04/04/introducing-opium/ is relevant.

[DCKing]

Scala? Strong static types, lots of quality libraries both for Scala and 'inherited' from Java. Fits well among the languages you already mention.

[peterhunt]

Nice. I've heard some complaints about compile times -- are they founded?

[mhax]

Yep. Compile times are comparatively long - the larger the project, the more this is an issue. For me it's not a deal breaker.

[th0br0]

Scala 2.12 will have a new compiler backend which should speed things up considerably. [1]

Other than that, as an avid Scala fan, I've been long wondering why people favour Go so much. Arguably, if you've started out with RoR, then Node.js was a great improvement (dynamic typing with awesome speed). Then came Go, which solves many of the issues you tend to encounter with Node.js. So now, after it has reasonably matured, many people are pivoting to it. Scala, while having a rather "bloated" core library (i.e. quite exhaustive), already does most that Go does (i.e. an Actor is reasonably close to a goroutine etc.) and has an awesome type system. But then, I'm biased and YMMV ;)

[1] https://magarciaepfl.github.io/scala/

[randallsquared]

Compared to Scala, Go is incredibly simple, both to learn and to use. If you don't have a lot of experience with Java and the JVM, Go also avoids that whole avalanche of complexity, apart from Scala itself.

[DCKing]

> Compared to Scala, Go is incredibly simple, both to learn and to use.

Probably true. Go has a far more simple language specification, but it's not as if Scala is particularly alien.

> If you don't have a lot of experience with Java and the JVM, Go also avoids that whole avalanche of complexity, apart from Scala itself.

Why is Java or the JVM an 'avalanche of complexity' for Scala?

[randallsquared]

I meant only that if you want to use Scala, you'll inevitably have to also know Java. It's two languages for the benefit of one. The JVM comes with its own issues: which JDK do I use[1]? What happens when one library I want to use recommends a different JDK than another library I want to use? Build tools questions: ant, maven, gradle? Oh, I need to learn Groovy, too? Three languages for the benefit of one. Yay.

There's just an enormous amount of stuff to learn, and most of it is required-but-incidental; none of it (except Scala, in our example) is an inherently necessary part of getting from learning to a production system running Scala on the JVM, but you will end up having to become conversant with many of these things, and probably dozens of similar infrastructure and tooling systems.

[1] Haha. I was thinking this was mainly between Oracle's and openjdk, because that's what seems easily available, but it looks like there are four or five currently updated JVMs: http://en.wikipedia.org/wiki/Comparison_of_Java_virtual_mach...

[DCKing]

There's a difference between "the language has long compile times" and the implied "you spend a lot of time waiting during development".

It is true that Scala's compile times are long, but the tooling provides ways so that you don't have to wait so much during development.

[dons]

> full of broken packages.

Citation needed. Hackage goes to great lengths to validate packages as much as possible. Other support systems do continuous integration and further validation, if you're looking for well regarded package subsets.

Maintaining 6000+ open source packages is a pretty serious task.

[peterhunt]

I dunno, I tried installing snap, yesod and happstack (the three top web frameworks apparently) about a month ago and after about 20 minutes of compiling all failed to install (some had missing packages, others had the packages but they failed to build). I'm running a no-frills MBP with bash, which I would imagine is a fairly popular dev environment.

All I want to do is serve an HTTP request.

[cgag]

I think you should figure out what's going on with with your dev environment and go with Haskell. Are you using the Haskell platform? If so I would ditch that and make sure to install everything in a sandbox, I've had very little trouble with cabal since I went with just cabal + sandboxes. I'm on linux but Chris Allen's guide has instructions for a minimal OSX install: https://github.com/bitemyapp/learnhaskell

If none of that helps, come to freenode #haskell, those packages really should work.

[peterhunt]

OK, you gave me the encouragement to try it again.

I ran into a bunch of bugs getting haskell platform set up correctly on OSX (wouldn't remove my old version, had to manually remove GHC, also reported this one https://github.com/haskell/cabal/issues/1980) but after reinstalling Haskell platform it seems to be working better. Thanks.

[artemshitov]

There is also a known issue with XCode and OS X >10.9, which may cause some packages to fail to compile. Haskell Platform download page includes instructions on how to avoid it: http://www.haskell.org/platform/mac.html

[marcosdumay]

If you are using the GHC and Haskell-Plataform provided by your distro, I'd recommend you get the latest version and install it yourself. Both are changing a lot and some distros (Debian, for example) do not keep up. (Also, that'll avoid a few severe bugs GHC had up to a few years ago.)

[jackyb]

As far as I know, Go already has a really strong static type system (int32 cannot be assigned to int for example). Which parts are weak?

[cgag]

No generics (parametric polymorphism), no algebraic data types. You should learn some Haskell or Ocaml even if you don't plan on using it in production. Go's type system is weak.

Edit: I don't think there's anything like type classes either but I'm not 100%.

[NateDad]

I don't understand why all the ML-lovers have to bash Go for not being OCaml or Haskell or Rust. It's like bashing Python for not having static typing. Go is not one of those ML languages with a complicated type system. It has a simple type system. This is a feature for Go, just as dynamic typing is a feature for python. Neither is right or wrong or backwards. They're different design choices. If you don't like it, that's fine, don't use it. But it's not an inherently bad choice.

[peterhunt]

Yeah, I mainly want to get a feel for building a real system using a strict type system and algebraic data types. I've done some toys with them but nothing real yet.

[otikik]

> Go's type system is weak.

It is strong enough for me.

I see the lack of algebraic data types and type classes as a feature, honestly. It means I can learn the things I need and start working in 2 days instead of in 2 weeks or a month.

I sometimes need generics, but not frequently enough to miss them.

You think Go's type system is weak. I think Haskell's type system is overcomplicated. So, there.

[cgag]

Even if it were true that it were overly complicated, that wouldn't change the fact that it's much more powerful than Go's.

“When I work at this system up to 12hrs a day, I’m profoundly uninterested in what user interface a novice user would prefer.” —Erik Naggum

Are you using visual basic because you could pick it up in 2 days instead of taking a month to learn Go?

It's easy to learn because it doesn't do anything interesting that you're not already familiar with. If you're not missing them, you're missing out on simple beautiful abstractions like map and filter. You're also missing out on type safe libraries for containers. It's not possible to write a generic container without casts to interface{}, which is a shame imo.

[otikik]

> visual basic

Bringing The Language Which Shall not Be Named to the discussion is a low blow. But I deserve it. My phrase about overcomplication was flamebaity and uncalled for, and I apologize.

> you're missing out on simple beautiful abstractions like map and filter

The thing is, in Go, those take almost as much space as a plain for loop.

I know, you will tell me "that's because Go's too verbose". I will grant that it's more verbose than Haskell.

But I am not doing maps and filters all the time in my code.

> It's not possible to write a generic container without casts to interface{}, which is a shame imo.

My point is that generic containers are the feature where generics are genuinely needed. And in those cases interface{} makes it possible. Not super-awesome, but possible. I actually like that the language doesn't bend over to fulfill something that looks almost like an edge case. It is not "programming with mathematics". It's still "moving bits around". But the bits can be moved with ease.

[jacques_chester]

interface{} doesn't give you generics. The point of generics is to give you two distinct things:

1. You can write code that performs identical logic for a range of different data types, without having to know what they are.

2. That code can be checked for type safety.

interface{} gives you half of 1. You can write code that performs common logic and takes an interface{}, but then that code has to manually switch on type, or convert type before running.

Which gives you trouble with 2. Once you don't have a distinct type, you can't check for safety. All the compiler can do is check that an interface{} is passed in; which is a pretty weak guarantee. Meanwhile, in languages with generics, the you can write a generic method that uses the + operator and the compiler can check whether it works for numbers (OK), strings (OK), HTTP servers (uh oh, stop the bus!)...

[DCKing]

Go's type system being weak is a factual statement. Haskell's type system being overcomplicated is an opinion.

One might prefer a weak type system over a strong type system, but that's a different discussion. The parent clearly expressed that he wants a static strong type system.

[otikik]

> weak is a factual statement

I disagree. "Weakly typed" does not even have a precise definition.

Defining "strongly typed" as "the way Haskell does it" and anything less as "weakly typed" is an opinion.

I agree that Haskell types are stronger than Go. That does not does not mean that Go is "weakly typed". It's "less strongly typed than Haskell".

> The parent clearly expressed that he wants a static strong type system.

I was not contesting that, only the classification of Go as "weakly typed".

[DCKing]

I'm not saying Go is a weakly typed language. I'm just saying that the statement "Go is a weakly typed language" is a factual statement that may be true or false. You were wrong in positing the claims "weakly typed" and "overcomplicated" as if they are somehow equally valid, because one is a factual claim and the other is an opinion.

In the most conventional definitions, Go is a strongly typed language. So this factual statement appears to be false.

As always, there is some confusion in this topic about dynamic typing vs static typing. There seems to be plenty of dynamic typing in Go, which in itself does not make its type system weak.

[NateDad]

Factual implies correct. But you are incorrect that it is weak. You're looking for objective and subjective.

[personZ]

Go's type system being weak is a factual statement. Haskell's type system being overcomplicated is an opinion.

Calling one weak and the other overcomplicated are both completely subjective, biased statements.

And no, some random blog doesn't count as a citation: There are zero legitimate, agreed to sources that will back up your definition. Instead it's people painting broad strokes to bias the world towards their own beliefs.

Just as unreasonably I could say that Go has a Clarified Type System, versus the Conundrum Type System found in Haskell.

[DCKing]

Are you aware that the notions 'weak' and 'strong' are actual terms used to describe type systems [1] ? Did you bother to look that up before going overboard and immediately accuse me of bias? I don't program in either Go or Haskell.

Now whether Go's type system actually has the property of 'weak'ness is very debatable. But whether it is true or false, it remains a factual statement.

[1]: http://en.wikipedia.org/wiki/Strong_and_weak_typing

[CmonDev]

It's a choice really: using a built-in exhaustive type system, or creating one manually with unit-tests. Unless you are happy with certain types of bugs.

[Kiro]

Would you consider JavaScript's type system strong?

[AlisdairO]

I assume they meant strong as in 'good' - presumably they're talking about generics.