Which option describes how often you use Dhall:
Would anything encourage you to use Dhall more often?
What do you use Dhall for?
|Why do you use Dhall?|
What should Dhall development focus on?
|1/1/2018 20:15:46||Briefly tried it out|
Mainly, a formal spec (also an ATS parsing implementation)
Getting Dhall to work with other languages
|1/1/2018 20:34:24||Use it at work|
Some way to find functions would be immensely helpful. The way to currently find functions is by word of mouth.
Backends for more languages would be great.
HTML templating, providing better manifest files (elm-package.json)
Dhall as a template language allows us to express all of the inputs to a template in one place. We don't have to hunt-and-peck to find out what a template is parameterized by. And if we want to understand what some variable is in the template, we can just look at the top of the file where its type is declared.
We want exact dependencies for our elm code. There is no specific syntax for exact versions in elm-package.json. There is a hack around that limitation which requires enforcement by convention (or CI scripts or some such). We use Dhall to generate exact versions by construction. The JSON that's generated uses the hack around the limitation, but we don't have to think about that accidental complexity.
Providing backends to other languages.
Using Dhall from Haskell is a cinch. The Haskell package makes it so you hardly notice that you're calling out to an entirely different language. It works as well as something like aeson.
Having that sort of ease of use in different languages would be a tremendous help for people wanting to use Dhall from within a different language.
|1/1/2018 20:38:01||Briefly tried it out|
I would use Dhall more often if it had better type synonym support.
Ad hoc command-line tools
Ergonomics and tools for refactoring
|1/1/2018 22:54:36||Briefly tried it out|
Verbosity for writing values in sum types was a no-go for our use case
Usability and some more ecosystem development
We tried it as an option at work for defining some APIs but describing values in sum types was way too verbose (though I think I understand why it might be needed). We really like the promise of a strongly typed config language but it was pretty much unusable for us without building other tooling to potentially improve ergonomics.
|1/1/2018 23:06:45||Use it at work|
Missing a linter usable in editors for in-buffer error highlighting.
Sometimes have to work around record or Turing completeness limitations to generate desired json or yaml: often need record keys that are referenced from elsewhere as strings.
Would like to be able to compute the sha1 or similar of a file or expression.
Generating docker swarm and other configs from common templates with specific variables inserted safely.
JSON and yaml suck, want to know about errors at compile time.
You rock. Thanks for all your work for the community.
Use it for my personal projects
Better syntax for optional values. It is abysymmal now. But perhaps I'm using dhall wrong. My colleague suggests merging into default values.
Schema validation. Kubernetes is known for blowing up in your face at runtime by doing evaluation and parsing at the same time
Usability and elegance of the language. Now the syntax is sometimes a big verbose
|1/1/2018 23:15:08||Never used it|
Just haven't gotten around to it yet but will probably use it for something at work instead of JSON
|More of the same :)|
|1/1/2018 23:40:50||Briefly tried it out|
Better error messages; more concise sum types.
Strong typing & schema
|1/1/2018 23:45:43||Never used it||Dropping the lets|
|1/1/2018 23:54:54||Briefly tried it out|
simpler syntax; ability to describe the whole config in one file
|1/2/2018 0:45:26||Never used it|
I worry that contributors/friends who'd like to work on a project with me would be intimidated because they don't know the lambda calculus
|1/2/2018 3:50:03||Briefly tried it out|
More compilation outputs, e.g. Java
Common functions for compilation output, e.g. lambda lifting
|Dhall is awesome!|
|1/2/2018 5:29:44||Never used it|
It's cool, but I'm yet to be convinced it will make my life easier
Last time I checked, I found syntax a bit awkward. Hey, Wadler's law :) Anyway, great job! I'm not using Dhall, but I try to follow its development, because it's different from everything else I've seen.
|1/2/2018 8:01:03||Never used it|
Stable spec, editor support, type inference
|1/2/2018 8:25:34||Never used it||Julia bindings|
|1/2/2018 8:48:07||Never used it|
Rich functinality and concise syntax
Libraries for other programming languages. For example, a Rust implementation would be nice as it is arguably more straight forward to integrate with other things.
|1/4/2018 11:56:08||Briefly tried it out|
The main thing is more time on my part (adoption as JSON-preprocessor and via Haskell high on my TODO), but now that you ask, a Python binding
JSON is universal but a bit dumb
The focus on the standard, as discussed in the 2017 review, is sound.
Motivational essays such as the 'Year in review' and others on Dhall on 'Haskell for all' are great. It was these that put Dhall on my radar and marked it as something special.
|1/6/2018 20:27:04||Use it at work|
Scala integration, full type inference, row polymorphism for records.
configuration - use haskell integration and spit out json/yaml on some projects (to kubernetes configs for instance)
I love pure fp and dealing with configs wastes a lot of my time and is often error prone
I am in favor of the standardization that seems to currently be a focus. I also personally would enjoy some more advanced type system features, though this seems to not be a goal if the project.
I love the project and am grateful for all the work that's been done to make it accessible and well documented. Keep up the good work!