If you get stuck on anything, come tell us about it on Slack. We can help you get unstuck! The majority of Elm users come from JS -- so while the syntax is different, it should not to be too hard to pick up. This is one of the reasons that Elm has avoided complex features from Haskell. It's really not very much like Haskell beyond syntax. Redux is very much like Elm, seeing as it is an implementation of the Elm Architecture.
It is no different from using a code generator for anything. Json2elm is designed to _help you_ write decoders, not replace decoders. Once you know how to write them, json2elm is mostly useful for generating boilerplate.
It's worth noting that JSON decoding is not _hard_ as such, but it's harder than other parts of the language. It is more time consuming. Tools like these can help reduce the amount of time you spend hand writing decoders.
You don't need to switch a whole language because of JSON decoding. There are many tools that exist to aid you write JSON decoders in Elm. The language is not just about the architecture -- you can implement the architecture in any language, as Redux has proven. What people like about Elm is the compiler and design philosophy that radiates through the entire community. Switching to Haskell won't give you that, as the Haskell community has different priorities.
I don't think that is a fair evaluation of that comment thread. I explained with links and resources _why_ elm-format is how it is, and _why_ it is considered a feature to not have flags. I also backed this up by showing how many of the users enjoy elm-format. This is not saying "don't dissent". This is saying "this argument is a strawman"
That's not particularly true. I am one of the most vocal dissenters when it comes to Elm. Dissent is welcome, as long as it's constructive. Saying "I don't like 4 spaces" is about as constructive as saying "I don't like Emacs". There are reasons as to why every piece of Elm is how it is. It is an opinionated language, that is very true. If you try to do things that don't fit well into Elm, you are going to have a hard time, simply because of those opinions that are built in. The community is eager to discourage people from falling into those common pitfalls. Everyone is welcome, however.
Come say hi on Slack! People there will help you judge if Elm is for you. If it's not, that's a shame. If it is, great!
I'm not really making assumptions about their use, but more rather commenting on the feeling of the community as a whole. I basis this on my deep involvement and the stats that we have to hand. I know that Elm format is not considered an issue by a large majority of Elm users. In fact, I can only thing of a couple of people who dislike it. So while they might personally use Elm and dislike it, it is not representative of the community -- it's important not to spread FUD, as comments on HN often tend to. The people who are most vocal about elm-format being negative are those who have not actually used it outside of short trials.
> You assume the OP is not actually using the language?
I'm making generalizations based on their statements -- the stats and anecdotal evidence tells us things about how the community at large.
> And yet you yourself said in another comment that you do not use the language.
Can you link that comment? I think you've gotten me confused with someone else -- I'm a very active member of the Elm community and write Elm as part of my day job and have done for over 2.5 years.
Elm is an opinionated language. The framework comes built-in. The tooling comes built-in. A clever language designer once said "there is only one way to do it". Elm is that, but at the language level. Elm-Format is opinionated, and for people who love Elm, they also love that.
> It might have been fine if elm-format had chosen better defaults.
Subjective. This is a time old discussion. Please read the linked issue.
> Universal consistency of code format just isn't that important, consistency within a team or company is what matters, and you don't lose that by allowing configuration.
And so on :) While it would be nice to solve Json Decoders in a better way, these solutions are very helpful for the time being. Long term, I personally believe the right route is hard to decide on. We could go with json-decoders being part of the language and compiler itself. We could generate decoders from type aliases. Or some template solution like template Haskell. Or tagged unions like Go. The issue is that decoders are not a blocker to people who write a lot of Elm. They make me sad, but they're not a blocker. That means that the solution is not such a high priority.
Please see the discussion at https://github.com/avh4/elm-format/issues/210. A fixed indent size is a feature, not a bug. Making a single tool that everyone uses is so nice. No need to mess around with .eslint files or the like.