[HN Gopher] Elm at Rakuten
___________________________________________________________________
Elm at Rakuten
Author : dragonsh
Score : 215 points
Date : 2021-08-18 15:04 UTC (7 hours ago)
(HTM) web link (engineering.rakuten.today)
(TXT) w3m dump (engineering.rakuten.today)
| roebk wrote:
| The pros and cons listed hear mirror my own views of Elm.
| Although, we've only got a handful of small Elm apps in
| production it's a joy to work on them. I can rip into them with a
| fairly big refactor, fix the compiler errors and be confident
| that it's all going to work. I do which there were a larger
| selection of Elm packages to take advantage of, but integrating
| Web Components into Elm hasn't been bothersome.
| folex wrote:
| Elm is awesome, its compiler is awesome, but its ecosystem is
| kinda stalling, isn't it?
|
| I mean, a lot of libraries aren't updated to the last lang
| version, debugging JS-Elm interactions been a real challenge for
| years, yadda yadda. Overall I'd say Elm ecosystem doesn't receive
| enough attention to survive.
|
| I'm not complaining, I'm just sad about that and kinda surprised
| I didn't found a mention of that in the OP article.
| aeturnum wrote:
| I'm not an Elm veteran like a lot of the folks here, but I
| think an aspect of Elm is that a lot of the traditional ways
| that people expand ecosystems are discouraged by Elm's
| approach. For instance, components are hard to do in Elm and
| are discouraged in the documentation[1].
|
| So my own personal Elm projects have involved a lot of reading
| other code and often copying and modifying open source code,
| but it's hard to wholesale import components in the way that
| JavaScript and other languages do it. My experience with the
| language is that it is very easy to do what _I_ want in it, but
| it seems more difficult to share that as an open source
| contribution in Elm than in similar languages.
|
| [1] https://guide.elm-lang.org/webapps/structure.html
| mechelephant wrote:
| I would argue the opposite! The elm slack is very active with
| people who frequently contribute to the ecosystem. I don't
| think the "a lot of libraries aren't updated to the last lang
| version" is true, the vast majority are.
|
| Debugging elm-JS interactions is not really a problem when
| using the standard interop methods of ports and webcomponents.
| It's just not something that comes up often.
|
| Source: have been writing elm professionally for the last 2 and
| a half years.
| jaeming wrote:
| As I understand it, there was a rift in the community over the
| leadership's tone in messaging and communication. Some
| Developers also felt like they could not contribute in a
| meaningful way or have constructive discussion with
| maintainers.
|
| See posts like these for more details and comments:
|
| https://news.ycombinator.com/item?id=16510267
|
| https://news.ycombinator.com/item?id=22821447
|
| There are also several great alternatives now. F# with Fable
| and Elmish for example: https://zaid-ajaj.github.io/the-elmish-
| book/#/
|
| And Bucklescript TEA with Ocaml or Reason:
| https://github.com/OvermindDL1/bucklescript-tea
|
| Some others have also gone on to develop new languages taking
| inspiration from Elm: https://www.mint-lang.com/
| rtfeldman wrote:
| Honestly I think the main reason for this perception is that
| people in the Elm community have gotten increasingly tired of
| correcting inaccuracies people like to post about Elm on
| Hacker News.
|
| I spent a bunch of time doing that in the past, and
| eventually stopped because I felt like Sisyphus. The same
| people would crop up on the next thread repeating the same
| things anyway. Of course if the claims go unchallenged, it
| leads to the perception that they're accurate...but that
| doesn't make engaging with them any more enjoyable a way to
| spend one's free time.
|
| If you want to check the health of the Elm community, visit
| Elm Slack and ask in the #beginners channel how people feel
| about it. It takes about the same amount of time as posting a
| HN comment, but it gives a very different perspective than
| the one you'd get if your main source of Elm information was
| Hacker News comments! :)
|
| http://elmlang.herokuapp.com/
| superdisk wrote:
| Speaking as someone who liked Elm for a while, then
| abandoned it, I will say that the biggest problem with the
| language is absolutely its leadership. Development moves at
| an absolutely glacial pace and basically takes place with
| no transparency at all. I would argue that it's more like a
| "source available" project than an "open source" one since
| the core dev team is so exclusionary. Most planning takes
| place inside Evan's head, leaving others to just speculate
| as to what's going to happen to the language.
|
| On top of this, the community is run like a dictatorship.
| Dissent is silenced and banned, and faux positivity is
| spread far and wide. I got sick of it and was banned from
| the Elm subreddit after I expressed my frustration. That's
| pretty much when I gave up on the language, years ago, on
| version 0.18 (fwiw, they're on version 0.19 now, that's how
| slow updates are)
| [deleted]
| rtfeldman wrote:
| This is an example of the type of post I was referring to
| being tired of correcting.
|
| I don't use Reddit anymore, but if memory serves there
| have been about 5 people total banned from the
| aforementioned Elm subreddit, which is fewer than 1 ban
| per year it's existed.
|
| I invite anyone to evalute the accuracy of "Dissent is
| silenced and banned" with that data point in mind, and to
| evaluate the accuracy of the other above claims
| accordingly.
| zoul wrote:
| FWIW, I have the same experience as the parent poster. I
| used to love Elm, evangelized the architecture, wanted to
| write Elm professionally. I was constantly bumping into
| things that were not finished or working, but didn't
| really mind. But I also often encountered cases where the
| leadership team was saying "we don't want this discussion
| here, thank you very much", even if the discussion was
| perfectly legitimate, friendly, technical and related to
| some sorely needed feature or bugfix. I constantly felt
| unwelcome, like I was trespassing on someone's lawn. I
| didn't want to base my work on that. Eventually I just
| shrugged and left.
| rtfeldman wrote:
| Totally fair! I'm sorry to hear you had that experience,
| although I hope maybe you'll someday consider giving it
| another chance in the future. :)
|
| My personal experience has been different, but I upvoted
| this because I really appreciated that you shared your
| own experience without overgeneralizing it.
| cultofmetatron wrote:
| Interesting food for thought. I bought your book awhile
| back and was 2 chapters in before reading about the
| aforementioned "Dissent is silenced and banned" issues
| which led me to abandon continuing at the time. Maybe
| I'll jump back into it.
|
| I've not heard of such misinformation being spread about
| other languages. Id love to hear your side on why Elm
| itself seems to attract such ire if its inaccurate.
| rtfeldman wrote:
| It's a great question!
|
| I think there's more than one factor, but the biggest one
| comes down to setting expectations, especially in the
| early days.
|
| Elm does a lot of things differently than other
| languages, and while I think that overall those
| differences have been instrumental to its success,
| especially early on it sometimes wasn't clearly enough
| communicated when "this is temporarily different because
| it's a WIP; you can expect it to be more like what you're
| used to in the future" versus "this is different by
| design, so expect it to stay different or even to become
| more different."
|
| Examples of this include typeclasses (a lot of people
| coming to Elm from a Haskell background assumed Elm would
| add them as a matter of course), JS interop (by design,
| it's not a traditional FFI, although there was an
| unintended backdoor that kind of worked like one; when
| that backdoor was finally removed, after much
| communication that in retrospect should have happened at
| the outset, some of those who had been relying on it were
| understandably upset), how the project is run (more like
| Clojure than like JavaScript), and what the release
| schedule looks like (batching large projects rather than
| more frequent smaller releases).
|
| I think things are a lot clearer today, but for some it's
| unfortunately too late to make a difference.
| gaereth wrote:
| One thing is that it wasn't communicated that well, but
| other (and that's what made me feel really uncomfortable)
| is that it felt like ,,This feature is not allowed
| anymore - except for some dudes, they're cool enough and
| can use it" (e.g. native modules, operators). Either keep
| or drop feature
| G4BB3R wrote:
| Kernel code and custom operators are only allowed under
| elm/ and elm-explorations/, so only 7 core packages can
| use them. The core developers cannot use those features
| in projects like everyone else.
| hashbig wrote:
| And who can contribute to `elm` and `elm-explorations`?
| The 7 cool dudes.
|
| The Elm contributor circle is a clique that you literally
| have to be a strong contact with one of the contributors
| to get into it. It goes against everything open source
| stands for.
| jaeming wrote:
| That's a good point and maybe I shouldn't have re-posted
| these stories in my comment as I have not personally
| witnessed this behavior. I just know that when I started
| learning Elm initially (Nice Frontend master courses btw) I
| ran into this sentiment a good bit on reddit and hackernews
| so thought there was probably something to it if it was
| being echoed by so many.
|
| I'll add a reply to my comment to make it clear this is
| hearsay and doesn't necessarily reflect the truth.
| rtfeldman wrote:
| Thank you, that's very considerate of you!
| brainbag wrote:
| Also Mint at https://mint-lang.com, which is heavily inspired
| by Elm (and better, IMO). The open source aspect is also the
| opposite of Elm - the community is very friendly, the
| developers are responsive and positive, and PRs are
| encouraged.
| jaeming wrote:
| After considering the way I phrased this comment above, I
| want to clarify that I never personally observed or witnessed
| this kind of behavior myself. My own dealings in the Elm
| community have been almost entirely positive. I had heard a
| lot of these criticisms from comments on hacker news or
| reddit and realize now they mostly resemble hearsay or people
| like myself repeating what they heard from others resulting
| in a sort of echo chamber. I apologize for adding to that
| echo chamber.
| ferdowsi wrote:
| After the relevations about Elm's dysfunctional leadership
| culture[1] I have seen vocal discouragement about investing in
| Elm, and reasonably so. This is a culture where Elm's leaders
| actively attempt to shut down criticism as "emotional
| violence"[2], which is just incredibly immature hyperbole. I
| couldn't imagine investing the future of my job and workplace on
| an operation like this.
|
| [1]https://news.ycombinator.com/item?id=22821447 [2]
| https://www.reddit.com/r/elm/comments/7zk0dy/is_evan_killing...
| StefanWestfal wrote:
| I had a similar line of thought in the beginning too. If you
| google Elm these issues pop up. However after some time posts
| about it lead back a very limited set of occasions and block
| posts. Which are either criticizing the leadership style or a
| few events. I view the leadership as a trade off which ensures
| a high level and guarantees for the core at the cost of a high
| barrier. For the fee events, I think we are all humans and make
| mistakes and usually it is a miss communication between two
| parts more then a real issue.
| dmix wrote:
| > We had global variables everywhere, and debugging was a
| nightmare.
|
| ES6 module imports really helped solve this problem and is a
| giant step forward in the JS ecosystem. Despite being relatively
| straight forward they were (and are) a big deal.
|
| Any JS project before that was a giant dance of complex window
| namespacing, closure wrappers, and hoping the 3rd party library
| you're using doesn't expect some weird custom thing to 'import'
| it.
|
| The next step obviously is fixing bundling and replacing Webpack
| and Babel (the closest thing to a widespread standard today in
| JS) with something less magicy and more native. And these are a
| big reason newbies/non JS devs freak out when they see a thousand
| packages in starter kits.
|
| These two things (importing and bundling/preprocessing) were a
| big reason why there always seemed to be a never ending output of
| new build tools. Just having those two to be predictable is a
| godsend in any JS developers but IRL even the best internal
| practices was never consistent across libraries, teams, and
| projects.
|
| I've always wondered how much frameworks like Elm and similar are
| motivated simply but attempting to establish best practices and
| standards in JS projects vs the abstraction/language innovations
| they provide (like pure FP and reactivity stuff). It's at least
| 50% of the value proposition.
|
| The big question is whether it will be for long enough to be
| worth the investment.
| hashkb wrote:
| esbuild and TS are a good step you can take incrementally as
| you move away from webpack/babel. Still the lesser of some
| evils, but less evil is better.
| tempest_ wrote:
| Elm looks interesting but when it pops up around here and other
| places it is usually about how the main dev does not work and
| play well with others.
|
| It is a bit off putting.
|
| It is nice to see a different perspective.
| z5h wrote:
| I think when something is built by several people, catering to
| outside interests, you end up with more churn, bloat,
| inconsistency, instability, etc. But your specific need has a
| better chance if being addressed. When something (like Elm) is
| built in a silo, you end up with less churn, bloat,
| instability, inconsistency. We forget how we got these nice
| things, and when we want something NOW we get cranky about the
| development model. So, as a developer with 20+ years of
| experience I can say that EVERYTHING (tools, languages,
| paradigms) is shitty in some ways, and I vastly prefer the ways
| that Elm and ecosystem are shitty.
| [deleted]
| agbell wrote:
| For those want to learn Elm, or to learn strongly typed
| functional programming in very well thought out order
| @rtfeldman's book "Elm In Action" is super good.
|
| His experience working at a teaching company made his book very
| well structured for new comers.
| mouzogu wrote:
| Wouldn't it be difficult to find other developers that are
| experienced using Elm? I don't know much about it tbh.
|
| Probably, one of my biggest career mistakes was opting for a
| little known PHP cms instead of WP as I thought it would be
| easier for the stakeholders to work with the limited options.
|
| Since then, I've always avoided going away from the mainstream
| toolset.
| MichaelGlass wrote:
| FWIW our experience has been: - finding devs with experience is
| hard - finding great devs who want to use interesting tooling
| is easy
|
| In the end, we hire interesting, curious devs, and ask them to
| use tooling (elm) that has a pretty shallow learning curve.
|
| I think bootstrapping a project in Elm without any experience
| on the team could be tough, but once you have some expertise,
| the seeds you plant in yield abundant fruit. At NoRedInk it's
| been a great success -- especially with regards to "finding
| other developers".
| g_delgado14 wrote:
| > Wouldn't it be difficult to find other developers that are
| experienced using Elm?
|
| Yes, however:
|
| - Elm has a very small surface area (you can read through the
| guide [0] in a weekend)
|
| - There are many folks who love functional programming && are
| willing to learn Elm
|
| So, given those two facts, the lack of Elm developers compared
| to other "markets" is not a big issue.
|
| For me, personally, the only risk with Elm is its incredibly
| opaque development. It's led by Elm's BDFL and a few other
| folks and it's almost as though they go out of their way to
| make Elm hard to adopt for outsiders.
|
| For example, all you have to do is change elm's version to
| 1.0.0 to signal to outsiders that, yes .. Elm is and has been
| production ready for quite a while now (years?). Instead
| "insiders" will reason and rant about how 0.19.1 is fine.
|
| ----
|
| [0] - https://guide.elm-lang.org/
| blowski wrote:
| I appreciate that I am biased because of my background, but
| I've met precisely one person who's used Elm while just about
| every dev I know has worked with WordPress at some point. For
| most enterprises I work with, 10 years in production is about
| close as they're willing to get to the bleeding edge. They
| don't really care about code quality or features. They want
| to be safe, secure and future-proof for as low a price as
| possible.
|
| That said, I know very little about Elm and would love to
| understand more about what it offers that's so exciting. I
| skim-read the article, will read in more detail later.
| matsemann wrote:
| My bias is the opposite, probably because I've worked at an
| Elm shop. But I know zero people with wordpress experience,
| in my circles I'm the only one I know of with professional
| php experience at all. But I need more than my hands to
| count all elm programmers I know.
| hitekker wrote:
| The "Elm at Microsoft" link is broken and when I google for it, I
| can only find an archived package on Github.
| pianoben wrote:
| This link works for me:
| https://elmtown.simplecast.com/episodes/it-just-goes-on-and-...
| hitekker wrote:
| Hmmm, I think it's my VPN. My bad.
| cfors wrote:
| Its right here from the "Other Testimonies" section:
|
| https://elmtown.simplecast.com/episodes/it-just-goes-on-and-...
|
| Obviously Microsoft is a huge company so they use all of the
| languages, but I find it surprising given the amount of
| investment they've made into Typescript.
| Zababa wrote:
| It's not surprising for a large company. For example, Google
| uses C++, Rust and Go on Fuchsia. They have Angular with
| Typescript and Angular with Dart. Big companies are what they
| are, an association of a lot of people that are all
| different.
| decafbad wrote:
| mkose@casper:~/Desktop$ ./elm repl ---- Elm 0.19.1
| ----------------------------------------- > Basics.modBy 0
| 3 Error: Cannot perform mod 0. Division by zero error.
| [deleted]
| earth_walker wrote:
| This is correct behaviour, depending on the definition of mod.
| See, for example:
|
| https://math.stackexchange.com/questions/516251/why-is-n-mod...
| decafbad wrote:
| The promise was _no runtime errors_.
| aaronchall wrote:
| I'd like to recommend Elm at work but I can't because it's still
| below a major version of 1, which implies there may be a good
| deal of rework in the short term.
|
| I did get an Elm app upgraded from 0.18 to 0.19 without too much
| extra work, but I'm concerned a major version release may bring
| much more changes.
| moistoreos wrote:
| https://github.com/elm/compiler/blob/master/roadmap.md
| arcade79 wrote:
| I wonder if someone will create 'pine' - "pine is not elm".
|
| (For younglings: elm was an email client. pine was also an email
| client. The latter was often thought to be short for 'pine is not
| elm').
| fatnoah wrote:
| To be honest, I read the article and was expecting this to be
| about ditching Outlook or Gmail in favor of Elm.
| wing-_-nuts wrote:
| I have fond memories of using the pine email client. It was so
| fast. I know mutt is another one, supposedly, but by the time I
| was considering switching, I had exclusively moved to web mail.
| neals wrote:
| What is Rakuten? Why is it on all my Samsung TV's? How come it
| works out of the box?
| deergomoo wrote:
| > What is Rakuten?
|
| A Japanese tech conglomerate.
|
| > Why is it on all my Samsung TV's?
|
| Because Samsung have no shame and will gladly ruin their own
| products for a quick buck.
| PragmaticPulp wrote:
| Interesting breakdown of some pros and cons of using Elm in
| production. However, it appears the JavaScript codebase they used
| for comparison was quite bad and maybe not representative of a
| good or even typical JavaScript app:
|
| > Our JavaScript application had global variables everywhere, and
| debugging was a nightmare
|
| Point #3 in their list of cons is especially important for anyone
| considering Elm:
|
| > Because Elm is not a mainstream language, it is sometimes
| necessary to reinvent something that could otherwise have been
| acquired by adopting a different technology.
|
| This is the biggest downfall of Elm projects that I've seen in
| the real world. Teams end up spending half of their time or more
| solving problems that could have been accomplished quickly with
| some off the shelf React libraries with numerous tutorials
| online.
|
| This attracts a lot of developers who enjoy working on libraries
| and tooling, but it's not ideal if you're trying to run a lean
| team that ships products quickly.
|
| Elm is fun, but I wouldn't use it unless I could afford to hire a
| relatively huge team to absorb all of the additional complexity
| and detours that go into building an Elm app. There's a constant
| promise of Elm being faster and easier to write for various
| reasons, but in practice it always seems to get bogged down in
| endless gotchas and framework shortcomings that need to be
| addressed before we can get down to getting real work done.
| aranchelk wrote:
| > This is the biggest downfall of Elm projects that I've seen
| in the real world. Teams end up spending half of their time or
| more solving problems that could have been accomplished quickly
| with some off the shelf React libraries with numerous tutorials
| online.
|
| This is an important point; I think it applies to varying
| degrees to any less popular language or framework. It's a
| little worse with Elm because of the restrictions they've
| placed on JS interop. I'll add that unless you're very familiar
| with the framework/language you'll be using, it's pretty hard
| to estimate scope of work; you'll just encounter surprises
| during implementation along the lines of "wow I can't be
| believe they don't have a library for x." On the plus side,
| since the work of implementing these libraries is very generic
| with regard to any specific application, it's easy to delegate
| to other employees or contractors.
|
| I'm currently working on a large PureScript project. At various
| times I've had to implement my own base libraries and
| components, but in many cases I've just been able to wrap
| existing JavaScript code. Some of the key libraries I use,
| which were developed by other community members are wrapped
| JavaScript libraries. This has been a pretty powerful
| mitigation strategy.
|
| In the case of PureScript, I also have the benefit of reusing a
| substantial amount of front end code on the server. For me, on
| this particular project, the benefits of using a language with
| advanced features has far outweighed the above mentioned costs,
| but I think you've got to look at each situation differently
| and do that evaluation.
| Silhouette wrote:
| _I 'll add that unless you're very familiar with the
| framework/language you'll be using, it's pretty hard to
| estimate scope of work_
|
| I think you've just defined a pretty good benchmark for when
| it's sensible to consider a less popular choice. Are you
| familiar enough with it to be confident of coming out ahead
| by using it? Perhaps you have a backup plan like the interop
| you mentioned if some functionality is missing. Perhaps the
| tool is so much more productive in general that you are
| reasonably confident any extra development work to fill in
| the gaps will be outweighed by the overall benefits. But
| there should be _some_ clear reason you think the risk is
| justified.
| platz wrote:
| curious if you using halogen or react-basic? I've gone with
| halogen for a small project and it's been fine but sometimes
| i wonder if react-basic is a better choice.
| aranchelk wrote:
| This is an area where I ventured far from the ordinary and
| wrote my own application framework. I'll eventually open
| source it and write an article about the process. In short:
|
| I was completely sold on the Elm architecture, but I used
| Haskell too long to be comfortable working without
| typeclasses, so I went through a couple different elm-like
| frameworks written for PureScript. I settled on one only to
| later realize what (I think) people are talking about when
| they say "Elm doesn't compose", which is not well
| articulated in that statement. I take it to mean: you can
| never really deal with stateful components in isolation
| because they have to work off of a unified global data
| structure. I developed some new tech that makes different
| tradeoffs and it got me what I wanted.
|
| I knew developing my own framework was going to add a lot
| of extra work: * Writing the framework (not too bad,
| actually) * Writing the reusable components and combinators
| (exactly what you'd expect)
|
| By far he hardest part has been establishing patterns and
| best practices working with a new and different
| architecture, I struggled with that for a while.
|
| I'm a strong believer in the points made in Graham's
| Beating the Averages (actually what brought me to HN) and
| in my case I'm establishing a tech stack for my current and
| future projects, so I believe the framework was a
| worthwhile investment.
| mst wrote:
| I thought the idea was that you'd have layers of actions
| so you have a top level handler of some sort that would
| then dispatch a contained-within-the-primnary-action
| component-scoped action and then pull the new component
| data back into the global store.
|
| (apologies for the lumpy phrasing, insomnia is a pain)
| aranchelk wrote:
| That may be best practice, I'm not sure. Regardless, you
| can imagine as a result of that style of coding, any
| changes to the type of your components state will require
| at least some changes within the component, changes to
| one or more of those layers of action handlers, and a
| change to the initial/default instance of your
| applications model.
|
| I'm absolutely not an authority on Elm architecture, I
| just know that my experience doing stuff like forms with
| validation really sucked.
| lhorie wrote:
| > Teams end up spending half of their time or more solving
| problems that could have been accomplished quickly with some
| off the shelf React libraries with numerous tutorials online.
|
| I dunno, having seen both sides, there are pros and cons to
| each.
|
| Teams that reach for libs quickly often think in terms of
| libraries instead of solutions (one recent example was some
| folks who were asking for my advice on some over-engineered
| client-side PDF generation thing, and me suggesting
| `window.print()` as a solution, considering this was for an
| internal tool and you effectively want print stylesheets
| anyways), and often use them as crutches due to a self-
| fulfilling cycle of "I don't know how to do X, let's use a
| library so I never need to find out" (and then pulling in a
| huge lib to do the job of a literal one-liner regex -
| `uuid.validate()`, looking at you). In my experience, they also
| often end up buried by their own complexity due to gluing too
| many things together. But at the same time, it's hard to argue
| with the ease with which one can plop a modal dialog or a
| calendar or a collapsible table in a React app.
|
| I find that teams working with more exotic technologies tend to
| be more creative with solutions (e.g. "oh there's no zoomable
| map UI lib bindings, so let's ask ourselves, do we _really_
| need a map library for that contact us page or is a static jpg
| good enough? ") and a have a deeper appreciation for how hard
| things are to implement. But conversely, UX can suffer from too
| much "creativity". For example, if care is not taken w/
| accessibility concerns for some UI element. Or, as you said,
| things just take longer to ship because people need to reinvent
| wheels.
| mjaniczek wrote:
| > Elm is fun, but I wouldn't use it unless I could afford to
| hire a relatively huge team to absorb all of the additional
| complexity and detours that go into building an Elm app.
| There's a constant promise of Elm being faster and easier to
| write for various reasons, but in practice it always seems to
| get bogged down in endless gotchas and framework shortcomings
| that need to be addressed before we can get down to getting
| real work done.
|
| Is this your experience writing Elm apps in production? I am
| writing large Elm apps in production and I'm having very
| different experience to what you just described.
| whateveracct wrote:
| A seasoned small Elm team will probably scale to higher
| complexity heights than a small JS team in my experience. Same
| goes for Haskell and the like.
|
| The freaking out about "oh no I gotta write a small library
| myself" is absurdly overblown here. Most of the time I see it,
| it's people flipping out at the very sight of there not being
| something available off-the-shelf. The actual cost is much
| lower than the panic implies.
|
| In general, people see ANY time spent in an FP language to
| solve FP problems as "a waste of time" but they're blind to the
| wastes of time people treat as "real code" in mainstream
| languages.
|
| But yeah if you're a software efficiency bean counter, maybe
| you won't like FP. Fair point.
|
| My opinion is the long-term technical & cultural benefits and
| opportunities pay off. And as a developer, I am happy to not
| optimize my development velocity to the utmost if it means I
| don't have to waste my brainpower writing imperative code. My
| mind is in a much better state at the very least :)
| PragmaticPulp wrote:
| > But yeah if you're a software efficiency bean counter,
| maybe you won't like FP. Fair point.
|
| > My opinion is the long-term technical & cultural benefits
| and opportunities pay off.
|
| How, though? These two points contradict each other. Is using
| FP going to pay off with technical benefits? Or is it just
| going to reduce your software development efficiency?
|
| I enjoy writing FP code and using niche frameworks like Elm
| for hobby projects, but I specifically avoid them for
| production work _because_ I 'm familiar with them.
|
| I always hear claims that using Elm and niche languages is
| going to pay off in vague benefits somewhere down the road,
| but in practice the payoff never really arrives. I think a
| lot of developers pushing these niche frameworks tend to
| mentally dismiss the actual costs and overhead incurred by
| using something like Elm.
|
| It's tempting to categorize the struggles as "learning" and
| therefore try to pretend it doesn't count as lost time, but
| at the end of the day if your team has to spend extra cycles
| doing extra things just to accomplish basic tasks, it's a
| drag on productivity.
| whateveracct wrote:
| Everything you say is optimizing for the short-term. When
| it comes to total cost of development, I think FP wins out
| even if you have to fill ecosystem gaps.
|
| But if you can't afford for ANY time to not be spent
| directly on the business, don't do FP. Sounds like a pretty
| brutal way to work.
|
| FP has _throughput_ benefits, but may come with _latency_
| hiccups while your team climbs the learning curve (which
| may include writing libraries.)
|
| If you have frequent deadlines (or treat 2 week sprints as
| deadlines), then FP won't jive..and you probably have
| bigger pain points in your company than PL choice lol.
| PragmaticPulp wrote:
| > When it comes to total cost of development, I think FP
| wins out even if you have to fill ecosystem gaps.
|
| This is the core point I was disagreeing with:
|
| In my experience (yes, I have used Elm and I enjoy
| various functional languages), this payoff never comes.
| There's always something more that needs attention, needs
| another developer, needs to be refactored because we
| forgot a use case, and so on.
|
| And also in my experience, by the time you've invested
| the years of effort required to fill in gaps in the
| public package ecosystem, it's time to move on to the
| next niche language trend. I'd rather invest our time and
| energy in mainstream languages that have staying power,
| where we're not obligated to carry large parts of the
| open-source ecosystem by ourselves.
| whateveracct wrote:
| Years, plural?? Maybe Elm is just way less mature, but I
| was on a team that shipped Haskell software with millions
| of users in about a year of dev time..and this included
| huge investments in many missing libraries..all on top of
| using GHCJS which required investments to the toolchain
| itself (Elm is definitely more mature now than GHCJS was
| at the time.)
|
| But that was Haskell I guess. It's obviously not a "niche
| language trend" by now, so it was pretty clear it had
| staying power.
|
| Definitely has paid off for me personally. My side
| projects move a lot faster and more stably now that I cut
| my teeth in production Haskell. A real free 10xer to my
| skills personally. And I gained the skills by getting my
| employer to finance my learning lmao.
| KronisLV wrote:
| > And also in my experience, by the time you've invested
| the years of effort required to fill in gaps in the
| public package ecosystem, it's time to move on to the
| next niche language trend.
|
| This probably depends on the complexity of what you need
| to do, as well as how well you want to do it.
|
| I've seen people writing their own packages and pieces of
| systems in months, to typically pretty underwhelming
| results. However when writing code with tests, proper
| documentation, getting started guides etc., then what
| you're saying does sound way more plausible, especially
| if scope creep of any sorts is also present.
|
| Would you care to comment on what sorts of systems take
| years to properly develop, though? Because in my
| experience that could be applicable to very few software
| projects out there.
| vlunkr wrote:
| > I think FP wins out even if you have to fill ecosystem
| gaps.
|
| What proof of this is there though? People have made the
| same claims about lots of things: FP, OOP, statically
| typed languages, dynamically typed languages, LISP
| variants, etc. The fact is, any of these solutions can
| work, and you can also write terrible code with any of
| them.
| kingaillas wrote:
| >The freaking out about "oh no I gotta write a small library
| myself" is absurdly overblown here
|
| I don't think it is.
|
| At work, I'm adding some basic metrics/logging functionality
| to an internal library, to see how it's being used. The idea
| is to log a few parameters and the tech lead suggested using
| JSON format.
|
| No problem right? Well my work environment is quirky and
| let's just say it is hard to use outside libraries for
| various reasons. It can happen there is just a lengthy IT
| process to go through... eventually most reasonable requests
| will be filled (copied/mirrored internally, or binaries
| imported). But there is a delay.
|
| This is all besides the point other than to say: I either
| need to wait a few weeks, or write my own minimal JSON
| library.
|
| How hard can that be? I mean, it's just JSON. Well earlier
| today I was checking reddit and saw an announcement that
| "JSON for Modern C++ was released" (https://www.reddit.com/r/
| cpp/comments/p69plb/json_for_modern...). Hey cool, I can see
| what the library looks like and maybe rip off some of their
| code while I'm waiting for a "please mirror this internally"
| request to finish.
|
| This library is thousands of lines long... for JSON. I'm not
| disparaging the author or JSON, it looks like an awesome
| library with great diagnostics, I'm more trying to point out
| that even for the SIMPLE format of JSON, a serious library is
| 10K+ lines. That's a hell of a lot of extra work to put on a
| team when writing a JSON (or whatever) library probably isn't
| the actual work that needs to be done.
|
| Elm likely has a JSON library ready to use, but having your
| seasoned team reinventing the wheel for so many other
| libraries isn't a good use of dev time. I can't think of
| simpler libraries to write than JSON and even that is 10K
| lines long. Other than the insanity of nodejs and leftpad and
| libraries like that. If the attitude for every single library
| needed is "we can write that from scratch" the team is never
| going to get anywhere.
| whateveracct wrote:
| A json serialization (no parsing) library is not going to
| be 10k+ lines, and it's going to be extremely simple.
|
| You can define a JSON AST type very simply, and then
| converting that to wire bytes is also quite trivial. Also
| simple to test via golden testing (you could even use
| property testing + shell out to jq to validate the json)
|
| https://github.com/nikita-volkov/jsonifier This one is
| nowhere near 10k lines - and it is heavily optimized and
| polished!
| panzagl wrote:
| The answer is ditch JSON for something already supported
| (XML? CSV?) or homebrew a more minimal serialization format
| that you can implement in a couple of days.
| vlunkr wrote:
| > The freaking out about "oh no I gotta write a small library
| myself" is absurdly overblown here
|
| This isn't a good representation of the argument. People
| don't want to write libraries because it's more valuable for
| everyone to spend time writing features using existing
| libraries, provided there are good libraries available.
| People aren't "freaking out", they just have deadlines, and
| you know, other things to do with their lives besides write
| code that has already been written.
| mst wrote:
| I would imagine that it's a good representation of their
| experience of such things, but a poor representation of the
| experience of such things of the person they're replying
| to.
| whateveracct wrote:
| Nah it's a pretty good representation. And acting like time
| should 100% be spent writing features is shortsighted -
| sometimes it's worth it to pay fixed costs such as filling
| in a gap of the ecosystem of the language you chose for
| higher reasons than cranking out business code.
| KronisLV wrote:
| > The freaking out about "oh no I gotta write a small library
| myself" is absurdly overblown here.
|
| Maybe in the context of the parent comment this holds true,
| but in my experience this is like walking on a knife's edge.
|
| There's the very distinct possibility that you'll end up with
| homebrew frameworks and libraries that are overcomplicated,
| buggy, not commented and exceedingly hard to work with. I've
| seen that happen many times and it makes me consider not just
| whether people want to do that, not whether people have the
| time to do that, but even whether it's possible for them to
| do.
|
| In one project people wanted all of their front end
| components to be custom and as a consequence spent 3x-5x
| longer building everything, none of their components were
| Googleable for someone who's been onboarded and thus people
| forgot how they even work after 2 weeks of not editing them
| and had to rediscover that later. I tried adding a component
| sandbox/playbook to help them provide examples, but no one
| was interested in doing that when they were already behind
| the expectations of the business. Picking an off-the-shelf
| framework would have saved them all of these troubles. Maybe
| there were actual reasons behind the choice of approaching
| the project this way, apart from padding their resumes,
| however after inquiring about those, i didn't get a
| convincing response.
|
| In another case, i had to work on a custom web back end
| framework, which had been developed by another company, in a
| country the language of which i don't speak. Curiously
| enough, all of their code comments were in this language,
| there yet again was a lack of any sorts of documentation, the
| implementation was obtuse, slow and any simple changes to the
| forms took days to implement properly, even when it would
| take around 30 minutes in established technologies.
| Furthermore, the actual framework hadn't received any updates
| in years and therefore i fear to think what sorts of security
| issues it had. An off-the-shelf framework would have at least
| been updated and probably would have more decent
| documentation.
|
| In short: - never underestimate the ability
| of people who lack oversight to make things worse -
| frameworks and libraries that are used by thousands of people
| are probably at least decent - there's definitely also
| something to be said about how well tested they are and how
| known the bugs are - because of the above, popular
| technologies seem like a pretty safe bet, as does off-the-
| shelf code appear to be - of course, despite all of the
| above, it's perfectly okay to explore new tech stacks and
| write your own code, just don't half ass it
| dimitrios1 wrote:
| > but it's not ideal if you're trying to run a lean team that
| ships products quickly.
|
| Good. The longer I do this, the longer I realize that unless
| your in a race-to-the-bottom industry (something like vying for
| eye balls to increase ad spend), then this is categorically a
| bad thing. I would prefer the quality of engineering required
| in knowing how to do some of these things yourselves.
|
| Take your time. Understand what you are doing. Some of the
| world class technologies we all know and use daily use minimal
| dependencies.
|
| And with more malicious code entering more package
| repositories, it might be apt advice more than ever today.
| pjlegato wrote:
| Quality engineering must always be balanced against the
| reality of finite budgets. Sure, lots of amazing engineering
| can be achieved in theory, _given infinite funding_.
|
| That never happens in the real world. One always has limited
| time to produce a viable product. There is always some
| extrinsic constraint to how much time can be spent taking
| your time and understanding what you're doing.
|
| Moreover, if you are operating in any commercially viable
| product space, you're always competing against other firms
| for finite market share. If it takes x years to ponder and
| understand how to build and ship a masterful feat of
| engineering, while some other company ships a "sort-of-works"
| product with bugs and engineering flaws in <<< x years, the
| other company will usually win in the marketplace.
|
| Your company usually goes bankrupt, and all the engineers
| will complain at their next jobs about what a wonderfully
| designed engineering system they were building, and how awful
| it is that nobody appreciates such things these days.
| PragmaticPulp wrote:
| > Your company usually goes bankrupt, and all the engineers
| will complain at their next jobs about what a wonderfully
| designed engineering system they were building, and how
| awful it is that nobody appreciates such things these days.
|
| This is precisely why I try to interview tech leads about
| what they _shipped_ rather than what they _built_. There
| are a lot of otherwise very talented developers out there
| who will spend years playing around in your codebase,
| writing beautiful code, but not actually shipping anything
| useful. Replacing them with shipping-focused engineers,
| even if they 're not as technically competent, usually
| results in big productivity boosts.
|
| This isn't a popular opinion among developer communities,
| but it's a common theme in the management forums I'm part
| of. It's important to have fun and budget some time for
| things like open-source contributions and library building,
| but the top priority must always be on shipping product.
| Silhouette wrote:
| This is the popular wisdom but I question how universally
| applicable it is. We all know that having the best
| technology doesn't necessarily mean you win in a commercial
| market and we all know that being first mover can be an
| advantage, but those observations don't tell us what will
| be successful in the long term.
|
| How often does substandard technology and technical debt
| become a drag on a business not long after that first move,
| allowing someone else to overtake because the poorly built
| system couldn't scale to production levels or wasn't
| adaptable enough for changing requirements or failed so
| often that the early users drifted away? How often do we
| see developers advocating shortcuts and showing limited
| understanding of basic software development or computer
| science ideas, only to see the product they work on being
| rewritten within a year or two, or the whole team shut
| down?
|
| You can try to be fastest always. You can often succeed, at
| first, if you take enough shortcuts. But you can't sustain
| that pace without enough quality in your people and your
| code. Planning to throw each implementation away and
| rewrite with more resources every year or two is a very
| unicorn-like strategy. It reminds me of VCs whose strategy
| is to invest liberally, who are fully aware that most of
| those investments won't work out but they're hoping for one
| or two in each batch to become the next big hits.
|
| Real engineering isn't done in a vacuum and its goal isn't
| perfection. Real engineering takes issues like costs and
| timescales and staffing into account and aims to find a
| solution that is good enough on all counts. But it still
| has to be good enough. Producing junk but quickly and
| cheaply is an effective strategy until it's not and the
| success of any product using that strategy comes down to
| little more than the luck of the draw.
| pjlegato wrote:
| I totally agree. Engineering should be the best it can
| be, within the constraints of the resources available.
|
| My post was addressing the common case where an engineer
| seems to ignore the 'resource constraints' side of the
| equation altogether.
|
| Balancing these factors is more art than science. No two
| projects have the same set of resource constraints, nor
| the same set of engineering challenges. Luck is a big
| factor. The solution depends heavily on the exact details
| of each particular case.
| JamesSwift wrote:
| See also: engineers who think that engineering
| considerations trump all other business considerations.
| You need to know when it makes holistic sense to rewrite,
| or ship a hack. There are a lot more people at the
| decision-making table than just engineering.
| Silhouette wrote:
| That is certainly true but somehow I suspect under-
| engineering is a more frequent problem in our industry
| than over-engineering.
|
| IME retrospectives rarely sound like "We hired a team of
| strong developers, they did a solid job, but then the
| business failed as a result". The kind of developers who
| are strong enough to do a solid job are probably also
| experienced enough to recognise the other considerations
| in play and adapt if necessary.
| 0xFACEFEED wrote:
| > Quality engineering must always be balanced against the
| reality of finite budgets. Sure, lots of amazing
| engineering can be achieved in theory, _given infinite
| funding_.
|
| While this is obviously true, I don't think it depicts the
| actual decision making process that leads to messy
| codebases and crappy products. In my experience lack of
| experience and/or laziness play a big part.
|
| A competent tech lead that's passionate about quality AND
| is willing to be annoying for the greater good makes an
| enormous difference. I'm talking multiple orders of
| magnitude difference.
|
| It's the difference between spinning up a k8s cluster +
| service mesh vs tiny single server vps with basic failover.
| The former is thousands of hours of dev time across
| multiple disciplines while the latter a seasoned engineer
| can handle by themselves.
| mwcampbell wrote:
| > Good. The longer I do this, the longer I realize that
| unless your in a race-to-the-bottom industry (something like
| vying for eye balls to increase ad spend), then this is
| categorically a bad thing.
|
| It's not that simple. I realize this may be uncommon, but
| it's possible to work on a product that is truly worthwhile,
| that improves peoples' lives, and whose target users urgently
| need a solution to the problem you're solving. I recently
| developed a product that I believe meets this description (I
| won't plug it here). I chose Elixir for the web application.
| While I think that's a defensible choice, given the real-time
| nature of the application, I sometimes wonder if I would have
| been better off choosing a more mainstream language -- one
| with an official Stripe client library, for one thing. Any
| day I spent unnecessarily reimplementing something because I
| chose Elixir is a day that the target users couldn't benefit
| from my product. And, bearing that in mind, I should get back
| to work.
| aszen wrote:
| In a more mainstream language, while it may have a few
| Stripe client libraries but if your true use case of being
| real time isn't full filled then it makes no sense to
| choose them. A working stripe client takes at most a day to
| write, compared to years that can go in changing the
| architecture of your application
| WJW wrote:
| If you have enough talent that a good quality Stripe
| integration takes only a day to write, bending Rails or
| Laravel to serve websockets is not going to take more
| than a few days to write either. The true pain of non-
| standard languages is not in having to implement any
| specific dependency yourself but in having to reimplement
| a few dozen trivial-but-not-easy things yourself. It's a
| death by a hundred small cuts.
| PragmaticPulp wrote:
| > I would prefer the quality of engineering required in
| knowing how to do some of these things yourselves.
|
| Realistically, a couple of engineers writing a library from
| scratch isn't going to be higher quality than adopting a
| mainstream, battle-tested library that accomplishes the same
| thing.
|
| Writing your own implementations of everything can be fun,
| but it's not possible to compete with all of the iterations
| and reviews that a mainstream library collects over time.
| aszen wrote:
| This is a common argument i have seen devs make when
| evaluating building from scratch vs adoption, here's what
| building from scratch gives you, a leaner more
| understandable piece of code that does what you want and
| nothing more.
|
| An open source library is necessarily generic and has to be
| battle tested to make sure it fulfills all use cases, while
| the library you write only has to cover your own needs that
| makes it easier to understand, extend and debug
| Silhouette wrote:
| _Realistically, a couple of engineers writing a library
| from scratch isn't going to be higher quality than adopting
| a mainstream, battle-tested library that accomplishes the
| same thing._
|
| That's true but the vast majority of what you find on NPM
| is not mainstream, battle-tested libraries.
|
| Libraries that do clear that bar tend to be widely useful
| but that suggests generality you won't necessarily need for
| any single use case. A couple of good engineers might
| struggle to beat a well-established open source library at
| everything it does, but that is rarely what they are trying
| to achieve. They just need something that is better for
| their own specific needs at that time, which might be a
| useful and realistic target.
| dimitrios1 wrote:
| Once you detach from "I must use a library for every thing"
| land, you begin to realize you don't need the overwhelming
| majority of them. Which results in writing cleaner,
| simpler, more focused code, with less of a surface area for
| bugs. It's a whole mindset, tbh.
| ModernMech wrote:
| I appreciate libraries for:
|
| - ubiquitous things, like data structures
|
| - hard to get right things, like time
|
| - implementations of specs, like Unicode
|
| - hardware interfaces, like CUDA
|
| For everything else, I'll take the above and roll my own
| solution.
| dimitrios1 wrote:
| except for the last one, all of those should be part of
| the language you are using, and well thought out +
| researched. I guess I should have been more specific:
| third party dependencies.
| scotttrinh wrote:
| In this specific case (Elm vs. JavaScript) We're talking
| about JavaScript here, so:
|
| > - ubiquitous things, like data structures
|
| There are a few basic data structures in JS, but almost
| everything else is in user-land.
|
| > - hard to get right things, like time
|
| Date is a notoriously bad API in JavaScript.
|
| - implementations of specs, like Unicode
|
| We just get a String type in JavaScript which is UTF-16,
| so...
| alephu5 wrote:
| What about something tedious and ubiquitous, such as
| swapping between camel and snake case?
| aszen wrote:
| as an example i made a firebase auth client in elm using
| their api and json decoders in elm. honestly i feel it's
| much better than the official js client for the app i was
| building because it's so focused, minimal and exactly
| suited to my app's architecture
| pkolaczk wrote:
| Often you don't need to reimplement 100% of functionality
| of a library but just a 1% of it. Then, a talented team can
| usually make that 1% higher quality just because they are
| not limited by the complexity and tradeoffs added by the
| remaining 99%.
|
| Also many "battle-tested" libraries are not really very
| high quality - they all have bugs, unnecessary complexity
| and technical debt. Higher degree of testing they get is
| often offset by the higher number of feature requests, and
| more features means more complexity and more bugs.
|
| And in reality I saw it many times when a niche library
| written by a solo developer is of a higher quality than a
| super popular behemoth written by hundreds of developers
| over 10 years.
| k__ wrote:
| But...!
|
| I've also seen many developers for years adopting
| mainstream libraries and frameworks wrongly.
|
| The atrocities I've seen built with Ember, Rails, Angular,
| and the like.
|
| Often these people built their own (albeit less powerful)
| libraries and could work much better with them.
| KronisLV wrote:
| > Often these people built their own (albeit less
| powerful) libraries and could work much better with them.
|
| In my experience, if someone fails at using mainstream
| libraries, they will also likely fail in creating their
| own, at least if it is to later be used and maintained by
| anyone else successfully.
| k__ wrote:
| I don't know about that.
|
| The problem with mainstream libraries is to grasp the
| mental model of their creators.
|
| I met a bunch of developers who understood software
| design patterns as they are taught in the GoF book, but
| couldn't see them when applied in a framework/library.
| Often this was because the design patterns weren't used
| 1:1 or framework creators simply used the wrong name for
| a pattern.
| [deleted]
| aszen wrote:
| Elm is build on top of solid foundations, and has a good
| standard library unlike js so it's much easier to reinvent
| things as you say. One of the core ways to ship products
| quickly is to ensure you don't break things often, and elm lets
| u do that provided one learns it well enough
| theobeers wrote:
| From the opening section of the blog post, I wondered why an
| incremental move to TypeScript wouldn't have worked for them.
| The rest seems to be all about Elm (I haven't read it
| thoroughly), but I feel there's a disconnect between the
| problem they started with and their choice to dive into a
| wholly new ecosystem.
|
| edit: Ah, hold on; I just got to where they comment on this.
| "TypeScript, which adds optional static typing to JavaScript
| and is probably one of the best things to happen to JavaScript,
| can partially mitigate the issues with the JavaScript dynamic
| type system. But being a superset of JavaScript it needs to
| compromise on elegance and simplicity. It also has several
| 'blind spots.'" etc. I don't know that I'm 100% convinced.
| cardanome wrote:
| TypeScript has a slow compiler and horrendous error messages
| (especially compared to the Elm). Plus it is far away from
| the no runtime exception guarantees that Elm offers by
| design.
|
| Also TS is just part of a potential solution while Elm comes
| with all batteries included. You still have to set up your
| code formater, liner, decide on a framework, state management
| library and so on and so on. With Elm, you just use elm-
| format. No arguing about code style, not arguing about how
| structure your code. There is only way to do it. It is not
| only a language but a framework. You get everything you need
| out need out of the box.
| toastal wrote:
| Elm also has a sound type system and no side effects
| because it doesn't need to be compatible with vanilla
| JavaScript
| wk_end wrote:
| To play Devil's (Elm's?) Advocate here: sometimes I wonder if
| the TypeScript promise of incrementally adding types to an
| existing JS code base is wishful thinking.
|
| I'm at a company that's transitioning to TypeScript, and the
| reality is that you can't just flip a switch and have a well-
| typed codebase: if we just turn `strict` on, `tsc` gives us
| thousands and thousands of errors. And as we've gone through
| trying to annotate things, it's clear that in order to get
| various components to a state where they're properly type-
| safe, we'll need to almost completely rewrite them.
|
| Compared to Rakuten, our codebase isn't even that huge or
| legacy - it's often very poorly written, but it's less than
| 50K lines and less than a couple of years old. No doubt the
| situation for Rakuten would be even worse; I'm sure huge
| swaths of their code would need to be trashed anyway.
|
| If TypeScript is ultimately going to force you to rewrite -
| and still leave you with a less-robust solution - I could see
| why starting with a clean-slate with Elm would be appealing.
| Existenceblinks wrote:
| I had a problem with perf optimization on Html.Lazy long time ago
| that I can't solved before I moved on.
|
| Since Elm is immutable and lazy render, most of the time, compare
| underline object reference (referential equality check), the
| reference (memory location) almost always changes on every update
| cycle because it needs to update model, thus, a new reference as
| a result. And that makes Html.Lazy worthless. I had some kind of
| 1000 html tree nodes, and it rendered every branch every time. I
| probably did something not right, but I already tried solving
| that for a few days, no success.
|
| If you have the Elm in Action book, that memory location pitfall
| is explained on the very last page about when memory location of
| a object changes.
| agumonkey wrote:
| anybody using purescript and its streamed ui lib ?
| osener wrote:
| Do you have a link for this library?
| agumonkey wrote:
| I just spent 10 minutes digging google and I cannot find it
| again.
|
| I didn't even try to find about it last year, it seemed the
| only ui lib for purescript with a tiny docs website (beige /
| pale themed)
|
| Really surprised not being able to find it again.. I'll reply
| again if I end up finding it
| dodecaphonic wrote:
| Maybe you mean Concur? https://purescript-
| concur.github.io/purescript-concur-react/
| StefanWestfal wrote:
| From a self taught view, the compiler helped me a lot and when it
| compiles it usually works and when not the community is very
| helpful. Over all I found libraries usually of good quality while
| also not needing a lot as Elm includes a lot out of the box (i.e.
| React, Redux, axios, type guards, etc.).
|
| Elm-UI made working with styling much easier for me and was the
| main reason I gave Elm a try.
|
| The Evan and the core team seem to have a clear vision of what
| they want and I can understand that but this is personal opinion.
| To make a system work well you have to be strict and including
| new features all the time might introduce complexity down the
| line. This might seem a bit closed in form the outside.
|
| So far I am very happy with it.
| fulafel wrote:
| What are Elm users using on the back end? FP or mainstream
| languages?
| wolfadex wrote:
| I have coworkers using Rails for the back end of their Elm app.
| I think NoRedInk is using some Rails and some Haskell. I've
| have a friend who uses Python for his back ends. Also heard
| that some people really like using F#, as well as Node.
|
| Or if you want to do Elm full stack there's
| https://lamdera.com/ or https://package.elm-
| lang.org/packages/choonkeat/elm-fullstac....
| GiorgioG wrote:
| The bus factor of 1 makes it a non-starter for me for any serious
| project.
| adelarsq wrote:
| Sad, but true.
| G4BB3R wrote:
| I could use Elm as it is today for at least a decade without
| updates, since it's very stable. Anyway, I am sure there are
| very competent people from the core devs or from the community
| that could make a new leadership if that happened.
| GiorgioG wrote:
| Your assurances don't particularly mean much - no offense. A
| decade from now I don't want to have a codebase with a
| toolchain with no future.
| dsiegel2275 wrote:
| It is refreshing once again to see an Elm post that looks at the
| pros and cons of the language and ecosystem, instead of solely
| focusing on a perceived problem with the way that the community
| is run.
| sergiotapia wrote:
| I'll never even consider Elm after they added DRM to the
| compiler. https://news.ycombinator.com/item?id=27819874
| jeofken wrote:
| Would it not be to prevent supply chain attacks, and to
| guarantee the user that all code you run is pure and type safe?
|
| They don't hinder anyone from forking and removing this
| limitation, allowing any package author to run native code on
| your machine.
| macintux wrote:
| > They don't hinder anyone from forking and removing this
| limitation, allowing any package author to run native code on
| your machine.
|
| That has arisen a few times here. Yes, they actually do
| actively discourage forking (to the point of threatening
| "excommunication" from the community).
| vmchale wrote:
| Yeah if anything the need to constantly fork the compiler
| indicates a problem lol.
| jeofken wrote:
| Who cares? It's a computer program, just have it do what
| purpose you require
| macintux wrote:
| Forking has long-term maintenance costs, even without the
| hassle of trying to hide your efforts from the Elm
| maintainers.
|
| I'd be fine forking it to pursue a personal project. I'd
| never do that for any critical business need.
| rtfeldman wrote:
| Just to correct this: for as long as I can remember, Evan's
| stance has been "feel free to fork Elm, just please don't
| call your fork Elm, since that would confuse people."
|
| There have been a couple of forks with different names, and
| nobody's been "excommunicated" or whatever. The forks
| haven't gotten much traction, but they're probably still
| out there.
| macintux wrote:
| I have heard otherwise, both in comments here and via
| https://lukeplant.me.uk/blog/posts/why-im-leaving-
| elm/#forka..., but it's entirely possible I'm wrong.
|
| Added: This comment is also not terribly friendly.
|
| https://github.com/gdotdesign/elm-github-
| install/issues/62#i...
| rtfeldman wrote:
| My word choice certainly could have been better (I was
| upset, and it showed), but to quote what I said there
| anyway: "If you understand the design goals, but don't
| agree with them, why not channel that in a positive way -
| e.g. by building something that fits your vision instead
| of directly working against Elm's design goals?" - in
| substance, this is consistent with what I said above:
| it's totally encouraged if anyone wants to go in a
| different direction from Elm's design, just please don't
| call it Elm.
|
| As it turned out, this is exactly what the OP in that
| thread did - he created https://www.mint-lang.com - which
| I think is a very positive development indeed!
| G4BB3R wrote:
| That's not true, lamdera is a fork and has it's own channel
| inside elm slack. Terezka (that is from core team) already
| said that if part of the community wants to fork Elm, that
| would be ok.
|
| https://discourse.elm-lang.org/t/clients-expressing-doubt-
| ab...
| macintux wrote:
| I have heard otherwise, both in comments here and via
| https://lukeplant.me.uk/blog/posts/why-im-leaving-
| elm/#forka..., but it's entirely possible I'm wrong.
|
| Added: This comment is also not terribly friendly.
|
| https://github.com/gdotdesign/elm-github-
| install/issues/62#i...
| macintux wrote:
| Ah, I see, lamdera isn't a "we'll change Evan's
| architectural decisions" kind of fork, which seems to be
| much of the source of contention.
___________________________________________________________________
(page generated 2021-08-18 23:00 UTC)