Wait, the restrictions aren’t verified on the server? You can just upload whatever you want as long as you send the proper HTTP request?
2 Likes
That’s really cool! as someone who is new to Elm and have seen people complain for as long as I’ve been in the community, I always wondered why that wasn’t a thing yet. This is OSS after all.
I think some checks have been added following the publishing of broken packages a few months ago by a forked compiler, but the point is to not try. Playing a cat and mouse game on this would waste some precious time better used on improving other more important things at the moment.
1 Like
Although on re-reflection, the whole point of the interface was to have a well defined, unsafe interface. So maybe instead of using the sync keyword, it should say unsafe. Since part of the reason for restricting the old native interface was to avoid letting users see compiled representations of Elm types, this interface would solve that at least.
In Rust, unsafe puts the responsibility of upholding the compiler invariants on the developer, and if you see things like crashes in your code, common wisdom says you should start by checking your unsafe code (if any), and many developers are happy to never use unsafe at all. I would be fine with having this unsafe port, where it’s clearly documented that the called JS function must be pure, or you risk seeing unexpected behavior (one way or another).
3 Likes
Alternatively, authors might mark some of the packages as platform-specific (i.e. non-portable). That way, when you start porting your app, the compiler just won’t compile the packages that are wrong platform.
But of course, your codebase might end up with a lot of native code, and the current Elm team’s stance on native code prevents that.
1 Like
I think that would be a really bad idea - the package system would end up fragmented.
For example, suppose somebody did add the easy-time package I described above. Maybe not such a problem, as the official compiler won’t build it, so to begin with maybe hardly anyone uses it. But then suppose it starts to become more widespread - more other packages use it as a transitive dependency. Then it starts to get to the point where its hard to avoid all this native code and non-pure functions that we never wanted in the first place. Eventually it gets to the point where we all have to switch over to the hacked compiler just to get anything done.
If it has not already been done, I really hope the package site gets patched so that it will not accept native code uploaded on the sly.
If people really want to fork the compiler, they should also be forced to fork the package eco-system too.
2 Likes
I’m not saying this is a terrific idea, and I’m sure I haven’t thought of all the possible downsides.
That said, I think the native/unsafe/platform-specific package attribute should propagate: no normal Elm package should be able to depend on those packages and not be considered unsafe too, same as a pure function cannot call an impure one (other than through dependency injection maybe).
But of course that would still give us some non-portable modules and by extension, less portable code bases etc. So it’s not that I’m advocating it, just saying it’s a possible middle-ground solution: allow native code but segregate it from the majority of the code your base should consist of.
1 Like
I find it interesting that Luke’s blog has this buried in the middle
One big factor in why I’m leaving the Elm community is that I messed up majorly in my interactions with the Elm core team.
At the beginning it wasn’t entirely my fault — I was all set to do a positive “Show and Tell” post on Elm Discourse, when the core devs announced a change that would really hurt my project (along with many other people’s). So my introduction instead turned into something a lot more confrontational, so I feel slightly a victim of bad timing, though of course I accept responsibility for my own words.
Since then I’ve not done a whole much better, although I have been trying.
There’s blame placed upon others, some blame placed upon themselves, but then the whole blog goes back to blaming others.
If your early interactions with another person are antagonistic, then odds are things won’t go well. How you heal that relationship is also partly your responsibility.
2 Likes
I also think it’s the core of the problem.
I just want to confirm what @dmy said earlier. If someone does a public fork they’d like to promote, please also do the following things:
- Call the project something else. Pine. OpenFP. Etc.
- Set up a separate package repo under the new name if you want “Pine” packages to work different. We hope to one day to not just be compiling packages before publication, but also running their tests and doing a range of builds to see if their package constraints work as advertised. Point is, trying to hack this will cause problems in the long run.
Since I do not think this dispute cannot be resolved within Elm, my hope is that you’d end up with a separate language to explore your vision for programming language design and governance (Like how Standard ML, OCaml, BuckleScript, and ReasonML all exist with different names, different technical artifacts, different development methodologies, and different communities, even though they come from a shared lineage.)
26 Likes
Sorry for nitpicking, but ReasonML compiles to OCaml AST (and back), and BuckleScript, while not the only OCaml/Reason compiler backend (quite a bit of native stuff is written in Reason already), is pretty much a part of the ReasonML project lately. SML is another thing, of course.
Then again, Reason so far is being a good example of the dangers of being too open. Not just the FFI (I find their JS interop pretty taxing mentally, and for all that, there’s not a whole lot of quality bindings), but there’s a divide in the community with regards to parameters order (pipe-first vs pipe-last), named vs positional, a lot of standard libraries, etc.
Of course, there’s a fine between bikeshedding and evolution, and ReasonML is pretty great in general, but for today, Elm feels like a better choice to actually build apps 
2 Likes
@hoichi, it sounds like something to discuss with @gigobyte or others who are interested in doing a fork.
To extend my comment above, using a new name for a fork is common outside of languages too. Linux distros, browsers, packages, etc. All I was saying above is that we’d really appreciate people interested in exploring alternate designs to use a different name for their project. From there, all the exciting design decisions are up to you. Right now maybe you just want one thing different, but maybe your users will want to add user-definable operators and user-definable type classes as well. Having a different name makes it easier to evolve as you express your particular design vision.
Like I said in 2016, having more languages makes each language community stronger and more fun. Just think it’s important to clearly label the languages.
22 Likes
@evancz I agree with your requests. And for the record, I am happy with Elm as it is and am not planning on forking anything.
But out of curiosity, isn’t there anything in the License terms that Elm is available under, that legally prohibits others from using the same name for their own fork?
Stuff like that usually is not covered by a license (and most licenses are not even proven to hold up in court). We usually ensure that with a trademark in other projects, that I’m part of. But that also means, that you have to act on possible trademark violations and can’t let them slide.
1 Like
Ah ok, didn’t know there’s a lot of additional action needed for that kind of stuff.
I think the reason that the two-class access to kernel code stings many people in elm particularly acutely is that Elm is both a language and the framework, and there are lots of places in the framework where ports absolutely could have been used.
Elm provides a wonderful alternative to very full-featured frameworks like react that have incredibly large ecosystems, whereas Elm sometimes requires use of ports just to access features of the underlying browser platform, not even third party libraries.
My memory of first using Javascript, way back in 1997 (technically I think it was Microsoft J-script) is that it was very, very limited, but we weren’t asking much of the browser platform in those days.
Today Javascript is incredibly versatile, particularly with the expansion of the web platform to cover so many aspects of human interaction with the computer: video conferencing, p2p networking, local storage, web workers for concurrency, etc. and browsers that lag behind others in implementing the most cutting edge of these features are routinely lambasted for it, including in this community. We hear how much Safari is holding back the web, just as IE once did. Isn’t that the same impulse as saying that Elm is not expanding its framework to cover the web api fast enough?
5 Likes
I see those as 2 different things. If I write my app in Elm, I can still access web sockets or Server Sent Events through ports even though Elm doesn’t natively support them.
If the user of my app only has access to IE as their browser because they’re on a work computer, then they will be limited and have no control over what features their browser can support.
I can totally sympathize with learning a new framework/language. My current employer uses Ruby and Ember and I’ve never used either before. After nearly 2 months I’m still trying to understand the basics of Ember. I know I could write the same features in React or Elm or even vanilla html/css/js much faster, but the team users Ember. That doesn’t make Ember bad or wrong. It’s all about learning something new.
2 Likes
I don’t see it as two different things. There definitely are things you can do with the web api that at a very minimum are difficult, if not impossible to do via, pretty much always involving dom node manipulation, the most prominent probably being use of “contenteditable”, which to be fair, doesn’t work well with virtual doms in any framework.
I don’t think there’s a great way to work with canvas or anything other than the basic aspects of the media api in elm currently.
Now that I think of it, though, the browser in those days did have a widely used native-ffi, and it sucked. For years we had access to plugins in browsers, and accomplished tasks like media playback and vector animation that way, and then it took us many years after the browser got those capabilities natively to get rid of those awful plugins.
1 Like
I think you are onto something with this - people are comparing Elm to JS frameworks and their expectations from that perspective don’t really match how Elm works.
For example, JS frameworks typically iterate fast (remember the “I’ve had milk that lasted longer than some JS frameworks” tweet). People look at elm/compiler and think the project is dead because it does not seem to be moving.
They fail to realize that Elm is well put together from a software engineering point of view - there is a clear separation of concerns with a lot of highly complex stuff in the compiler, a carefully designed runtime in the kernel code in the elm/* packages, and then the mass of community driven efforts in the package repository. I’ve looked at a bit of kernel code myself from time to time, I have never looked at the compiler code - I really do not need to know.
The compiler is evolving at a glacial pace, compared with JS frameworks. The runtime evolves at a very measured pace too - I get the impression that it really does take a good amount of time to make some careful API choices, let them loose upon the world, and then figure out what worked and what did not, make some adjustments and work towards a newer better version of Elm.
This slow pace makes people think - why is it not evolving faster? Why can the community not get involved, wrap some browser APIs or JS libs and add lots of whizzy features that everyone will love.
When people ask if Elm is dead, I now point them to the Slack #packages channel. That is where the action is, and it is all community lead. This is where Elm is evolving fast, and by and large it is managing to do so unhindered by the constraints that the lower layers of this software stack impose on it.
4 Likes
People seem to be going off on tangents (I am also to blame since I posted off-topic earlier 
). I wanted to share some of my opinions:
Why do people complain that only makers of the Elm language(Evan) can define operators when the same is true for JavaScript?
Because Elm is not comparable to JavaScript, as people already mentioned, Elm is comparable to React, Angular, Vue etc. It would be similar to Facebook releasing a React component that is not implementable by anyone else because there is a hardcoded part of the runtime that optimizes it.
Why do people not accept that Kernel code can only be written by Elm Makers(Evan) when in JS only makers can make calls to native© code(at least in Browser JS, excluding web assembly)?
Same as above, JS to Elm is vanilla JS to React, there is no problem with escaping the React runtime (in fact Dan Abramov has recommended it multiple times) / dropping down to a lower level while using React, unlike Elm.
I wonder if kernel code wasn’t part of the package that uses it, but centrally defined in the compiler if there were less discussion about how people want it in their packages too? Then it would seem more like a central kernel and less like a privileged package.
That would be fine for modules like Platform, Html, List etc but would be unacceptable (and it still is) for high-level packages like elm/parser and elm-explorations/markdown
2 Likes