Regarding the language and "configurations" specifically, you might like what we do with Nickel: https://github.com/tweag/nickel. Research project showing a potential future for Nix.
We are a research and development laboratory at the heart of Europe, applying functional programming techniques to tame the complexity of distributed systems and scale predictably. Most of our existing folks have a PL research and/or formal methods background and enjoy demonstrating the correctness of their solutions with gusto: randomized test case generation, model checking in SPIN/Promela or interactive theorem proving using Coq. We're very active in the Haskell community - contributing new language extenions (linear types, static pointers) to GHC, publishing and maintaining HaskellR, inline-java, sparkle, rules_haskell and many others. We hit the HN front page just yesterday with our Haskell support in Bazel.
Tweag.io are organized as a distributed team of experts around three main areas of focus: distributed systems engineering, functional programming based devops (Nix, Haskell etc) and mathematical modelling / machine learning. We are looking for formal engineers and PL designers to join our distributed systems team, to help us apply interactive theorem proving techniques to industrial scale projects and work on tools to make this cost effective for the masses.
If you'd love the opportunity and the space to solve the hard problems of science's large dataset infrastructure, by systematically decomposing them into simple, orthogonal solutions that compose and commute like in algebra, shoot us an email at [email protected].
Tweag I/O is looking for distributed systems engineers to be part of one of several projects focused on developing the next wave of storage solutions in Haskell and in C, targeted at the Exascale.
We are a research and development laboratory at the heart of Europe, applying functional programming techniques to tame the complexity of distributed systems and scale predictably.
For this position we're looking to have you join a local team near our headquarters here in Paris. We're pretty happy to look at helping you relocate if you're up to spending some time in this beautiful city. Fluency in French not required.
Many of our existing folks come from diverse backgrounds, be it a PL research and/or formal methods background, high-speed storage or machine learning. We are the active maintainers of the Cloud Haskell project and authors of the HaskellR and Sparkle projects, among other open source contributions. Our engineers spend a fair amount of time building the tools they need to make their life here a happy one. We love Nix and Stack so much to build and deploy our software that we made it easy to use both together (see our blog for more on all of these: http://www.tweag.io/)
If you like the idea of working on the software plumbing and infrastructure for tomorrow's Science, by systematically decomposing them into simple, orthogonal solutions that compose and commute like in algebra, give us a shout at [email protected]!
Yup, pretty close. Just to be clear though we don't generate any JVM bytecode for any of the Haskell code - we compile that to native code using GHC as per usual but then we dynamically load the resulting shared objects into the JVM.
The static pointer thing is what allows us to share (practically) arbitrary Haskell closures with Scala/Java. And more than that - to get Spark's Scala code to ship these Haskell closures between machines across a cluster.
Incremental recompilation is a big one, but beyond that, out-of-the-box handling of multi-package projects without the hassle of custom scripting or setting up .nix files just right. If all your projects are single package, `cabal repl` should work pretty well. Where stack really shines, and where it's interesting to simply reuse that, is for multi-package repos, which tend to be very common in private company Haskell developments.
You should give Haskell another shot. Since last you tried, this happened: https://github.com/commercialhaskell/stack. In fact using stack is the recommended installation method for HaskellR, rather than using the cabal-install command.
Yes - the R GC manages R objects allocated by the R interpreter, and conversely the Haskell GC manages Haskell objects allocated by the Haskell runtime.
Tweag I/O is looking for distributed systems engineers and a devops engineer to join a brand new team starting on a new, fully funded 3 year project in Haskell and in C to develop the next wave of storage solutions, targeted at the Exascale.
We are a research and development laboratory at the heart of Europe, applying functional programming techniques to tame the complexity of distributed systems and scale predictably. Most of our existing folks have a PL research and/or formal methods background and enjoy demonstrating the correctness of their solutions with gusto: randomized test case generation, model checking in SPIN/Promela or interactive theorem proving using Coq. We are active maintainers of the Cloud Haskell project and authors of the HaskellR project, among other open source contributions.
We are a distributed company with a presence across Europe (and a smidgeon in South America), but for this position we're looking to have you join a local team near our headquarters here in Paris. We're pretty happy to look at helping you relocate if you're up to spending some time in this beautiful city. Fluency in French not required.
If you'd love the opportunity and the space to solve the hard problems of science's large dataset infrastructure, by systematically decomposing them into simple, orthogonal solutions that compose and commute like in algebra, shoot us an email at [email protected].
> 3. strictness: arguments abound about whether laziness or strictness is better; for me, it comes down to the fact that with some pain, you can embed laziness in a strict language with effects, but you cannot embed full-on ML-style strictness into a language like Haskell; moreover, strictness-by-default permits safe uses of benign effects.
I've seen this claimed before, but I'm not sure I can subscribe to any sense in which this statement is true. It's been known since at least John Reynolds that you can make programs evaluation order oblivious by means of a CPS transformation: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.110..... Just as thunkification is a program transformation to simulate call-by-name, the call-by-value CPS program transformation is a way to simulate call-by-value.
Moreover, Haskell has strictness annotations, so strict programming is possible if you pepper all the arguments of all your functions with strictness annotations and you use only strict datatypes. In fact in the future a language pragma will do this for you: https://ghc.haskell.org/trac/ghc/wiki/StrictPragma. That's less invasive than a CPS transformation.
Regarding the language and "configurations" specifically, you might like what we do with Nickel: https://github.com/tweag/nickel. Research project showing a potential future for Nix.