Just wanted to drop in and say thank you for asking the question. I don’t do that level of promotion, but I certainly love the language and see its benefits, and I can see where you are coming from. Even in talks with my team and other devs they hesitate with exactly the same sorts of things, so I can only imagine it for people who you are asking to invest $$ into it.
I think all the suggestions I have read so far are great. Not sure which is the right direction, but any momentum I think would be a welcome sign – if nothing just to show all the uninitiated out there that its fully supported.
This all resonates very well with me. My main selling point for getting anyone to jump into Elm was as a springboard to learning pure FP - which it is great for by the way. Other than that people just seem to shrug it off as more effort than its worth and fail to see the payoffs. That has been my, minimal I admit, experience at least.
After 5 or 6 years, and the clear abandon of the current version of Elm by the manager(s?), I finally gave up on Elm. My last attempt was to fork the compiler to remove the limitation for JavaScript in local applications, but I got runtime errors even though the compiler is written in Haskell. I found too hard to work with it mainly because:
Lack of Haskell experience.
IDE integration of Haskell with IntelliJ is very limited.
There are a few uses of Map.! that break type safety, probably for performance, but debugging Haskell is hard.
Now, Typescript allows for strict types with good consistency, there are plenty of projects that make good use of typescript in the ecosystem, and the time where many developers wanted to learn Elm has past, so I am continuing my journey following a completely different path. Actually, I have more hope for roc than for Elm, because it seems to address important limitations of Elm.
Evan himself recommended using another language if you need confidence about the language:
I think having more flexibility in planning is a major competitive advantage for Elm, but obviously it is a trade off that does not work for everyone. If someone needs more certainty, I generally recommend looking into other languages to see if they have a balance that works better for their needs. For example, languages made by big corporations are generally “less risky” on things like this, but I think you see the fruits of that kind of process in the design decisions as well. Trade offs!
(from here, and that’s a small snippet of a large post; you should read the whole thing).
I put several months of nights/weekends learning Elm and eventually decided the complaints in this thread were dealbreakers to me (I still haven’t found a good alternative tbh), but, like it or not, this is how Elm works and it’s probably not going to change.
The thing that really helped me accept Elm’s “do the ‘right’ thing no matter the cost, no matter how long it takes, and Evan has to sign off or implement it” value was Bryan Cantrill’s PLATFORM AS A REFLECTION OF VALUES talk. It’s a great watch.
This reflection on Elm’s values makes me see Elm more as a hugely influential research language than a vendor-supported escape-hatched-if-you-need-it language I feel comfortable selling products on. This is just my personal opinion and I know a lot of people have their own opinion.
Any attempt to fork elm to provide such a production language should take a super careful look at Elm’s values to decide what tradeoffs should be made. I don’t believe it’s possible to add values like “contains escape hatches” (including through seemingly-unrelated things like an alternative package manager) without removing some level of commitment to Elm’s current “do the ‘right’ thing” value. To be clear, I personally think it would be great to have some experimentation in the space, but the tradeoffs are real and should be made intentionally.
For the people who are interested in just addressing low hanging fruit/open bugs, I still don’t think even this is happening. The discussion of batching and doing occasional updates seems like something that was happening a few years ago. Now, it just looks like a frozen repo that might get some amazing additions every few years but the routine maintenance of bugs in batching or whatever work pattern won’t happen.
If you’ve not checked it out have a look at PureScript. It’s somewhere between Haskell and Elm and it has a really good JavaScript FFI (no need to hack in anything - you can just have a .js file named the same as a PureScript module that implements stuff you marked with foreign in the PureScript module - simple, efficient, a dream compared to Ports - also easy to add local/github packages outside the main repository).
For your trouble with the fork: you might have an easier time using VS code and GHCup - usually this works out of the box just as good as what you are used with Elm.
The first thing that I wanted is to be able to track HTTP requests executed as tasks in order to cancel them if needed. But, specially, I wanted give the power to the developers to do what they need to do in their code. Future plans could have included more community focused goals, I see the Elm momentum too small nowadays in order to defend it at work. As I see it, limiting developer capabilities was a great a idea to get better pure Elm packages ASAP, but in the long run it has been a shot in the foot.
I guess the difficulty with cancelling HTTP requests, is that the request has likely already been sent to the server, in which case it will likely be replying anyway. So may as well just set your client side state machine to ignore the response. I guess if its a particularly large response, cancelling does make sense?
I am interested in reasons why people want to write their own kernel code to try and find solid genuine reasons that it is really needed. In just about every case I feel there is a workaround, although not always a simple one, sometimes it is a complete shift in how you think about solving a problem. Not to be rude, but in this particular case there seems to be a reasonable workaround, and also Http.cancel, so I don’t think it is justification enough to allow it…
…but I get what you are saying overall.
Only time I genuinely felt that I really needed a synchronous FFI was to make use of OpenType.js, because it was too much of a PITA to use it through ports, and also I needed the answer right away to render the view, rather than delay 1+ animation frames waiting for the update to call it through ports. The workarounds would be a) just use a port or b) rewrite OpenType.js into Elm.
b) Would be great overall for Elm , if only I had like 6 months free time to pull it off.
In the end I just call it using synchronous FFI by doing sneaky stuff with decoders, which will no doubt come back to bite me when that loop hole is closed off.
If third parties could publish packages with kernel code in them, I think it is highly likely that we would very quickly see the following non-functions:
-- Make Elm easier!! :-)
timeNow : () -> Posix
randomInt : () -> Int
So it is really a good thing that Elm as a platform prevents me as a user of that platform from being exposed to non-functional polution such as this.
A step down from packages, at the application level, if it were allowed I could still be exposed to this from other developers working on the same application. That seems less severe than at the package level, because at least they are my colleagues and we can argue about it locally without damaging the overall platform.
We already found an escape hatch for doing synchronous FFI via Decoders, and my feeling is that there always will be an escape hatch to find in hacky ways. Probably better at this stage to begin to allow it, with public and properly documented APIs, but in ways that keep the overall platform purely functional.
My proposal for adding third party kernel code to Elm is this:
The idea would be that a third party can create their own “domain tag”, and add some kernel code under that tag. Much of the time, this would only published to their own private package repository. But at some point we could consider opening things up to allow third party packages with kernel code to be shared. The idea of the tags is that you would have to explicitly opt in to using something.
So maybe someone does a great job of adding video stuff to Elm, and publishes it under org.elm-video - its high quality code, its purely functional, people like it and trust it, why wouldn’t we want to share it and use it? A lot of good work can be done by many authors, and Evan is no longer the bottle-neck.
On the other hand, someone hacks together org.elm-hacks, which has impure functions and runtime errors if you call things in the wrong order. It will never get a good reputation and should be avoided.
Perhaps there could even be an unsafe label, which curators of the package system could apply to things like that. But that gets into the area of centralised review, and needs an appeals system to ensure it works fairly, and so on.
It is not, because our requests are constructed as Tasks, not Cmds. and in tasks you cannot add the tracker string.
We already do this, but we were considering closing database connections in the server when a long request is canceled (user moves to another route or refreshes), which we could not achieve easily without the tracker.
I guess we all need to hack it somehow at some point
I see. At a guess, and without seeing your code, the workaround would seem to be to use HTTP Cmd API, instead of the Task one? If this assumption is correct, not having third party kernel code is not a blocker for your application, but merely an inconvenience. (And now you have to add more state and Msgs to your application to handle it).
I get it though, and it really doesn’t help when you are trying to sell Elm to your co-workers when things like this come up. Everyone just gets the sense that this is inconvenient and can’t be made better.
Ideally you, or one of your co-workers would make a PR against elm/http to add cancelTask, it would get reviewed and merged, and a new minor release of elm/http would come out with the enhanced API for cancelling tasks. This does not happen because:
We are blocked on Evan, and he does not work this way.
You probably don’t bother to make the PR in the first place, because you are discouraged by knowing about 1.
Just to be clear, being able to publish Native code under some secondary package list would mean being able to write Native code at all, right? I.e. in my own private/local project, something that right now is forbidden by the compiler unless you’re Evan.
In this case, what would be the benefit of a secondary package list at all? You could simply publish your horribly unsafe library on Github and let developers use it as a direct git dependency and be judges of its usefulness/ ratio. That’s how the original Elm-UI was published.
That path explicitly forbidden by the Native code ban because common Elm developers aren’t trusted to keep the language functional and clean. I’m not sure I understand how a different package repository would work around that.
Dunno if you read the whole thing (Eco - An Alternate Elm Package Server)? But the proposed package manager is not a free for all - it would still work off of a repository of published packages and would also take the existing packages from upstream at package.elm-lang.org. It would also NEVER publish to package.elm-lang.org, only to its own package realm.
So the benefit of the secondary list(s), wrt hypothetical native packages, are that:
a) Users must opt in to using them, by default they are not available.
b) We avoid polluting the existing package.elm-lang.org with third party kernel code.
c) The supply chain is clear on where things are coming from, and who owns that packaging domain. That is, the question of “who do you trust to write clean native code?” can be tackled by reputation of the author.
d) We get a nice website with package docs for all of it, you don’t need to go hunting around GitHub to find bits of kernel code. We still get semantic versioning and authors decide what is ready for publication and when.
I should also add, that kernel packages is not really an aim of Eco at the present time. Private packages, and mirroring and offline working are higher priorities, but its still interesting to consider the possibility of sharing third party kernel packages.
Yes, I understood that the proposal was not a free for all. My point was a separate package repository is not required for Kernel code experimentation, but I was focused too much on the Kernel code aspect - opposed to the actual goal you’ve clarified.
At this point however I’m curious as to why you mention a “hacked version of the compiler” if not to provide the possibility of Kernel code.
The current compiler is locked down to package.elm-lang.org, so to use an alternate package manager the compiler may need to be modified.
At the time I wrote that, I was not sure if I could just make a new packaging tool, have it download into ELM_HOME, but continue to use the official 0.19.1 compiler after that step. I now think I would certainly not do this because it may lead to packages that build only with stuff that is not in package.elm-lang.org available, but that could end up being published back to package.elm-lang.org, which would leave that in a broken state. (package.elm-lang.org trusts that your local elm make did a good enough job of verifying everything, it does not redo the build on the server side in a controller environment to check).
So even without unlocking kernel code, a new version of the compiler would be needed to make this Eco idea work. Naturally, this compiler fork would have its publish command disabled, so as to avoid interfering with the existing Elm infrastructure.
I actually would like to split elm into 2 separate tools:
eco which supports make, init, reactor, repl - and never needs to go online to work, its just a compiler.
eco-pack which supports install, bump, diff, publish and probably also update and uninstall.
But a reasonable starting point would be eco without publish, and able to download packages from a different URL.
