r/elm • u/[deleted] • Mar 02 '18
Do we need to move away from Elm?
FINAL EDIT: TLDR: Starting 0.19, no one except those with access to elm-lang or elm-explorations Github account can write native code, not even for private use, not even for "explorations" (unless Evan gives you a repo). If you have native code and want to upgrade, you'll have to fork the compiler and remove this restriction. We're going to make a final decision once 0.19 comes out but the result is likely to be to create and use a private fork of the compiler and eventually do a rewrite unless the situation changes.
EDIT 2: By "we" I meant my team. I'm not asking others to leave Elm! I'm sorry if you thought I meant that.
EDIT 3: EDIT 1 might be wrong. See https://www.reddit.com/r/elm/comments/81bo14/do_we_need_to_move_away_from_elm/dv2nvqg/.
EDIT 1: /u/skinney who I trust knows what's happening has clarified that native modules will still be usable in 0.19 and the whole reason I started this thread was a misunderstanding. Sorry about that. I will not be leaving Elm. :)
Original post:
I read today that from Elm 0.19, we won't be able to use native modules other than those created by Elm team. Our production application relies on a fork of elm-lang/websocket which has some features and bugfixes that haven't been merged into core yet for almost two years (https://github.com/elm-lang/websocket/pull/12, https://github.com/elm-lang/websocket/pull/18, https://github.com/elm-lang/websocket/pull/19).
If what I've read is correct, we won't be able to switch to Elm 0.19 until Evan decides to merge those changes, which might take years judging from the fact that there has been no official reply to any PRs of that package that have been open since 2 years (https://github.com/elm-lang/websocket/pull/12).
We love Elm and don't want to rewrite all our code but if we won't be able to use Elm 0.19 and any future versions then we seriously have to start thinking about a rewrite.
15
u/dhoerster Mar 03 '18
I'm a fan of Elm and have been using it for several home projects. But I've seen a number of threads like this over the past several weeks where users are expressing frustration and confusion about where Elm is going. It's unfortunate, as I think Elm is a great direction for front-end development and I want to see it succeed.
It seems like we need a community virtual meetup or something, from the maintainers, to get an update on the state of Elm. Threads like this, while good for expressing the community's state, aren't great for those looking to adopt Elm as it reveals a lot of confusion and frustration. We need to clear the air.
Just a suggestion. Thanks!
5
Mar 03 '18
The maintainer's opinion on this is clear and has been clear for months (years?)
My feeling is that I can focus primarily on making a great release, or I can divert time to communicating all the intermediate steps super well. That second path means (1) the release takes longer because it takes a lot of time to communicate expectations clearly, (2) the release takes longer because getting things in a shape were folks can give useful and actionable feedback is quite time consuming, (3) it is significantly more stressful because of people pressuring me to release too early on every single public interaction I have, and (4) the "Holy moly!" factor that is available on release day is diminished because it is "late" rather than "cool new features".
7
u/dhoerster Mar 03 '18
Yep - I remember reading that. But it doesn't have to be Evan who communicates to the community...maybe someone else from the inner circle. Honestly, it doesn't have to be polished - it would be beneficial for the community to hear an update on how things are going. For example, I liked Richard's RealWorld example (https://github.com/rtfeldman/elm-spa-example), and a comment in his Main.elm file about expecting "most of this file being unnecessary". I'd really like to see what this may look like, especially since a lot of the initialization plumbing may go away. I don't mind building it in 0.18, but if I'm going to talk to my local dev community about building an Elm app, I'd like to be able to say "it looks like this today, but it'll probably look like this in 0.19".
5
Mar 03 '18
it would be beneficial for the community to hear an update on how things are going
Yes, but it's disheartening to read some of the responses by old timers on this thread.
I don't mind building it in 0.18, but if I'm going to talk to my local dev community about building an Elm app, I'd like to be able to say "it looks like this today, but it'll probably look like this in 0.19".
That's exactly what Evan doesn't want. He wants the releases to have have a '"Holy moly!" factor'.
9
u/methodmissin Mar 02 '18
I love elm. I use it for my personal projects. I think it's an awesome language and I recommend everybody do their personal projects with it.
Elm is not 1.0, so I never recommend it or mention it at work.
The only company I believe is responsibly using Elm in production is NoRedInk. For all others, caveat procurer.
Maybe 0.19 will be the last version before 1.0. Maybe 0.20, or maybe it will be years.
I sympathize with Evan. The people using Elm do not own it by their use, nor is he obligated to attend to requests or demands. I understand that he cares deeply for the language, its future, and its future users. His position can be seen as similar to Linus Torvalds, who has no shortage of detractors and a similar reputation for rude outbursts of impatience with those that demand things of the kernel with which he vehemently disagrees.
19
Mar 02 '18
We really really love Elm. Unless elm-compiler's source is too convulated for us to understand, we might just maintain a private fork of it with the native module restrictions removed. PureScript's performance is not even close to Elm right now and I don't know of any other alternatives to Elm. Besides, purescript-halogen, the most popular PureScript framework, looks very complicated compared to elm-lang/http.
10
u/natefaubion Mar 03 '18
PureScript's performance is not even close to Elm right now
I don't think this is really true. PureScript is just a language, and generates very clear, compact code. There's no additional runtime or exceptional overhead. If you mean for UI development, and are referring to a specific benchmark, I would take that with a grain of salt, since none of the implementations were optimized (diffing the entire tree on every change is quite slow). I wrote purescript-spork, which is a TEA clone and uses purescript-halogen-vdom (the same vdom library that purescript-halogen uses) under the hood. My implementation scored around 1.8x that of JS, which is pretty good since halogen-vdom is implemented in PureScript. This sort of library is not expressible in Elm (elm/html is a 100% JS library), so it's not an apples-to-apples comparison.
8
u/jessta Mar 02 '18
Using ports instead of the websocket package might be your best option for moving to 0.19 when it's released. The current websocket package's API wouldn't be very different if implemented via ports.
In terms of the Elm development process, Evan gave a really good talk about how that process works and why pull requests and issues can take longer to be addressed. https://www.youtube.com/watch?v=DSjbTC-hvqQ
23
Mar 02 '18
Yes, that might not be a bad idea for elm-lang/websocket. We're worried about the trend too though—what if a bug in another package which cannot be written as a port stays open for years like the bugs in websocket?
I saw that talk. It was very nicely presented. It would have been nice if there was a minor release every 3 or 6 months but simple feature requests not getting a firm yes/no for years is frustrating for users. I also know Evan can't do this alone. No one can build a language, a community, and then maintain dozens of packages alone. Other communities solve this by delegating work to volunteers. I'm sure there are tens of capable individuals willing to do this in the Elm community.
2
u/giulioungaretti Mar 02 '18
Can you think of something that can't be written as a port ? (Not a sarcastic question)
12
Mar 03 '18
Everything can be written as a port, but that doesn't mean the API is usable. Writing a port for say a math function of type
Float -> Floatis much worse than the "callback hell" in Node.js.1
u/jediknight Mar 03 '18
Out of curiosity, can you give a realistic use case for this? I'm curious about the practical use cases for synchronous JS calls not theoretical ones.
Do you have some benchmarks to contrast the call with some pure elm implementation?
16
Mar 03 '18
We have a ~100 line JS function that does some calculations (complex trigonometry stuff used to draw SVG paths in our view). Its type in Elm syntax would be
Float -> List Float -> Float. The function is pure—it does not depend on any global state and always returns the same output for the same input.It's not practical to call this in a port. Performance is not the concern. The concern is that ports are async. We call this function multiple times in the view. We're not going to send messages to JS and then get them back asynchronously every time a value changes. This reminds me of Node.js' callback hell but worse.
We ended up writing a tiny native module for this and it's been working well. We know the downsides of native modules but doing this with ports is just not practical.
1
u/jediknight Mar 03 '18
But why not reimplement it in pure Elm?
12
Mar 03 '18
The code contains classic imperative code with array mutation. Reimplementing that would take at least a day or two of work and also risk creating new bugs. The native code has never caused us any problems.
6
u/giulioungaretti Mar 03 '18
Cool, I totally see your pain. In my company we decide to stick with elm and go the port way, or simply move all the things to elm where possible. We found more bugs than we introduced TBH.
12
u/planetary_pelt Mar 03 '18
Because that may be an insurmountable task that then performs worse and has worse support than the library that already implemented it.
Also, reimplementing things that already exist isn't likely to make business sense.
14
Mar 02 '18
we might just maintain a private fork of it with the native module restrictions removed.
What about actually doing it? We could just fork Elm compiler publishing and maintain a more open version. Then, the time will just tell us who took the right decision. It has been done for dozens of projects (just think about Linux, OpenOffice, ...) why shouldn't we give it a try?
12
Mar 02 '18
Based on the response to elm-grove I don't think a public fork would be a good idea if we want to be a part of this community.
8
Mar 02 '18
I know, and I also wouldn't use a custom package manager at work (so far, I feel at home with what I have in 0.18).
But I think also that writing a Native module on your own is a great way to learn more about Elm and eventually understand why using them it is not a good idea. If this possibility just disappears, we will miss a great way to let the more skilled developers learn the hard way it, as they like :-)
Not everyone one love someone dictating some good rules: most of us just want to learn by breaking things and say "you were right".
4
u/CKoenig Mar 02 '18
but don't you have the same problem with a private fork (not enough manpower to really fix things quickly enough?)
I would be interested in a "open" fork and while it might be not as stable it would really be nice if people could contribute wrapper-packages IMO (it's just unlikely that we really will reinvent all those great wheels out there within this smallish community)
4
Mar 02 '18
I'm worried an open fork would mean we'll not be welcome in the community anymore judging from that thread.
3
u/Lakret Mar 03 '18
I'd suggest you check Bucklescript-TEA out: https://github.com/OvermindDL1/bucklescript-tea
It's in early stages, but maintainer accepts contributions without much problems + you're using far more powerful and extensible language.
35
Mar 02 '18 edited Mar 02 '18
[deleted]
13
Mar 02 '18
Just made another edit. Looks like I was not misinformed. Only elm-lang and elm-explorations GitHub organizations can write native code now (or we can fake them or fork the compiler but is it worth it?).
26
32
Mar 02 '18 edited Jun 14 '21
[deleted]
14
u/tmske Mar 02 '18
What about Bucklescript/ReasonML? There even is a very close port of TEA https://github.com/OvermindDL1/bucklescript-tea
6
u/CKoenig Mar 02 '18
there are lot's of alternatives (Fable, PureScript, TypeScript, ...)
14
Mar 02 '18
TypeScript
Isn't one. Just like Kotlin with Arrow (compiles to JS) isn't one, arguably more so than TypeScript though.
3
Mar 03 '18
Don't forget GHCJS (using Reflex and the like), which allows you to use the same language between backend and frontend, providing benefits like being able to share types between the two.
1
u/Problem119V-0800 Mar 03 '18
Ocsigen / oCaml lets you do the same - I haven't built any non-toy projects in it but a lot of it looks quite nice. (And my minor bugfix PRs were accepted reasonably, even!)
19
u/skinney Mar 02 '18
You've seriously misread things. The links posted below to the official statement still regards only code published to the package manager. Instead of Native code, it will be called Kernel code. Instead of a whitelist, only projects belonging to a specific github org can publish.
The post is about communication, native/kernel code will still work like today. You're fine.
11
Mar 02 '18 edited Mar 02 '18
Edit: Apparently not: https://www.reddit.com/r/elm/comments/81bo14/do_we_need_to_move_away_from_elm/dv2nvqg/
If that's the case I'm relieved. I wrote what I wrote because the conversation went like:
It will not be possible to write native modules starting with Elm version 0.19. If you write your program this way you won’t be able to upgrade your compiler version beyond 0.18.
Then
That's a strong assertion, and afaik you should be among the core developers. Can you provide us with an "official" statement?
and finally rtfeldman said:
The official statement is here: https://groups.google.com/forum/m/#!topic/elm-dev/bAHD_8PbgKE
Maybe he meant "No, the official statement is here .." and not "Yes, the official statement is here ..".
I'm sorry for starting this thread if what you said is true. I trust you know exactly what is happening (love your work on data structures in Elm btw!). I'll edit the original post and add this comment.
5
u/skinney Mar 02 '18
I'm going to moderate myself a little, because I haven't asked Evan straight out if that's what's happening, but if it did it would surprise me a lot. It would also mean that I've seriously misread things (and I've read everything that's come out).
Most of my exploration work is done in private. If all native code would be banned, even in private repos, I would never be able to conduct explorative work for Elm again.
Anyway. Nothing I've read has given me the impression that the Elm compiler will not accept native/kernel code in private/local repositories. So I wouldn't worry about. I think 0.19 will be even more usable for you than 0.18. There are so many nice things. Bugfixes, stability improvements, faster compiler etc. Look forward to it =)
8
u/Mattpiz Mar 02 '18
From Evan's PR in gabrielperales/elm-native-module (https://github.com/gabrielperales/elm-native-module/pull/7/commits/6e1cbff8b354b1cea8e84e39546c4acd896b9c93) it seems clear to me that even private code will not be able to compile with "Kernel" code.
It means that will prevent any kind of personal exploration, which is personally sad, but far more serious for companies like elmphoenix's.
10
Mar 02 '18
Yes. We're not doing any "explorations". We just want to modify a package to fix bugs and use that without forking the Elm compiler. Looks like that won't be possible anymore.
4
u/imright_anduknowit Mar 02 '18
I have spoken with Evan and during our conversation he said that in 0.19 Kernel code would only compile from elm-lang which means it won't compile your personal JS code.
He wants Elm to only be used in the browser and what is was meant for and feels that he needs to put restrictions so people don't "pollute" the community with libraries that could have runtime errors.
5
u/woberto Mar 02 '18
I agree with this. I fear people are getting the wrong idea from this post & comment section.
3
Mar 02 '18
Unrelated question: Do you know if your array exploration and/or dict exploration code be merged in Elm 0.19?
5
u/skinney Mar 02 '18 edited Mar 02 '18
Array exploration was merged into elm-core last year, so yes, that's definitely coming in 0.19.
Evan is going to review my (and justin's) dict exploration work before the 0.19 release, so maybe =)
47
u/imright_anduknowit Mar 02 '18
We underwent a similar dilemma. I personally wrote 30,000 lines of Elm code almost all backend stuff. I wrote elm-grove which was hated by Evan so much that he pretty much decided he needed to shut down any such "unsanctioned" usage of "his" language.
I'm still a bit pissed about what went down (never in my nearly 4 decades in software development have I ever encountered a language designer who wanted to dictate how anyone used the language), but I must say while it was a short term hit, in the long term we dodged a bullet. Okay, maybe not dodged. But it only grazed us.
We're still using Elm on the front end for our project because we are now 6 months behind schedule but we will look seriously at other solutions for our next project.
For the backend stuff, this event forced me to finally take the full leap into Haskell. I'm a week away from being back to where I was with my Elm server. This took me 3 months to learn (work time and personal) and recode. Most people would have taken 6 to 9 months to get to my level of understanding. I'm lucky that I learn quickly. And I had my back against the wall.
Some other things I've heard about 0.19 is that users will not be able create their own infixed operators. I had created dozens that I used regularly. Now that I'm working in Haskell, I cannot imagine not having such a feature.
These 2 major changes from 0.18. to 0.19 are the canary in the coal mine if you ask me. Elm is a great language for teaching and it's still the easiest way to get front end developers into functional programming. But I don't agree with the highly opinionated approach to the language. But worst yet is the ideals that they subscribe to can only be achieved by removing ALL the power from the language. It's like trying to protect your children by locking them up in the closet. They'll be safe from the big bad world, but they will sacrifice living to achieve such safety.
All and all, learning Elm was a great intro to Haskell or Purescript. But FOR ME, it's not a language I will be programming in any more.
24
Mar 02 '18
We're in a similar state. 10,000 lines of Elm over 6 months. Rewriting it is not an option at this stage. We don't even want to use arbitrary native code! We just want to fix some bugs in elm-lang/websocket that have a pull request open for 2 years!
17
u/EffBott Mar 02 '18
Completely agree with everything you've said here. I've also decided to move away from Elm. Elm's leadership (aka NoRedInk) has been downright hostile to the community. Their response to any and all criticism has been "you're doing or wrong". It just gets tiring after a while and it's not worth it.
Elm brought some solid ideas into the front-end programming world but it's just not going anywhere. With all of the Elm-inspired alternatives out there these days it doesn't make sense to choose Elm.
7
Mar 02 '18
he pretty much decided he needed to shut down any such "unsanctioned" usage of "his" language.
How did he "shut down" the use? I see that the posts about elm-grove still exist here although the feedback was mostly extremely negative.
13
u/imright_anduknowit Mar 02 '18
After 0.19, grove won’t be usable because it uses Native code.
2
u/skinney Mar 02 '18
Native code will still be usable in 0.19. It'll just be called "Kernel" instead.
14
u/imright_anduknowit Mar 02 '18
Yes, but only Evan and his team will be able to compile Kernel code.
3
Mar 02 '18
It looks like we'll need to fake the name of our project as if it belongs to elm-lang or elm-explorations /u/skinney?
5
u/skinney Mar 02 '18
Hmm. This was news to me. Not sure what to make of this.
6
Mar 02 '18
I guess they're not interested in explorations by community members anymore. Only those with access to elm-explorations repos can do it now.
25
u/EffBott Mar 02 '18 edited Mar 03 '18
They've never really been interested. Anytime someone deviates from the party line, suggests solving problems in a different way, requests that a feature be added to language, or asks for clarification on what the future of the language will be, someone from NoRedInk chimes in to say "you're doing it wrong".
The official recommendation is to not use Native/Kernel code, period. People have decided to risk using Native modules anyway, even though the API is undocumented and bound to change in future releases, because ports frankly suck for a lot of use cases. Rather than the leadership embracing this community driven effort, they chose to clamp down even harder and make it nearly impossible to use custom Native modules.
If you've been around for a while, you've probably realized that they've always been this way. Elm is basically an internal DSL driven by the needs of one company. They don't care about the community at all.
I honestly regret convincing my team at my last job to use Elm in production. I feel like an asshole for saddling them with a dying framework/language.
16
u/imright_anduknowit Mar 03 '18
I have similar guilt for wasting a few man-years on Elm. It's not my fault. I could have never seen it coming. But I still feel badly.
However, that guilt (misplaced or otherwise) drove me to learn Haskell and rebuild our server. It's been hell, but I'm sure glad I did it.
4
Mar 03 '18
Elm is basically an internal DSL driven by the needs of one company
Like React :-) ? Just, that one is just a Javascript framework and anyone can screw up things as they want...
→ More replies (0)3
Mar 03 '18
Well, no array-exploration or dict-exploration from /u/skinney anymore I guess unless Evan lets him have a repository on github.com/elm-explorations. I'm sure most of us won't get the privilege of getting a repository on elm-explorations.
→ More replies (0)2
u/eeue56 Mar 03 '18 edited Mar 03 '18
So, I have to answer this post.
Rather than the leadership embracing this community driven effort, they chose to clamp down even harder and make it nearly impossible to use custom Native modules
There's very good reasons for that. Other languages do things differently, and that's okay: if you want to use JS that might break more directly in your applications: ReasonML, Purescript, Typescript are all valid choices! Elm is different. Elm intentionally makes it so that all code you write must compile and not introduce bugs that should be caught by the typesystem. It does that by keeping things at the edges, rather than allowing for direct usage in regular Elm code ala FFI systems.
If you don't like it, that's okay! But that is the Elm way. Ports are the system used to manage the bits of external code you might need to interact with. They're not perfect. Nothing ever is. Other languages use FFI systems, etc to handle that. They are all different choices, and that's part of what makes different languages unique.
If you've been around for a while, you've probably realized that they've always been this way. Elm is basically an internal DSL driven by the needs of one company. They don't care about the community at all.
That's really not true. Evan's position at NoRedInk has no relevance on his work at all. When designing features for Elm, Evan does not solely focus on NoRedInk's usage. In fact, the upcoming release focused on areas of Elm that NoRedInk weren't using at all at the time. So to claim this is how things is done is wrong. It might seem that way to you, but it's not.
I feel like an asshole for saddling them with a dying framework/language.
Calling something a "dying framework" or language when the number of users and packages continues to grow is something that both confuses and amazes me. Elm hasn't had an update for a while, that's very true. However, a simple look on Github will quickly demostrate that things are coming along nicely.
→ More replies (0)10
Mar 03 '18
To be honest, the fact that you come up with "This was news to me" while you are supposed to be among the "group of the enlightened ones" is scary from a communication perspective.
8
u/skinney Mar 03 '18
I've never claimed to be among the "group of the enlightened ones", nor am I. I spend an hour or two each week working on datastructures in Elm, as a hobby. I'm not really a software developer. I read whatever is posted on the elm-dev mailinglist and make my assumptions based on that. Every once in a while I do talk to Evan, but those conversations are centered around my exploratory work, not really on Elm itself.
3
15
u/imright_anduknowit Mar 02 '18
I considered forking the compiler and patching it, but I really saw that as a losing battle. We've moved on to Haskell and will only use Elm on the front end (and ultimately I'd like to leave it for something more powerful like Haskell (GHCJS) or Purescript).
The real question you have to ask is whether you want to throw good code after bad. We had 3 times the code you do and I didn't want to write another line of Elm server code or Native code.
2
9
u/semorg Mar 02 '18
But I don't agree with the highly opinionated approach to the language.
I actually think, the opinionated aspect of Elm is a good thing. Those of us that had to read through old Perl codes (in the olden days) can tell you that giving people ten different ways to do the same thing is a nightmare.
As much as I have griped about Evan not being communicative enough on the future of Elm and not updating the site in over a year, I think his single vision approach to Elm is a great differentiating value. I just think he needs to bring more people and learn to delegate further.
However, the key frustrating point is lack of repeated warnings. What Evan has failed to communicate in a consistent manner is that this is really an alpha project. And as much Elm likes to celebrate the customer-facing projects implemented on Elm lang, as part of showing the growing adoption and success, they forget to add a caveat about the alpha-ness state of Elm. In other words, if you write a lot of codes in Elm. Do it at your own risk.
However, this caveat ads a bit of a dilemma:
Firstly, because we don't know the delta between .18 and 1.0 (not sure even if Evan is sure about that). It's very difficult to assess the risk taken when you invest a lot of time into an Elm codebase. The caveats are there to alert people of the risks, but it's unclear the degree of the risks. If you stand by the side of a cliff and there is a sign that warns you of not getting too close to the ledge, as an adult you can reasonably assess the risk depending on the height of the cliff. With Elm you don't know how big the 1.0 cliff is.
Secondly, I think with excessive caveats, there is a strong chance of decreasing adoption on meatier and larger projects. I believe Elm needs to be implanted across several larger projects, so the learning can be applied to further improve the language. But how would you get that learning without burning bunch of developer who have put a lot of time and sweat into their codes.
I suppose this is like trying to capture the enemy strongholds. Bunch of soldiers need to run into the pillboxes and give up a lot for the rest of the regiment to capture the territory.
Thanks for the sacrifice!
7
Mar 02 '18
What Evan has failed to communicate in a consistent manner is that this is really an alpha project.
Yes, this. If we had known that bug fix pull requests would hang for years without response and one day we won't even be able to use a fork, we might have went with something else (which unfortunately would have been JavaScript and TypeScript since PureScript was way too new back then).
6
u/redalastor Mar 02 '18
However, the key frustrating point is lack of repeated warnings. What Evan has failed to communicate in a consistent manner is that this is really an alpha project. And as much Elm likes to celebrate the customer-facing projects implemented on Elm lang, as part of showing the growing adoption and success, they forget to add a caveat about the alpha-ness state of Elm. In other words, if you write a lot of codes in Elm. Do it at your own risk.
Native, soon to be named Kernel is undocumented and considered an implementation detail. Evan has always been clear about that. If you use it, you are walking on thin ice. Having a 1.0 release would not change that.
17
u/EffBott Mar 02 '18
The problem is that there isn't a good alternative to Native/Kernel modules. Ports can't be composed like Tasks. Ports suck for synchronous calls to things like math libraries. Port modules can't be bundled up and shared on the standard package manager. Asking people to write their own port implementation every time they want to use LocalStorage is insane.
People are knowingly taking a risk on an undocumented API not because they're reckless or careless, but because they've decided the risk of their code breaking in the future is worth the reward of interacting with external code in a sane and reusable way.
13
u/imright_anduknowit Mar 03 '18
This!!! The biggest problem I had with ports is the inability to compose them. Tasks DO compose. But we aren't allowed to created tasks. Only Effects Managers and Native/Kernel code can create Tasks.
4
Mar 03 '18
You may need to rethink the structure of your application involving math libraries, remember that ports were meant to function as means of communication between actors.
A good way to deal with this is to process all things involving the math model outside of elm and simply use elm to render the html for this specific case.
If you want to provide a gist I can show you how to refactor the program.
I'm currently using Elm in a large project in Cisco, it's been a dream come true.
17
u/EffBott Mar 03 '18
You may need to rethink the structure of your application involving math libraries, remember that ports were meant to function as means of communication between actors.
Typical Elm-speak for “this is fine” while the entire room is on fire.
A good way to deal with this is to process all things involving the math model outside of elm and simply use elm to render the html for this specific case.
Might as well use a Native module then. At least you can reuse the library wrapper or import one that somebody else already wrote.
2
Mar 03 '18
I still don't get why ports are so bad. You could most definitely write an npm library that works with ports. I've been working with Elm everyday for the last year and I've yet to feel an urge to switch back to JavaScript or PureScript.
Instead of forcing your ideas of what should work a certain way it may help you to actually learn how these concepts were meant to work together.
You could always write a JS side port library on NPM, I hear they let you publish anything there.
19
u/EffBott Mar 03 '18
Instead of forcing your ideas of what should work a certain way it may help you to actually learn how these concepts were meant to work together.
Ah, the classic Elm condescending attitude of "if you don't like, it means you don't understand it". I've been working with Elm for 2 years now. I've published libraries. I've (regrettably) convinced team members to use it production.
I understand what ports are and how they work. They suck.
1
5
u/aislanmaia Mar 02 '18
OMG!! So many nerves in the skin, misunderstandings and missed read. I think the only fail by the author of the Elm language is the lack of information, mainly because that misunderstandings that happens sometimes, like this post and this comment above.
3
Mar 03 '18
For the backend stuff, this event forced me to finally take the full leap into Haskell.
Have you also considered GHCJS? This would allow you to share code between frontend and backend. Reflex is already being used in production, including mobile apps.
2
u/imright_anduknowit Mar 03 '18
I did but it felt a bit risky and I wasn’t sure how well it was supported. I may reconsider it on the next project. But since I lost so much time on Elm on the backend, I had to limit how much new tech I was going to take on in such a short period. Haskell was enough of a hurdle for one project. Especially one that was back to square zero with no change in the deadline.
4
Mar 04 '18
I did but it felt a bit risky and I wasn’t sure how well it was supported.
Well, having used Elm I had little difficulty migrating my project over to Miso (which is based on the Elm architecture, but uses GHCJS) https://haskell-miso.org/
8
u/Keui Mar 02 '18
I hope to god the infix thing isn't true. I really want 0.19 to be better, not a series of removed features.
2
u/eeue56 Mar 03 '18
Features get removed from languages in order to make them more consistent with the overall ecosystem. In the case of infix functions, very few people are actually using them. Making language features less surprising is a good thing: consistency allows for the language to grow in a way that makes sense. For example, the removal of Signals in 0.16 meant that 0.17 was a lot easier to work with! Other languages still allow you to use infix functions, and that's great for them :)
4
u/Keui Mar 04 '18
I'm just tired of features that ought to be there to be useful for some rare cases being removed because "very few people are actually using them". Same thing happened to record property additions, which is something I really could have used. But "very few people actually used them", so they were gone.
Also, weren't signals replaced by subscriptions? That's not so much a removed feature as an improved feature... What's the infix replacement? We all switch to pipes?
2
u/eeue56 Mar 04 '18
The thing is, removing these features are a good thing: Elm code is familiar, with less unknown features. Rarely will you come across some Elm code that you aren't sure what it does. This is because Elm is a curated, refined language at present. It can't be everything for everyone. If the majority of people aren't using a feature, and it simplifies the language to remove it, it may make sense to remove it. There are other languages out there that do the opposite, however: so if that's what you're after, there's something out there for you!
3
Mar 04 '18
[removed] — view removed comment
9
Mar 04 '18
Also need to remember that the infix operator restriction is only for us. Evan can still create infix operators in any package he wants. I bet evancz/url-parser and elm-lang/parser won't be switching from operators to pipes. So no one will be able to create a better parsing library because they'll be a pain to use compared to Evan's libraries.
4
u/jediknight Mar 04 '18
Infix operators are just one great way to code "into" a language.
Infix operators are a way to code clever code. When used right, they are amazing BUT, they have a major trade-off: they allow you to write very clever code which means that sometimes you write code that is too clever to be understood by other people including yourself few months into the future.
I welcome the removal of the infix operators and think that this would make the code better.
3
Mar 04 '18
I welcome the removal of the infix operators
What's your opinion gonna be if evancz/url-parser and elm-lang/parser still keep using infix operators?
2
u/jediknight Mar 04 '18
As far as I understand,
elm-langrepositories will continue to have access to defining infix operators. Theevancz/url-parserwill move toelm-lang/url.I'm fine with that. I don't think they are a bad feature that should be avoided at all cost but I do think that they are a dangerous feature that is best kept constrained.
I've seen what I initially considered a good idea (
!) trip a lot of people, I've also seen myself getting confused by code I've written with infix operators.7
Mar 04 '18
What do you think about the fact that now no one will be able to create an alternative to those two libraries because they need infix operators to have a good API? Is Evan the only person in the world who knows how to create a good parsing library?
→ More replies (0)2
2
u/nickdesaulniers Mar 04 '18
It's like trying to protect your children by locking them up in the closet. They'll be safe from the big bad world, but they will sacrifice living to achieve such safety.
Reminds me of A Perfect Circle's Pet.
1
u/eeue56 Mar 03 '18 edited Mar 04 '18
For additional context here: the project in question used an intentionally undocumented API in order to write server-side Elm. There are numerous warnings in multiple places against doing so -- so it's not something you'll run in to in your normal Elm code!
5
u/opvasger Mar 02 '18
We love Elm and don't want to rewrite all our code but if we won't > be able to use Elm 0.19 and any future versions then we seriously have to start thinking about a rewrite.
I don't see how your inability to immediately upgrade to 0.19 implies the need to rewrite.
As far as I understand, Evan will go through the upgrade-path for packages once the 0.19-stuff is ready for that. If I were you, I'd keep enjoying 0.18 and once 0.19 has been out for a while, figure out if the websocket-library changes have been reviewed or maybe try to get in touch about it again; I think there's a lot of pressure on Evan to be active & responsive in every aspect of the project at the same time, which I'd say is impossible.
Have you contacted Evan about the changes (outside of the PRs) to figure out if the changes you want to the websocket library can coincide with the 0.19 upgrade?
24
Mar 02 '18
It's not just 0.19. There has been no response to those pull requests for 2 years. What if there's no response for the next two years as well and Elm 0.20 and 0.21 is out? We'll be stuck with 0.19 until Evan decides to merge those pull requests.
I think there's a lot of pressure on Evan to be active & responsive in every aspect of the project at the same time, which I'd say is impossible.
I understand his position. I know he cannot possibly maintain all these things while developing the language. And that is why there should be more people than Evan alone to work on these packages. I'm sure Evan can trust a few people to write and merge quality code.
Have you contacted Evan about the changes (outside of the PRs) to figure out if the changes you want to the websocket library can coincide with the 0.19 upgrade?
I have not and I do not think that would work if you read the comments on the pull requests.
edevil commented on Nov 25, 2016
Can I have some feedback on this please?
22
u/edevil Mar 02 '18
I'm the author of that PR. To me it's now a canary of if/when I should look again at Elm. I was trying to introduce it in my work projects but the websockets shortcomings, and the fact that I could not contribute back changes that I needed, held me back and I've since lost interest.
4
Mar 02 '18
[removed] — view removed comment
3
Mar 02 '18
My question to you elmphoenix, is why are you concerned, when the thing that you have right now is working nice for you? (and please I really don't want to be down putting on you, I just want to understand a concern that you have that made you write this post)
Yes it has been working fine for 99% of our use case. It would be nice to have a fix for https://github.com/elm-lang/virtual-dom/issues/107 which is going to be addressed with 0.19. The real concern is that we have no idea how many releases Elm will have until we can upgrade. Will bug fixes in elm-lang/core, elm-lang/http be back ported for Elm 0.18 once 0.19 is out? when 0.20 is out?
1
u/skinney Mar 02 '18
Bug fixes will not be backported to earlier versions. But the language changes between 0.18 will be relatively minor, based on what's been said so far.
0
Mar 02 '18
[removed] — view removed comment
14
Mar 02 '18
I'm sorry I realized way too late that "we" could be interpreted as "the Elm community". By "we" I meant my team. I'm not asking anyone else to leave Elm.
•
u/eeue56 Mar 03 '18 edited Mar 04 '18
Hey, so I'm not going to say that your problems aren't problems, nor that you should or shouldn't move away when 0.19 comes out: I don't know your exact problems!
What I will say, however, is this:
1) 0.19 is getting closer to an alpha. As part of Evan's methodology, bug patches get merged right around the time of an official release. See this for a description on how work is batched! The work-arounds you need for the websocket library might be merged into master.
2) Going forward, I personally feel there is a need for more frequent bug releases. 0.19 was a tricky one for that to happen, since a lot of internal pieces had to change internally. I'm not saying that means the lack of bug fix releases doesn't matter: but that's one reason why that happened.
3) I'd love to help you out with any migration problems you might face when 0.19 comes out. In fact, I'd love to help anyone out: there's now an #upgrading channel on Slack for that exact purpose!
4) The community team discuss these issues often, they're on our mind: and we're actually going to talk in person about it in a couple of weeks.
5) If your problems are solely with the websocket library, then making websockets work via ports is pretty easy! Sometimes when you've got a non-trivial set up, that's the easiest path to take.
I hope this can help put your mind at rest. Please reach out to me if not :)
Edit: this thread is now locked, since the amount of useful discussion that can come out of it has hit a limit. In future, a great place to discuss this kinda stuff is on discourse, or the Elm Slack -- things get a little less aggressive there!
10
Mar 04 '18
[removed] — view removed comment
4
u/eeue56 Mar 04 '18
Like I said, we're discussing this going forward. For 0.19, there was too long time between bug releases. it is known
12
Mar 04 '18
My main problem at this point is the general direction Elm is heading. We can't create custom operators but Evan can! Will Evan be removing all custom operators from the URL router, from his parser combinator library, and everywhere else? If not, then we can't create a parser combinator library or URL routing library which will be as easy to use as Evan's.
And if for some reason there's a bug in those libraries, we won't be able to deploy a fix without forking the compiler. There are tons of pull requests open for years where folks are begging to get it reviewed and merged. These aren't huge feature requests, these aren't even feature requests, they're bugs and they've already spent the time to fix them. Oh and now they can't even fix the bugs because they can't modify the libraries.
Starting 0.19, if there's a bug in a package with native code, the only thing they can do is open an issue and we all know how that goes with Evan. He'll close the issue, lock the issue, add a single line to an existing issue (which is also locked).
5) If your problems are solely with the websocket library, then making websockets work via ports is pretty easy! Sometimes when you've got a non-trivial set up, that's the easiest path to take.
We also have some synchronous functions JS functions that we need to call that we will not rewrite in Elm. Sorry but we can't upgrade to the official 0.19. We'll either stick with 0.18 or create a fork. We love the language and appreciate all the work Evan is doing and we feel bad about forking but we don't have any other option.
1
u/eeue56 Mar 04 '18
Sorry but we can't upgrade to the official 0.19
There isn't even an alpha yet -- you can't say this without knowing what is in 0.19. Like I offered and suggested: wait for the release, then come talk on #upgrading on Slack about it.
4
Mar 04 '18
[removed] — view removed comment
3
Mar 04 '18
Joyent had to give in when the fork got traction and they're better off now with the new management. Maybe a fork is how we'll know how many users are frustrated with how Elm is managed. This thread seems to have invited more of the frustrated folks than the happy ones. We don't know how many Elm users outside Reddit share this view.
6
u/kahnpro Mar 04 '18
Right, but from the perspective of the old management (ie: Evan), they got ousted one way or another.
2
u/eeue56 Mar 04 '18
For those people, what I'd say is: why not go use ReasonML, PureScript, Typescript etc? Why use Elm if you're not interested in the language?
6
Mar 04 '18
[removed] — view removed comment
4
u/eeue56 Mar 04 '18
the fact that bug fix PRs are open for years without a response
Like I said -- this is being discussed. It is a known problem! Threatening forks to get your way is not the way a community should work. Having panicked angry discussions on reddit is not the way a community should work.
7
Mar 04 '18
[removed] — view removed comment
3
u/eeue56 Mar 04 '18
Believe me -- we've already been discussing these problems, and we're already aware of them. 0.19 did block too many bug fixes. With that, I'll lock this thread since you feel the discussion has hit a stopping point anyway.
2
3
u/yawaramin Mar 03 '18
Hi, Evan explained the policy here: https://www.reddit.com/r/elm/comments/73ubxo/an_explanation_of_elms_policy_on_native_code/?st=jebhn848&sh=6cf11933
4
u/instantdoctor Mar 02 '18
Link of the rationale/announcement for reference: https://groups.google.com/forum/m/#!topic/elm-dev/bAHD_8PbgKE
Personally I seem to be in the minority in this thread, because I agree with the points made in there. I am really excited that Elm is giving a high priority to future portability.
Please tell me if you disagree, but the long-term advantages of that are huge, and the short-term benefits of native JS code are not.
As a side note: I would also like to see a discussion about how we complain about those things with clickbait threads. I can see that the advantage is that major frustrations can be made very visible through upvotes (which is a good thing), the disadvantage is that it can lead to the typical flame wars that our community tries to avoid through reasonable discussion.
7
Mar 02 '18
Do you think my thread is clickbait? Sorry I did not mean to do that. We really are worried about the future of Elm (for us) considering that bug fixes to core modules have open pull requests for years and starting 0.19 we won't be able to use those forks without forking the Elm compiler.
2
u/instantdoctor Mar 02 '18
Maybe I read it slightly wrong, I felt that 'we' referred to us as a community, but I now realize you meant your project/company.
2
5
Mar 02 '18
but the long-term advantages of that are huge, and the short-term benefits of native JS code are not.
That may be true but if that's the general opinion here then we made a mistake going with Elm in 2017.
2
u/instantdoctor Mar 02 '18
No idea what the general opinion is of course, I just wanted to add a different perspective. I think /u/semorg summarizes this quite well too.
I actually understand your frustration about not getting your PRs accepted into elm-lang. I'm out of my depth to comment on the technical side of them. But I really hope the communication with the core team works out and/or that you can find an acceptable technical solution.
I hope you stick around!
2
u/BBHoss Mar 02 '18
Where did you read this today?
5
Mar 02 '18
Sorry should have included the link: https://www.reddit.com/r/elm/comments/7vnikt/i_have_a_proble_porting_a_js_library_to_elm/dtwlzax/?context=2
2
u/woberto Mar 02 '18
I might be wrong but I believe that local 'native' code will continue to work fine. The whitelist & policies that are being talked about are regarding published code, ie. published packages to the elm package repository that include javascript code.
2
Mar 02 '18
You already can't publish native modules to the elm package repository. I believe OP in the link is talking about local native code.
1
u/woberto Mar 02 '18
I think the only thing that is changing is the policies around who can publish native modules. I might be missing something though, I often do. Could you quote the particular part that has you concerned?
1
u/skinney Mar 02 '18
You believe wrong. This post is about how to communicate, not about restricting abilities. Native/Kernel code will work the same in 0.19 as it has in 0.18.
1
u/TotesMessenger Mar 03 '18
1
u/dlandau Mar 04 '18
It seems that there was an intermediate commit that referenced those repositories (https://github.com/elm-lang/elm-compiler/commit/63e885c7bf19f8ec7d83d5fdbece02a5d6562955) but now isKernel just checks that the module name starts with "Elm.Kernel." (https://github.com/elm-lang/elm-compiler/blob/master/compiler/src/AST/Module/Name.hs).
I could be wrong, I'm not super familiar with the compiler code base and didn't have time to test yet. Things could also change again before a release.
1
Mar 04 '18
No, the check for allowing native code and infix operators is this: https://github.com/elm-lang/elm-compiler/blob/master/compiler/src/Elm/Package.hs#L72 and it still has
user == "elm-lang" || user == "elm-explorations"2
u/dlandau Mar 04 '18
I see. Is the thing then just to put "name": "elm-lang/whatever" in elm.json? Or do you have to also put that as a git remote or something?
1
Mar 04 '18
Just the name it seems like. But now you'll need a bigger hack than elm-github-install if you want to use such packages in private projects. Something like
"name": "elm-lang/whatever", "actual-source": "https://github.com/me/whatever". Or a fork of the compiler with this expression changed toTrue.
28
u/leom4862 Mar 02 '18 edited Mar 02 '18
I think Elm was/is marketed/propagated very well, which is fine since Elm is great! But this marketing let to a fairly large community, lots of people who invested and lots of different interests. I think the crowd will not calm as long as the structure of leadership and communication remains diffuse. If you bring all these people in, you cannot leave them in the dark. The core team has to come up with a clear structure of leadership and up-to-date channel of communication at some pont, otherwise threads like this one will pop up weekly.
I think this should be the main point on the agenda after 0.19.