enalicho

Can you quantify this? In what sense is the JS output from Elm lagging behind? What is it about the JS output from Reason that makes it better?

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.

No problem! Glad you found it useful :) It's not perfect by any means, but it's not meant to be.

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.

Right now, there exist multiple tools for dealing with JSON:

- json-to-elm http://json2elm.com - swagger-elm https://github.com/ahultgren/swagger-elm/ - elm-graphql https://github.com/jahewson/elm-graphql, https://github.com/jamesmacaulay/elm-graphql - elm-export https://hackage.haskell.org/package/elm-export

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.

There exist multiple tools to aid you with writing decoders:

- json-to-elm http://json2elm.com

- swagger-elm https://github.com/ahultgren/swagger-elm/

- elm-graphql https://github.com/jahewson/elm-graphql, https://github.com/jamesmacaulay/elm-graphql

- elm-export https://hackage.haskell.org/package/elm-export

Once you've got the hang of it, it's not that hard either. Just time consuming. That's where json2elm comes in :)

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.

Here are some JSON tools for Elm:

- json-to-elm http://json2elm.com

- swagger-elm https://github.com/ahultgren/swagger-elm/

- elm-graphql https://github.com/jahewson/elm-graphql, https://github.com/jamesmacaulay/elm-graphql

- elm-export https://hackage.haskell.org/package/elm-export

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!

We have a fully searchable and linkable archive for the Elm Slack, actually. :)

Trees go extremely well with FP. In fact, a lot of Elm's core data structures are implemented with trees. Dicts, Arrays, Sets. Here's an example of a zipper package in Elm: http://package.elm-lang.org/packages/wernerdegroot/listzippe...

Not quite. Things are happening, but perhaps not in the way you'd expect. See https://github.com/elm-lang/projects/blob/master/roadmap.md#... for roadmap notes, and some more notes on how issues are handled in Elm: https://github.com/process-bot/contribution-checklist/blob/m...

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.

When I come to an Elm project, I am able to read the code instantly. In fact, the majority (91%) of the Elm community who use elm-format enjoy it because of this. See here: https://www.brianthicks.com/post/2017/07/27/state-of-elm-201...

What you say might be true for you, but for people who are actually writing and using Elm, it does not apply.

I posted this lower down, but I'm posting it here again since it also applies to your comment:

Luckily there's a whole range of tools dedicated to making your life there a bit easier:

- json-to-elm http://json2elm.com

- swagger-elm https://github.com/ahultgren/swagger-elm/

- elm-graphql https://github.com/jahewson/elm-graphql, https://github.com/jamesmacaulay/elm-graphql

- elm-export https://hackage.haskell.org/package/elm-export

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.

Luckily there's a whole range of tools dedicated to making your life there a bit easier:

- json-to-elm http://json2elm.com

- swagger-elm https://github.com/ahultgren/swagger-elm/

- elm-graphql https://github.com/jahewson/elm-graphql, https://github.com/jamesmacaulay/elm-graphql

- elm-export https://hackage.haskell.org/package/elm-export

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.

Like the post says, come talk on Slack. That is where the majority of discussions happen.

The free version is _free_. The only thing you would have to pay for is the "studio", aka the dev tools.

There is very little JS in Fuse -- only some business logic. It's entirely possible to only have your business logic written in Uno, which compiles down to native code on each platform. All UI code is written in UX, which already does this.

It fills the same space as Electron, but does not function like Electron. The majority of code is written with UX, which is then compiled to Native components. It is also possible to have trivial FFI to native code with objc and Java. JavaScript is only used for _some_ business logic.

There is a bunch of people on the community slack who are using Fuse to make things. Generally, any question you may have will be answered in there. The dev team sit in there too, so it's first hand help

Fuse Tools | Software Engineer, Senior Javascript Engineer, Community Engineer, CFO & Senior Operations Executive, Cloud Software Engineers, Ops Engineer, UX Designer | Oslo, Norway or Palo Alto, America | https://medium.com/@fusetools/we-are-growing-and-hiring-a745...

Fuse is a new platform which makes app development easier, more efficient and more fun for both developers and designers. We’re committed to solving actual cross platform app design and development problems with tools that simplifies working with layout, interaction and motion.

In order to do this, we've implemented our own OpenGL engine that targets multiple platforms. We've also developed a superset of C# called [Uno](https://www.fusetools.com/docs/uno/uno-lang), with built in support for foreign code written in Objective-C, C++, and Java in order to help target multiple platforms from a single codebase.

We're currently hiring people for several roles, as we have just secured $12 millon in funding from NorthZone and Alliance Venture. We currently have around 25 developers on our team and, as we grow, we're also looking for people who can help us manage that growth. If you have expertise in different approaches, we would love to hear them.

We want people who like to think about API + library design, since the tools we make here are used by developers all over the world. Almost everyone on our team has a developer background, and we follow a strong practice of eating our own dog food. If you work on Fuse, you'll be using Fuse. Our community gets close support from us, the developers, so you must be good at communicating through Slack and at workshops. We're looking for people who like to help other people.

For more information please reach out to us on Slack [here](https://fusecommunity.slack.com). In order to apply, just go straight to [here](https://docs.google.com/a/outracks.com/forms/d/e/1FAIpQLSfOH...

Remote EU too for non-junior candidates!

Take a look at http://sourceforge.net/projects/snopy/. The project hasn't been updated for 3 years, and the files haven't been updated since 2002. I'm not sure that the dev is particularly active any more.

Permutations and combinations already exist within the itertools module.