Check out Miso [1] a frontend framework built in Haskell.
Our Use of Haskell and Elm
41–50 of 68 posts
Re: Our Use of Haskell and Elm
#42> "Haskell has excellent libraries for integrating with databases and web services, and for building API services."
I tried using Haskell for my side project(group chat type). Its libraries are nowhere near matured ones like Phoenix.
Re: Our Use of Haskell and Elm
#43Earlier quoted context omitted.
Why does it matter when the next release is coming, as long as the project is actively maintained?
That's a valid point. In this case, two reasons: 1 - active development is relevant. Is it being updated once a year, once a month. Is it going to take 1 year, 2 or 3 years. 2 - Above is not a deal breaker along. But, the new release is going to break stuff. you need to have ability to plan around things, especially as the new release will have paradigm shift (from what I'm gathering). You don't want to write lines a…
I bought that book 2 years ago, I've since stopped using Elm. It's pretty bad that it still hasn't been released yet.
Re: Our Use of Haskell and Elm
#44Learning ELM really helped me learn Haskell which is something I'm continuing to do, but Elm helped a lot. So I can see why a Haskell shop would want to use Elm for their frontend work. This makes total sense. That said, my initial enthusiasm for using Elm, aside from a gateway-drug to Haskell, has waned. I just do not have enough confidence in adopting Elm for our internal project nor to recommend it to other compan…
Why is the pace of releases an important metric for using a programming language? Focus on code quality, and maintenance simplicity. If anything, being able to use the same version for x years and having it be consistently better than any JS library/framework I used, means that the work done is of high quality. Maybe you should watch Evan's talks from various Elm conferences ( search on youtube, for example https://w…
my startup uses elm in production.
There are plenty bugs with the current featureset in the elm compiler. The next version is going to break many things. This puts users of the platform in an awkward position where they have to put up with bugs for an indefinite amount of time, and when a release does come it is going to break a lot of code.
this isn't something I'd expect in a "production ready" language.
frequent patch releases would be ideal. Though the version scheme of elm does not respect semantic versions. Which introduces another problem - unless you're "in the know" about elm, its difficult to even tell that the new release is going to break your code.
Re: Our Use of Haskell and Elm
#45Check out Miso [1] a frontend framework built in Haskell. [1] - https://haskell-miso.org/
I look at the opening stanza of the first example:
https://github.com/dmjio/miso/blob/master/examples/todo-mvc/...
"We're not in Kansas anymore"
Re: Our Use of Haskell and Elm
#46Check out Miso [1] a frontend framework built in Haskell. [1] - https://haskell-miso.org/
I look at the opening stanza of the first example: https://github.com/dmjio/miso/blob/master/examples/todo-mvc/... "We're not in Kansas anymore"
RecordWildCards and DeriveGeneric are clearly used but fairly basic. OverloadedStrings seems to be used for MisoString.
The other extensions don't seem to be used so it probably isn't as bad as it looks.
Re: Our Use of Haskell and Elm
#47I’m confused by the discussion of bringing new programmers on a team up to speed with these lesser-used languages; this blog is quite explicitly from a one-man dev shop.
We do the same in several teams of 5+ people, in a company having 3k employees.
I don't understand what lets you come to your conclusion.
Re: Our Use of Haskell and Elm
#48Learning ELM really helped me learn Haskell which is something I'm continuing to do, but Elm helped a lot. So I can see why a Haskell shop would want to use Elm for their frontend work. This makes total sense. That said, my initial enthusiasm for using Elm, aside from a gateway-drug to Haskell, has waned. I just do not have enough confidence in adopting Elm for our internal project nor to recommend it to other compan…
What I've heard from Evan and others, is that Elm's timetable is modelled on Python's, which would mean (my estimations here) that they expect almost a decade of obscurity to give them room to tweak and generalise the language, before really expecting any kind of popularity (which might lock them into certain approaches).
Note that doesn't necessarily mean a long period of instability -- I think one of the reasons why they're taking it so slow at the moment is to see how to match tools like "elm-update" to seamless allow language upgrades. But it does mean that they're still in the phase of, for instance, removing language features rather than monotonically adding them, and trying to avoid dependencies on Javascript and the current Javascript ecosystem.
I also think that the burst of excitement around TEA and using Elm as a front-end web application tool was seen as an indicator that they were heading in the right direction, rather than an absolute flag that they should try to achieve dominance in that sector, or concentrate on it exclusively.
Re: Our Use of Haskell and Elm
#49Earlier quoted context omitted.
If there are no important outstanding bugs, are there any sorely missing features? Does anything rot in the codebase as the JS in browsers (the target compilation platform) is constantly updated?
There are both long outstanding bugs and sorely missing features in the currently released version.
You keep claiming that without providing any links.
Care to post links to bugs/features you miss?
Re: Our Use of Haskell and Elm
#50> "Haskell has excellent libraries for integrating with databases and web services, and for building API services." I tried using Haskell for my side project(group chat type). Its libraries are nowhere near matured ones like Phoenix.
What libraries did you use, and which problems did you encounter ?