16 ms·

Elm 0.19 Broke Us

276 points by maxhallinan 8y ago

iamleppert 8y ago
I recently took on a contract to fix a busted elm project. There were no runtime exceptions but it was such a Frankenstein monster I couldn’t believe it. If you’re doing any real work on the web, you’re going to have to use external libraries and code and such. You’re not going to have time to recreate an entire mapping framework in Elm or whatever and the minute you need to commingle in such a way you loose a major benefit of such system. Also “no runtime exceptions” does not mean the application isn’t broken, does not absolve your developers from real testing and QA their changes. Also it says a lot when someone wants to call their framework a kernel and patterns their behavior off you know who.
- bgorman 8y ago
  In general, type checkers almost never catch any errors that wouldn't have been found extremely quickly in a strongly typed dynamic language.
  - star-techate 8y ago
    "Extremely quickly" -- if you can always take all sides of every branch in control flow. And you'll find only the same errors -- if you restrict the types you define to those supported by the dynamic language. If you don't restrict yourself, however, you can start catching classes of error at compile-time that in a dynamic language you could only look for by writing your own runtime checks. And runtime checks aren't free - they cost CPU, they can have their own bugs, and they can be tedious to write. "In general", rather than even try to be as careful in a dynamic language as you could be with an advanced type system, you'll just settle for not being careful.
  - skybrian 8y ago
    Having worked in a large codebase to fix type errors in an evolving language, this is not true. There are plenty of errors. What is true is that the errors you catch are most often benign and not obvious, user-visible bugs, for one reason or another. (If they were obvious, they would have been fixed sooner.) The code might be abandoned or rarely executed, or it's never called with that argument. Something like that. Occasionally you do find a serious error, though.
  - amelius 8y ago
    Type checkers can be of great help when refactoring, though.
k__ 8y ago
Sounds like reasonable removes to me, custom operators are a pain.
- vmchale 8y ago
  > Sounds like reasonable removes to me, custom operators are a pain. Not the point. The point is that it breaks backwards compatibility for the arbitrary prejudices of the Supreme Leader.
detaro 8y ago
The reddit discussion for this post is a telling confirmation of the articles complaints about the community forums/interaction: https://www.reddit.com/r/elm/comments/9a0hc6/elm_019_broke_us/ https://www.reddit.com/r/elm/comments/9a0hc6/elm_019_broke_u...
- kragniz 8y ago
  To see the deleted comments: https://www.ceddit.com/r/elm/comments/9a0hc6/elm_019_broke_us/ https://www.ceddit.com/r/elm/comments/9a0hc6/elm_019_broke_u...
  - lugg 8y ago
    Haven't really been paying any attention to elm, all I can say now is that I never will.
    - MBCook 8y ago
      I have, I thought it’s philosophy was pretty neat and I love the idea of being able to use something like Haskell in JavaScript land. I’ve seen complaints about how slow it moves and the fact that there is effectively one developer has certainly worried me. I never made a serious try to get it into production. It’s now very clear to me there’s no point in EVER trying unless there’s a massive shift in the project. The community/leadership sounds very broken. This seems more like what I would expect from someone’s hobby project that got out of hand and accidentally got a bunch of people who follow along no questions asked.
      - lallysingh 8y ago
        Reflex-FRP is finally getting documented and usable. I looked at ELM and decided that I could wait for reflex.
      - vmchale 8y ago
        > This seems more like what I would expect from someone’s hobby project that got out of hand and accidentally got a bunch of people who follow along no questions asked. It does, but then you realize he actually advocates using it in production and tries aggressively to grow the community. See e.g. http://elm-lang.org/blog/how-to-use-elm-at-work http://elm-lang.org/blog/how-to-use-elm-at-work
willtim 8y ago
Custom operators make code more readable when used appropriately; and any aspiring general purpose language that refuses to support them is cutting off the nose to spite the face.
- zaphar 8y ago
  Any language with a large userbase has a large group of people who don't use them appropriately. The result is a majority of code that is unreadable. Any language that depends on people to just "don't do that" is a language that will be full of people who do exactly that.
  - willtim 8y ago
    This is a social problem, it can be solved without such a blunt instrument. Single letter variable names also make code more readable, but only when used appropriately. Your argument would suggest banning those! IMHO it is better to concentrate on getting the semantics right and not waste any goodwill on restricting syntax.
    - zaphar 8y ago
      Yes it is a social problem. But I disagree that you can solve the social problem without very opinionated and restrictive syntax and semantics.
      - willtim 8y ago
        I respect your position, which was shared by the designers of Java and Go, but any language I choose to use is one that seeks to empower me. For example, the purity restriction in Haskell exists to ultimately empower me, not because the language designers have contempt for my abilities.
        zaphar 8y ago
        I also respect yours. This is why there are multiple options in the PL arena for people to choose.
tbenst 8y ago
I looked at Elm a couple years back and decided on Purescript instead: http://www.purescript.org/ http://www.purescript.org/ Has a much better FFI story with JavaScript than Elm, and has a more powerful type system (higher kinder types, etc). Row polymorphism makes writing pure code a joy, the effects system is unobtrusive. I actually enjoy programming purescript more than Haskell.
- arianvanp 8y ago
  https://github.com/slamdata/purescript-halogen https://github.com/slamdata/purescript-halogen is a very nice frontend library with local state per component, such that not the entire vdom needs to be diffed. However, if you want an easy migration path, there is https://github.com/pselm/core https://github.com/pselm/core Which is a drop-in replacement of the Elm 0.18 API in purescript. You can almost directly copy your elm code to it and it will work with minor changes
  - dan-robertson 8y ago
    I recall looking at halogen a while ago (maybe a year?) and I didn’t really get where it was going. The goal is to do ui in a functional language and you chooses a functional language for various reasons. But then the halogen components are essentially reimplementing object orientation in purescript (so everything looks weird, there isn’t special syntax for common things, and the types are bizarre): Components are these things that have a way to initialise themselves, an internal state, a way to receive messages and update their internal state, a way to compute from the internal state (ie rendering), and a way to reply to messages that are querying things (by having the message pass a callback for the reply as an argument). The only thing they have which is missing from standard oo is a way to pass up messages to their parent component. After all that one must wonder what the point of using purescript for this is and why not just use a more object-oriented language fron the start?
  - mbo 8y ago
    That `core` `README` is really good! It's convinced me to look more into PureScript. Thank-you!
  - 8y ago
dsiegel2275 8y ago
I would have liked to have seen custom operators stay around in 19, but I understand the motivations. I think it was in 18 they removed back-ticks for the same reason. Just makes it way easier for newcomers to learn the language. As far as I understand it, the native modules lockdown had to take place. Period. The one thing that most attracts myself (and many others, I'm sure) to Elm is the guarantees that the compiler gives you towards ensuring no run-time errors. Give folks the ability to author and publish Elm native modules and the entire platform loses that guarantee.
- jarcane 8y ago
  Not only that, it was a completely undocumented hack in the first place that it was repeatedly communicated shouldn't be used. And I really don't see how JSON parsing is a task that actually needed hacks to work short of massive GB dumps or something. I am sometimes frustrated by the way Elm is almost more a DSL for web apps than a complete language, but I also don't see anything wrong with closing an unsafe API in a language that's specifically about type safety. It seems like complaining that Haskell doesn't give you instructed ASM blocks.
  - owl57 8y ago
    It seems like complaining that Haskell doesn't give you instructed ASM blocks. Well, Haskell doesn't give them out of the box, but it allows implementing and distributing all sorts of crazy unsafe stuff in libraries, including exactly this sort: http://hackage.haskell.org/package/inline-c-0.6.1.0/docs/Language-C-Inline.html http://hackage.haskell.org/package/inline-c-0.6.1.0/docs/Lan...
- berns 8y ago
  > Give folks the ability to author and publish Elm native modules and the entire platform loses that guarantee. Note that you can't even compile native modules for your private modules.
- endgame 8y ago
  I don't. If you ban custom operators, how can you find out future use cases where custom operators make a lot of sense? I am extremely distrustful of a language where certain people are more equal than others. Those elevated people could be blessed library authors, or within the core implementation or whatever, but I hate not being trusted to use my tools properly.
the_duke 8y ago
I only briefly dabbled in Elm and I'm not terribly qualified to comment on specifics, but I had a similar, negative impression of the way the project is managed. Especially in comparison to many other open source projects.
dcu 8y ago
These kind of stories make me value Go's approach a lot more. You just have to worry about making your product better.
- tree_of_item 8y ago
  Go's approach? Go has the same extreme BDFL approach to ignoring community feedback in favor of the leader's vision. I don't see what is different about Go.
  - hellofunk 8y ago
    Common with many languages, actually.
    - star-techate 8y ago
      That has its downsides, but if the people maintaining the language are too lacking in strong opinions about the language, you'll have other kinds of problems: bad features get into the language and now everyone must be prepared to deal with errant use of those features in the wild; there are too many too similar ways to do the same thing, so the language becomes hard to learn and teach; there are features you never normally use, so you're terribly confused when you accidentally invoke them (suppose you have `val` and `var` as two ways to bind variables, but everyone only uses `val` because `var` has some weird extra semantics.)
      - ModernMech 8y ago
        Basically, you get C++. This is what I love about programming languages; it's a true marketplace of ideas. There's something out there for everyone, and a project of every flavor. You see this happen all the time with languages projects, especially opinionated ones, where someone likes the general vibe of the language, but wishes it were more like something they are more comfortable with. But sometimes a language just wants to be where it is, especially when it's run by one ego. Programming languages can be very personal things for their authors, much like a novel is for writers.
the_mitsuhiko 8y ago
I think Elm can learn a lot from Rust before 1.0 here. Rust made some "insane" decisions that should have pissed off the community but did not mostly because of the way the communication was handled. There were obviously some disagreements along the way which caused some valuable community members to jump ship, but overall it was really well handled and the language became better as a result.
- Certhas 8y ago
  Seeing these type of processes playing out over the years just impresses on me how exceptionally well done the Rust process was. The atmosphere and attitude of the community was always excellent. For newbs/outsiders looking in, I think a lot of it has to do with a culture of validating people's experiences. That's difficult. If a user complains about it, the natural reaction can easily be to go defensive ("You're doing it wrong" or "we documented that here"). Rust has successfully fostered a culture of approaching it as an opportunity to learn something ("Why did you not see the documentation").
- MBCook 8y ago
  I’m not familiar with the history of rust. Could you give some examples?
  - the_mitsuhiko 8y ago
    Things that people were super excited about that got nuked: typestate, green threads, garbage collection support, tail recursion call syntax. But also small things (ternary operator was removed, a ton of keywords were changed and more).
    - MBCook 8y ago
      Thanks. Makes sense. I can seen wanting some of those myself, but I get you have to draw the line somewhere if you’re ever going to be ‘done’ with the initial/beta releases.
- bjz_ 8y ago
gonyea 8y ago
And this is why I love TypeScript: It's just JavaScript, with a type system. If it's not in the standard then it's not in TypeScript (by default). There's no risk to adoption.
- Tehnix 8y ago
  Typescript certainly is nicer than plain JavaScript, but it doesn’t come anywhere near Elm (or PureScript or GHCJS). It really is a world of difference (edit: in type safety, that is). The reason for that is simply that TypeScript has to fit in with JavaScript, while the others do not.
  - gonyea 8y ago
    I mean, Dart offers this. The difference between Dart and the other strongly typed options is that a massive pile of funding (and production apps) drive Dart and its direction. So it’s quite stable, if a little too risk averse. That said, I’ve never found Strong Typing to be that essential for front end dev. TypeScript is incredibly pragmatic, which is why it’s been so successful imo. Nothing stops people from writing all their dependencies in TypeScript. But it’s not necessary to use it successfully.
    - Tehnix 8y ago
      What is the “this” that Dart also offers? With the languages I specifically called out, a LARGE part of them is purity, and not providing the type system escape hatches that TypeScript/Flow does, to maintain easier gradually switching a codebase. A nice thing at first, but nothing gained for new projects.
      - gonyea 8y ago
        this = a sound/strong type system: https://www.dartlang.org/guides/language/sound-dart https://www.dartlang.org/guides/language/sound-dart
erokar 8y ago
I'm torn about this. I'm rooting for Elm and I think it currently might be the best frontend solution. I really like Evan's focus on developer UX and simplicity. This means removing things, making the language smaller and simpler. And to do that you need to maintain a certain amount of control. However this seems to have backfired. Too many in the community want this or that and/or don't feel their opinion is heard. Then they switch to something else. Unfortunatley I think something like ReasonML will win in the end. JS interoperability and just enough Algol syntax to staisfy the masses. Evan is between a rock and a hard place here and it's due to the current sentiment in frontend dev.
- jnbiche 8y ago
  > Too many in the community want this or that and/or don't feel their opinion is heard. Then they switch to something else. Unfortunatley I think something like ReasonML will win in the end. That's not the only reason ReasonML will win. The BuckleScript JS compiler generates fantastic JavaScript, with no huge extra runtime at all. Also, ReasonML benefits from all the stability of OCaml's type checker. And, as you suggest, both ReasonML and BuckleScript are in my experience a much friendlier and open community to experienced devs and commercial users.
  - sdnguyen90 8y ago
    The runtime is not that big with 0.19 in my experience. I rewrote a (P)react component that was 5kb and Elm came out to be 6.8kb. If you're comparing it to ReasonReact, you still have the React/ReactDOM Javascript dependency which is still ~30kb gzipped
    - bjz_ 8y ago
      Kind of curious if anyone's played around with using incr_dom with Reason: - https://github.com/janestreet/incr_dom/ https://github.com/janestreet/incr_dom/ - https://www.youtube.com/watch?v=h_e5pPKI0K4 https://www.youtube.com/watch?v=h_e5pPKI0K4 Seems like it might be tied to js_of_ocaml though...
    - 8y ago
Libbum 8y ago
Whilst I get the point about the community leadership being more autocratic than others, the Elm language itself has always been opinionated - thus it's difficult to empathise with the rest of the sentiment of this post. An 0.x release, two years in the making, drops two features such that it can further fulfil its design goals and everything is ruined?
robert-wallis 8y ago
One of Elm’s main focuses is code that is not possible to crash. Once I groked that, native modules going away in favor of ports made much more sense.
- _asummers 8y ago
  Maybe it's my recent living in the Erlang/Elixir community, but writing code that is not possible to crash doesn't make sense to me. Servers die, machines get unplugged, network partitions happen, etc. I don't discount that the type system allows you to specify segments of your program that can be provably impossible to crash, but doing that for entire nontrivial programs seems like an impossible ask to me.
  - erulabs 8y ago
    I could not agree more - and in fact, have no recourse when a developer tells me with a straight face that their code "cannot crash". The worlds best type system doesn't prevent timeouts, running out of disk space, memory, etc. The attitude I typically receive when trying to push pragmatism instead of idealism is usually a "you just don't understand". Throwing an exception is _not_ the worst thing a program can do, by a hell of a long shot!
    - Skinney 8y ago
      «Cannot crash» != «cannot fail». There are a bunch of things in Elm that can fail, but the language forces you, «through types», to deal with those situations. That doesn’t mean developers make apps that deal with errors reasonably, but the developers should be aware of every part of the application that can fail. Exception, of course, beeing stavk overflows as we haven’t solved the halting problem yet.
  - Fiadliel 8y ago
    The general aim of error handling in languages like Elm is for types to not lie. If you can either return a result, or an error, the type represents that. The more places that can return an error: the more complex the types, and the more complicated the error handling. You can always pass the error value up through layers, but as people would say, it's just easier to make illegal states unrepresentable. It's not an aim to pretend that failures don't happen, especially when doing remote calls, and the types will be transparent in showing where this occurs.
Tehnix 8y ago
I think there’s a very weird mismatch between the way the core language people are pushing for the adoption of the language, and then at the same time they will turn around and say “we’ll, it’s not even 1.0, yet, so what’d you expect”. The way Elm is developed is fit for a language that has little to no users, and can take going so long between updates, that remove escape hatches needed to fill out the immaturity of the language. It really saddens me to see it go like this, because I once had high hopes for Elm. Nowadays I see it purely as a stepping-stone into more advanced languages like PureScript and Haskell. Elm is there to hold your hand, but it seems it has no intention of ever taking you further than the basics.
- dsiegel2275 8y ago
  > remove escape hatches needed to fill out the immaturity of the language I think you mean "immaturity of the platform". Also, native modules weren't the only "escape hatch". An Elm application can communicate with JS through ports.
  - k__ 8y ago
    Complicated interop with JS also broke Darts back.
    - pjmlp 8y ago
      Politics broke Dart's back.
      - k__ 8y ago
        Sure, the bad JS interop had to come from somewhere.
  - AlexCoventry 8y ago
    What was the capability of native modules which enabled the dev.to essayist to use them, where ports would have been unreasonable ("there is no other reasonable way to do what I need")?
brokencode 8y ago
I agree that community management and handling of issues could be better in Elm, but I’m willing to overlook that due to the terrific quality and innovation of the end result. Elm has benefited greatly from vision and the willingness to take risks, which is much easier to do with less communication overhead and fewer contributors. Maybe someday Elm will adopt a more community-oriented approach, but I don’t think that is necessary right now.
- dsiegel2275 8y ago
  If I could upvote this more than once, I would. Spot on.
tigershark 8y ago
I really enjoy the fable-elmish philosophy, I think that the community is great compared to what the author of this post experienced, but..BUT, the platform on the whole is just too immature. I remember trying to compile jquery using the otherwise great ts2fable.. and it was, and probably still is, pretty much impossible. Or trying to use fable-elmish and getting “undefined behaviour” in a “hello world” test page. Luckily I discovered pretty soon these limitations, but I think that when a platform is not battle tested by millions of people you’ll always get this kind of grief. So just test if elm or fable-elmish or whatever framework work well for you before committing head first into it..
kaffee 8y ago
For those of us who desperately want to put javascript (the entire language) behind us, many of the "problems" this article mentions are features. Refusing, on principle, to be inter-operable with unchecked javascript code is a defining virtue of Elm. edit: grammar
- vmchale 8y ago
  > For those of us who desperately want to put javascript (the entire language) behind us, many of the "problems" this article mentions are features. Yes, not having FFI is a feature. Brilliant.
didibus 8y ago
I've heard of a few people discontent with Elm for the reasons mentioned in the article make a very successful jump to ClojureScript and being much happier about it. It offers an MVU framework: re-frame. There are others too. Its community is very friendly and helpful, it loves to discuss the language itself. No one seems to think of themselves as more knowing. It has never ever broken backward compatibility. It's a core tenet of the language to never break anyone ever. Finally, it has very good interop with JavaScript. And its getting better and better every release. It's also ran by a BDFL, actually more like two. Rich Hickey as the BDFL of the standard language design, and David Nolen as current implementer and main maintainer of ClojureScript. But they're loved and admired. And if you disagree with their direction, you're free to add your own features as a macro, that's why they made the language a Lisp. The language design prioritizes pragmatism. All discussion starts with: What exact problem are you facing for which there are no simple way to solve. And working backwards from real problems, solutions are added and new constructs are built. The only thing is, it comes from a different school of thought opposite to strong static types. But it shares a lot in common, emphasis on pure functional code, immutability of variable and values. No OOP, everything is a function with support for higher order functions, closures and partial application. And the same focus on interactive live development. If you don't mind losing the strong static types, I highly recommend giving it a try. You'll only miss the nice Elm error messages.
- KingMob 8y ago
  Good suggestion! Just to clarify one point, though, Clojure/Script does support OOP, with protocols/records/types, it's just not the first thing we suggest people reach for in the language. As a community, we're much more likely to use boring maps/vectors/functions first, and switch to OOP when we really need type-based polymorphism, or extreme performance. One consequence of not forcing everything to be OOP (like, e.g., Java) is an honest evaluation of where it makes sense, and where it adds nothing but complexity.
  - didibus 8y ago
    Well, I don't want to get into a semantics debate, but I can't help myself :p. And I'm pretty sure Rich Hickey himself would disagree with you about Clojure/Script having OOP. Protocols, records and types are not instances of OOP in my book. Polymorphism and abstract data types are concepts orthogonal to OOP and FP. The fact Clojure/Script has support for polymorphism and ADT does not mean it supports OOP. If you want to claim it supports OOP, I'd say it does in the form of interop. Genclass, proxy, or defining classes in Java or objects in JavaScript and using them from Clojure/Script. But, what is OOP exactly? We can debate this. I like to use Wikipedia's definition that it is languages where there is a construct, called an object, which groups together data fields and methods which can access and modify the data fields within. Clojure/Script has no such construct. But one can define them in Java or JavaScript, and use them from Clojure/Script through interop.
noncoml 8y ago
I was experimenting with Elm around .14 or .15 if I remember correctly. At the moment the language allowed you to use prime(‘) to name variables, and that was the suggested way if I had to guess by the tutorials and examples. During next release they decided that primes as part of a name were not their cup of tea and removed it. Just like that. When I asked why was prime no longer allowed, since I couldn’t see any good reason behind it, I got the usual: “it’s pre-1 release you should expect things to change, etc.” What left a bitter taste in my mouth was that this change had nothing to do with the language itself. It seemed as if they decided that using prime is not good style, so they forbid it. I haven’t touched Elm since.
- kjeetgill 8y ago
  I think rust went through a huge amount of simmilar changes pre-1.0. I think everyone was better for it. I appreciate they're taking their time to get it right pre-1.0. 1.0 is a fairly solemn promise and I respect them for not taking it lightly.
  - noncoml 8y ago
    That’s exactly the kind of answers I got instead of giving me one good engineering reason on why primes were made forbidden just like this. Thanks for the demonstration.
    - star-techate 8y ago
      The actual reason is probably "when people use primes, they post code that gets syntax-highlighted by tools that don't know about primes, and this results in Elm code looking broken and stupid."
      - noncoml 8y ago
        Which is not a good reason to ban them completely from one release to the next. It only shows that they don’t really care about their users that much.
  - 8y ago
protomikron 8y ago
In the end I think it's a good thing to be strict in language design and openly reject many ideas and suggestions. I guess it's a case of "too many cooks spoil the broth". Most languages have too many features anyway so removing them can be a positive thing.
- vmchale 8y ago
  > Most languages have too many features anyway so removing them can be a positive thing. This is completely unsubstantiated.
fouc 8y ago
I just wanted to let you know that a possible alternative functional MVU is Mithril/Meiosis http://mithril.js.org http://mithril.js.org - vdom lib - for the V http://meiosis.js.org http://meiosis.js.org - state pattern in conjunction with streams to give you the M/U Check out the gitter chatrooms, the communities for both are very FP oriented, and working on making it easier to do FP all the time. this guy came from elm: https://github.com/pakx/the-mithril-diaries/wiki/Coming-From-Elm https://github.com/pakx/the-mithril-diaries/wiki/Coming-From...
mst 8y ago
Can somebody take pity on me and explain why the ports system that's supposed to be used for JS integration can't replace the native modules?
- Tehnix 8y ago
  As far as I know, ports are strictly asynchronous, compared to native code, which can be synchronous. This means that if you are using native code for something that is 100% synchronous, you now have to go through a huge hassle of every calling site becoming async.
purplezooey 8y ago
had to realize for a sec that they weren't talking about the mail client
h4b4n3r0 8y ago
And that, in short, is why I prefer really freakin' old languages for doing real work.
always_good 8y ago
Article aside, the HN and Reddit comments really reflect our toxic entitlement culture. How many comments here seem to exist for no other reason but to get in a negative jab of their own? I'm reminded of Rich Hickey's great response (https://www.reddit.com/r/Clojure/comments/73yznc/on_whose_authority/do1olag/ https://www.reddit.com/r/Clojure/comments/73yznc/on_whose_au...) to a similar situation.
pjmlp 8y ago
Another proof that sticking with platform languages is a better option for productivity, even if the languages might miss a few shinny features.
- yakshaving_jgt 8y ago
  Yeah, productivity. Because spending 10 minutes writing asynchronous FFI code is definitely worse than spending a couple of hours debugging a runtime failure.
  - pjmlp 8y ago
    It is always funny when people compare external languages to platform ones, but keep forgetting to include tooling, libraries and eco-system when comparing them, reducing it to grammar and semantics.
  - vmchale 8y ago
    > Because spending 10 minutes writing asynchronous FFI code is definitely worse than spending a couple of hours debugging a runtime failure. Or... more than 10 minutes, because you have to re-implement a library that was already written.
msangi 8y ago
I would be totally on board with these changes if an alternative way of doing things had been offered. From the philosophical point of view they are exactly what is needed to allow Elm give as much guarantees as possible. The sad reality is that very little pragmatism went into this release and now stuff like web-sockets won't work [1]. This is very surprising because web-sockets are an use case where the Elm-architecture really shines. Things like this reinforces my idea that while Elm is a very nice language I wouldn't want to have it in production, or even in a side project, at least till it reaches 1.0 and becomes more stable. [1] https://github.com/elm-lang/websocket/issues/27 https://github.com/elm-lang/websocket/issues/27
- lozenge 8y ago
  Not only it doesn't work in 0.19, but the README doesn't mention it, the issue is closed (making it difficult to find) and the Elm release notes/upgrade notes don't mention it.
- yakshaving_jgt 8y ago
  Why can't this be done with ports?
  - msangi 8y ago
    I'm not sure. I haven't looked into the issue much. In any case, I would expect web-sockets to work out out the box in a language that is specifically designed to run in the browser. If that's not working I'm sure that less common parts of the web platform aren't supported either. Normally I wouldn't care and implement stuff myself and contribute back, but it doesn't seem to be a realistic option in Elm. I appreciate that what's there is generally of very high quality, but I cannot pretend that there aren't many missing pieces and, more importantly, no clear roadmap
- vmchale 8y ago
  > From the philosophical point of view they are exactly what is needed to allow Elm give as much guarantees as possible. Pretty much every language falls apart when it comes to FFI. In Haskell, a foreign function `Int -> Int` can print to the terminal. That's just the way it goes.
jlengrand 8y ago
I love Elm. Discovered it last year and loved the language so much that I went on a conference later in the year on my own budget. I love how low the cognitive load of adding features is. Having a small baby, it helps a lot. That being said, some things really confuse me, and especially the way the governance model is accepted and cherished. We have a `almighty god` deciding what will and not be done, the accepted reason being that it's not 1.0 yet. I mean, with 0.19 coming out, all IDE support went out the window and the answer from the author of the language is basically : 'changes are known since last May, things should have been done already. I don't even know what the status is'. Communication is at the minimum lacking tact. Others could say straight offensive for not-core users. I understand PR is hard and not fun. But then find someone to do it for you, or act as to minimize it. At the moment, the advantages of elm far outweight the issues for my personal use. But I really wonder about the long run, but I'm really afraid someone gets really pissed and forks the language in the long run, fragmenting and ending up destroying this great community. That would really be a waste.
- yakshaving_jgt 8y ago
  Are you paying to use Elm? What's stopping you from sticking to 0.18? What's stopping you from building your own 0.19 IDE support?
  - jlengrand 8y ago
    This is 100% what i mean. This exact way of thinking is what imho might well prevent Elm to strive as much as it could. And btw, I am (modestly) involved in the IDE support. So do check before being cynical <3.
    - yakshaving_jgt 8y ago
      My exact way of thinking is that you are not entitled to anything, and neither am I. I run businesses on Elm. I use it because it's the alternative that makes the most business sense (most confidence that I can release things without them breaking, and least chance of failure at runtime). I make money with this tool, and I don't pay to use this tool. If a better tool came along, I'd use the better tool. So far, Elm is the best alternative in my opinion. Everyone has this freedom to pick and choose their tools. And what does it mean to strive? Scala was a striving language. And? It's garbage. It tried to be all things to all people, and ended up being an awful tool. I find it absolutely amazing that so many petulant children in this thread believe they are facing some kind of authoritarian oppression because the language designer said "You know what? Synchronous FFI has almost only been a bad thing. All FFI should be synchronous from now on."
knorker 8y ago
This was confusing to read if you only knew about the email client Elm. In general I wish people spent more time naming things better, and reducing naming clashes.
hellofunk 8y ago
Wow: https://news.ycombinator.com/item?id=17843149 https://news.ycombinator.com/item?id=17843149

276 points by maxhallinan 8y ago

I recently took on a contract to fix a busted elm project. There were no runtime exceptions but it was such a Frankenstein monster I couldn’t believe it. If you’re doing any real work on the web, you’re going to have to use external libraries and code and such. You’re not going to have time to recreate an entire mapping framework in Elm or whatever and the minute you need to commingle in such a way you loose a major benefit of such system. Also “no runtime exceptions” does not mean the application isn’t broken, does not absolve your developers from real testing and QA their changes. Also it says a lot when someone wants to call their framework a kernel and patterns their behavior off you know who.

bgorman 8y ago
In general, type checkers almost never catch any errors that wouldn't have been found extremely quickly in a strongly typed dynamic language.
- star-techate 8y ago
  "Extremely quickly" -- if you can always take all sides of every branch in control flow. And you'll find only the same errors -- if you restrict the types you define to those supported by the dynamic language. If you don't restrict yourself, however, you can start catching classes of error at compile-time that in a dynamic language you could only look for by writing your own runtime checks. And runtime checks aren't free - they cost CPU, they can have their own bugs, and they can be tedious to write. "In general", rather than even try to be as careful in a dynamic language as you could be with an advanced type system, you'll just settle for not being careful.
- skybrian 8y ago
  Having worked in a large codebase to fix type errors in an evolving language, this is not true. There are plenty of errors. What is true is that the errors you catch are most often benign and not obvious, user-visible bugs, for one reason or another. (If they were obvious, they would have been fixed sooner.) The code might be abandoned or rarely executed, or it's never called with that argument. Something like that. Occasionally you do find a serious error, though.
- amelius 8y ago
  Type checkers can be of great help when refactoring, though.

k__ 8y ago

Sounds like reasonable removes to me, custom operators are a pain.

vmchale 8y ago
> Sounds like reasonable removes to me, custom operators are a pain. Not the point. The point is that it breaks backwards compatibility for the arbitrary prejudices of the Supreme Leader.

detaro 8y ago

The reddit discussion for this post is a telling confirmation of the articles complaints about the community forums/interaction: https://www.reddit.com/r/elm/comments/9a0hc6/elm_019_broke_us/ https://www.reddit.com/r/elm/comments/9a0hc6/elm_019_broke_u...

kragniz 8y ago
To see the deleted comments: https://www.ceddit.com/r/elm/comments/9a0hc6/elm_019_broke_us/ https://www.ceddit.com/r/elm/comments/9a0hc6/elm_019_broke_u...
- lugg 8y ago
  Haven't really been paying any attention to elm, all I can say now is that I never will.
  - MBCook 8y ago
    I have, I thought it’s philosophy was pretty neat and I love the idea of being able to use something like Haskell in JavaScript land. I’ve seen complaints about how slow it moves and the fact that there is effectively one developer has certainly worried me. I never made a serious try to get it into production. It’s now very clear to me there’s no point in EVER trying unless there’s a massive shift in the project. The community/leadership sounds very broken. This seems more like what I would expect from someone’s hobby project that got out of hand and accidentally got a bunch of people who follow along no questions asked.
    - lallysingh 8y ago
      Reflex-FRP is finally getting documented and usable. I looked at ELM and decided that I could wait for reflex.
    - vmchale 8y ago
      > This seems more like what I would expect from someone’s hobby project that got out of hand and accidentally got a bunch of people who follow along no questions asked. It does, but then you realize he actually advocates using it in production and tries aggressively to grow the community. See e.g. http://elm-lang.org/blog/how-to-use-elm-at-work http://elm-lang.org/blog/how-to-use-elm-at-work

willtim 8y ago

Custom operators make code more readable when used appropriately; and any aspiring general purpose language that refuses to support them is cutting off the nose to spite the face.

zaphar 8y ago
Any language with a large userbase has a large group of people who don't use them appropriately. The result is a majority of code that is unreadable. Any language that depends on people to just "don't do that" is a language that will be full of people who do exactly that.
- willtim 8y ago
  This is a social problem, it can be solved without such a blunt instrument. Single letter variable names also make code more readable, but only when used appropriately. Your argument would suggest banning those! IMHO it is better to concentrate on getting the semantics right and not waste any goodwill on restricting syntax.
  - zaphar 8y ago
    Yes it is a social problem. But I disagree that you can solve the social problem without very opinionated and restrictive syntax and semantics.
    - willtim 8y ago
      I respect your position, which was shared by the designers of Java and Go, but any language I choose to use is one that seeks to empower me. For example, the purity restriction in Haskell exists to ultimately empower me, not because the language designers have contempt for my abilities.
      - zaphar 8y ago
        I also respect yours. This is why there are multiple options in the PL arena for people to choose.

tbenst 8y ago

I looked at Elm a couple years back and decided on Purescript instead: http://www.purescript.org/ http://www.purescript.org/ Has a much better FFI story with JavaScript than Elm, and has a more powerful type system (higher kinder types, etc). Row polymorphism makes writing pure code a joy, the effects system is unobtrusive. I actually enjoy programming purescript more than Haskell.

arianvanp 8y ago
https://github.com/slamdata/purescript-halogen https://github.com/slamdata/purescript-halogen is a very nice frontend library with local state per component, such that not the entire vdom needs to be diffed. However, if you want an easy migration path, there is https://github.com/pselm/core https://github.com/pselm/core Which is a drop-in replacement of the Elm 0.18 API in purescript. You can almost directly copy your elm code to it and it will work with minor changes
- dan-robertson 8y ago
  I recall looking at halogen a while ago (maybe a year?) and I didn’t really get where it was going. The goal is to do ui in a functional language and you chooses a functional language for various reasons. But then the halogen components are essentially reimplementing object orientation in purescript (so everything looks weird, there isn’t special syntax for common things, and the types are bizarre): Components are these things that have a way to initialise themselves, an internal state, a way to receive messages and update their internal state, a way to compute from the internal state (ie rendering), and a way to reply to messages that are querying things (by having the message pass a callback for the reply as an argument). The only thing they have which is missing from standard oo is a way to pass up messages to their parent component. After all that one must wonder what the point of using purescript for this is and why not just use a more object-oriented language fron the start?
- mbo 8y ago
  That `core` `README` is really good! It's convinced me to look more into PureScript. Thank-you!
- 8y ago

dsiegel2275 8y ago

I would have liked to have seen custom operators stay around in 19, but I understand the motivations. I think it was in 18 they removed back-ticks for the same reason. Just makes it way easier for newcomers to learn the language. As far as I understand it, the native modules lockdown had to take place. Period. The one thing that most attracts myself (and many others, I'm sure) to Elm is the guarantees that the compiler gives you towards ensuring no run-time errors. Give folks the ability to author and publish Elm native modules and the entire platform loses that guarantee.

jarcane 8y ago
Not only that, it was a completely undocumented hack in the first place that it was repeatedly communicated shouldn't be used. And I really don't see how JSON parsing is a task that actually needed hacks to work short of massive GB dumps or something. I am sometimes frustrated by the way Elm is almost more a DSL for web apps than a complete language, but I also don't see anything wrong with closing an unsafe API in a language that's specifically about type safety. It seems like complaining that Haskell doesn't give you instructed ASM blocks.
- owl57 8y ago
  It seems like complaining that Haskell doesn't give you instructed ASM blocks. Well, Haskell doesn't give them out of the box, but it allows implementing and distributing all sorts of crazy unsafe stuff in libraries, including exactly this sort: http://hackage.haskell.org/package/inline-c-0.6.1.0/docs/Language-C-Inline.html http://hackage.haskell.org/package/inline-c-0.6.1.0/docs/Lan...
berns 8y ago
> Give folks the ability to author and publish Elm native modules and the entire platform loses that guarantee. Note that you can't even compile native modules for your private modules.
endgame 8y ago
I don't. If you ban custom operators, how can you find out future use cases where custom operators make a lot of sense? I am extremely distrustful of a language where certain people are more equal than others. Those elevated people could be blessed library authors, or within the core implementation or whatever, but I hate not being trusted to use my tools properly.

the_duke 8y ago

I only briefly dabbled in Elm and I'm not terribly qualified to comment on specifics, but I had a similar, negative impression of the way the project is managed. Especially in comparison to many other open source projects.

dcu 8y ago

These kind of stories make me value Go's approach a lot more. You just have to worry about making your product better.

tree_of_item 8y ago
Go's approach? Go has the same extreme BDFL approach to ignoring community feedback in favor of the leader's vision. I don't see what is different about Go.
- hellofunk 8y ago
  Common with many languages, actually.
  - star-techate 8y ago
    That has its downsides, but if the people maintaining the language are too lacking in strong opinions about the language, you'll have other kinds of problems: bad features get into the language and now everyone must be prepared to deal with errant use of those features in the wild; there are too many too similar ways to do the same thing, so the language becomes hard to learn and teach; there are features you never normally use, so you're terribly confused when you accidentally invoke them (suppose you have `val` and `var` as two ways to bind variables, but everyone only uses `val` because `var` has some weird extra semantics.)
    - ModernMech 8y ago
      Basically, you get C++. This is what I love about programming languages; it's a true marketplace of ideas. There's something out there for everyone, and a project of every flavor. You see this happen all the time with languages projects, especially opinionated ones, where someone likes the general vibe of the language, but wishes it were more like something they are more comfortable with. But sometimes a language just wants to be where it is, especially when it's run by one ego. Programming languages can be very personal things for their authors, much like a novel is for writers.

the_mitsuhiko 8y ago

I think Elm can learn a lot from Rust before 1.0 here. Rust made some "insane" decisions that should have pissed off the community but did not mostly because of the way the communication was handled. There were obviously some disagreements along the way which caused some valuable community members to jump ship, but overall it was really well handled and the language became better as a result.

Certhas 8y ago
Seeing these type of processes playing out over the years just impresses on me how exceptionally well done the Rust process was. The atmosphere and attitude of the community was always excellent. For newbs/outsiders looking in, I think a lot of it has to do with a culture of validating people's experiences. That's difficult. If a user complains about it, the natural reaction can easily be to go defensive ("You're doing it wrong" or "we documented that here"). Rust has successfully fostered a culture of approaching it as an opportunity to learn something ("Why did you not see the documentation").
MBCook 8y ago
I’m not familiar with the history of rust. Could you give some examples?
- the_mitsuhiko 8y ago
  Things that people were super excited about that got nuked: typestate, green threads, garbage collection support, tail recursion call syntax. But also small things (ternary operator was removed, a ton of keywords were changed and more).
  - MBCook 8y ago
    Thanks. Makes sense. I can seen wanting some of those myself, but I get you have to draw the line somewhere if you’re ever going to be ‘done’ with the initial/beta releases.
bjz_ 8y ago

gonyea 8y ago

And this is why I love TypeScript: It's just JavaScript, with a type system. If it's not in the standard then it's not in TypeScript (by default). There's no risk to adoption.

Tehnix 8y ago
Typescript certainly is nicer than plain JavaScript, but it doesn’t come anywhere near Elm (or PureScript or GHCJS). It really is a world of difference (edit: in type safety, that is). The reason for that is simply that TypeScript has to fit in with JavaScript, while the others do not.
- gonyea 8y ago
  I mean, Dart offers this. The difference between Dart and the other strongly typed options is that a massive pile of funding (and production apps) drive Dart and its direction. So it’s quite stable, if a little too risk averse. That said, I’ve never found Strong Typing to be that essential for front end dev. TypeScript is incredibly pragmatic, which is why it’s been so successful imo. Nothing stops people from writing all their dependencies in TypeScript. But it’s not necessary to use it successfully.
  - Tehnix 8y ago
    What is the “this” that Dart also offers? With the languages I specifically called out, a LARGE part of them is purity, and not providing the type system escape hatches that TypeScript/Flow does, to maintain easier gradually switching a codebase. A nice thing at first, but nothing gained for new projects.
    - gonyea 8y ago
      this = a sound/strong type system: https://www.dartlang.org/guides/language/sound-dart https://www.dartlang.org/guides/language/sound-dart

erokar 8y ago

I'm torn about this. I'm rooting for Elm and I think it currently might be the best frontend solution. I really like Evan's focus on developer UX and simplicity. This means removing things, making the language smaller and simpler. And to do that you need to maintain a certain amount of control. However this seems to have backfired. Too many in the community want this or that and/or don't feel their opinion is heard. Then they switch to something else. Unfortunatley I think something like ReasonML will win in the end. JS interoperability and just enough Algol syntax to staisfy the masses. Evan is between a rock and a hard place here and it's due to the current sentiment in frontend dev.

jnbiche 8y ago
> Too many in the community want this or that and/or don't feel their opinion is heard. Then they switch to something else. Unfortunatley I think something like ReasonML will win in the end. That's not the only reason ReasonML will win. The BuckleScript JS compiler generates fantastic JavaScript, with no huge extra runtime at all. Also, ReasonML benefits from all the stability of OCaml's type checker. And, as you suggest, both ReasonML and BuckleScript are in my experience a much friendlier and open community to experienced devs and commercial users.
- sdnguyen90 8y ago
  The runtime is not that big with 0.19 in my experience. I rewrote a (P)react component that was 5kb and Elm came out to be 6.8kb. If you're comparing it to ReasonReact, you still have the React/ReactDOM Javascript dependency which is still ~30kb gzipped
  - bjz_ 8y ago
    Kind of curious if anyone's played around with using incr_dom with Reason: - https://github.com/janestreet/incr_dom/ https://github.com/janestreet/incr_dom/ - https://www.youtube.com/watch?v=h_e5pPKI0K4 https://www.youtube.com/watch?v=h_e5pPKI0K4 Seems like it might be tied to js_of_ocaml though...
  - 8y ago

Libbum 8y ago

Whilst I get the point about the community leadership being more autocratic than others, the Elm language itself has always been opinionated - thus it's difficult to empathise with the rest of the sentiment of this post. An 0.x release, two years in the making, drops two features such that it can further fulfil its design goals and everything is ruined?

robert-wallis 8y ago

One of Elm’s main focuses is code that is not possible to crash. Once I groked that, native modules going away in favor of ports made much more sense.

_asummers 8y ago
Maybe it's my recent living in the Erlang/Elixir community, but writing code that is not possible to crash doesn't make sense to me. Servers die, machines get unplugged, network partitions happen, etc. I don't discount that the type system allows you to specify segments of your program that can be provably impossible to crash, but doing that for entire nontrivial programs seems like an impossible ask to me.
- erulabs 8y ago
  I could not agree more - and in fact, have no recourse when a developer tells me with a straight face that their code "cannot crash". The worlds best type system doesn't prevent timeouts, running out of disk space, memory, etc. The attitude I typically receive when trying to push pragmatism instead of idealism is usually a "you just don't understand". Throwing an exception is _not_ the worst thing a program can do, by a hell of a long shot!
  - Skinney 8y ago
    «Cannot crash» != «cannot fail». There are a bunch of things in Elm that can fail, but the language forces you, «through types», to deal with those situations. That doesn’t mean developers make apps that deal with errors reasonably, but the developers should be aware of every part of the application that can fail. Exception, of course, beeing stavk overflows as we haven’t solved the halting problem yet.
- Fiadliel 8y ago
  The general aim of error handling in languages like Elm is for types to not lie. If you can either return a result, or an error, the type represents that. The more places that can return an error: the more complex the types, and the more complicated the error handling. You can always pass the error value up through layers, but as people would say, it's just easier to make illegal states unrepresentable. It's not an aim to pretend that failures don't happen, especially when doing remote calls, and the types will be transparent in showing where this occurs.

Tehnix 8y ago

I think there’s a very weird mismatch between the way the core language people are pushing for the adoption of the language, and then at the same time they will turn around and say “we’ll, it’s not even 1.0, yet, so what’d you expect”. The way Elm is developed is fit for a language that has little to no users, and can take going so long between updates, that remove escape hatches needed to fill out the immaturity of the language. It really saddens me to see it go like this, because I once had high hopes for Elm. Nowadays I see it purely as a stepping-stone into more advanced languages like PureScript and Haskell. Elm is there to hold your hand, but it seems it has no intention of ever taking you further than the basics.

dsiegel2275 8y ago
> remove escape hatches needed to fill out the immaturity of the language I think you mean "immaturity of the platform". Also, native modules weren't the only "escape hatch". An Elm application can communicate with JS through ports.
- k__ 8y ago
  Complicated interop with JS also broke Darts back.
  - pjmlp 8y ago
    Politics broke Dart's back.
    - k__ 8y ago
      Sure, the bad JS interop had to come from somewhere.
- AlexCoventry 8y ago
  What was the capability of native modules which enabled the dev.to essayist to use them, where ports would have been unreasonable ("there is no other reasonable way to do what I need")?

brokencode 8y ago

I agree that community management and handling of issues could be better in Elm, but I’m willing to overlook that due to the terrific quality and innovation of the end result. Elm has benefited greatly from vision and the willingness to take risks, which is much easier to do with less communication overhead and fewer contributors. Maybe someday Elm will adopt a more community-oriented approach, but I don’t think that is necessary right now.

dsiegel2275 8y ago
If I could upvote this more than once, I would. Spot on.

tigershark 8y ago

I really enjoy the fable-elmish philosophy, I think that the community is great compared to what the author of this post experienced, but..BUT, the platform on the whole is just too immature. I remember trying to compile jquery using the otherwise great ts2fable.. and it was, and probably still is, pretty much impossible. Or trying to use fable-elmish and getting “undefined behaviour” in a “hello world” test page. Luckily I discovered pretty soon these limitations, but I think that when a platform is not battle tested by millions of people you’ll always get this kind of grief. So just test if elm or fable-elmish or whatever framework work well for you before committing head first into it..

kaffee 8y ago

For those of us who desperately want to put javascript (the entire language) behind us, many of the "problems" this article mentions are features. Refusing, on principle, to be inter-operable with unchecked javascript code is a defining virtue of Elm. edit: grammar

vmchale 8y ago
> For those of us who desperately want to put javascript (the entire language) behind us, many of the "problems" this article mentions are features. Yes, not having FFI is a feature. Brilliant.

didibus 8y ago

I've heard of a few people discontent with Elm for the reasons mentioned in the article make a very successful jump to ClojureScript and being much happier about it. It offers an MVU framework: re-frame. There are others too. Its community is very friendly and helpful, it loves to discuss the language itself. No one seems to think of themselves as more knowing. It has never ever broken backward compatibility. It's a core tenet of the language to never break anyone ever. Finally, it has very good interop with JavaScript. And its getting better and better every release. It's also ran by a BDFL, actually more like two. Rich Hickey as the BDFL of the standard language design, and David Nolen as current implementer and main maintainer of ClojureScript. But they're loved and admired. And if you disagree with their direction, you're free to add your own features as a macro, that's why they made the language a Lisp. The language design prioritizes pragmatism. All discussion starts with: What exact problem are you facing for which there are no simple way to solve. And working backwards from real problems, solutions are added and new constructs are built. The only thing is, it comes from a different school of thought opposite to strong static types. But it shares a lot in common, emphasis on pure functional code, immutability of variable and values. No OOP, everything is a function with support for higher order functions, closures and partial application. And the same focus on interactive live development. If you don't mind losing the strong static types, I highly recommend giving it a try. You'll only miss the nice Elm error messages.

KingMob 8y ago
Good suggestion! Just to clarify one point, though, Clojure/Script does support OOP, with protocols/records/types, it's just not the first thing we suggest people reach for in the language. As a community, we're much more likely to use boring maps/vectors/functions first, and switch to OOP when we really need type-based polymorphism, or extreme performance. One consequence of not forcing everything to be OOP (like, e.g., Java) is an honest evaluation of where it makes sense, and where it adds nothing but complexity.
- didibus 8y ago
  Well, I don't want to get into a semantics debate, but I can't help myself :p. And I'm pretty sure Rich Hickey himself would disagree with you about Clojure/Script having OOP. Protocols, records and types are not instances of OOP in my book. Polymorphism and abstract data types are concepts orthogonal to OOP and FP. The fact Clojure/Script has support for polymorphism and ADT does not mean it supports OOP. If you want to claim it supports OOP, I'd say it does in the form of interop. Genclass, proxy, or defining classes in Java or objects in JavaScript and using them from Clojure/Script. But, what is OOP exactly? We can debate this. I like to use Wikipedia's definition that it is languages where there is a construct, called an object, which groups together data fields and methods which can access and modify the data fields within. Clojure/Script has no such construct. But one can define them in Java or JavaScript, and use them from Clojure/Script through interop.

noncoml 8y ago

I was experimenting with Elm around .14 or .15 if I remember correctly. At the moment the language allowed you to use prime(‘) to name variables, and that was the suggested way if I had to guess by the tutorials and examples. During next release they decided that primes as part of a name were not their cup of tea and removed it. Just like that. When I asked why was prime no longer allowed, since I couldn’t see any good reason behind it, I got the usual: “it’s pre-1 release you should expect things to change, etc.” What left a bitter taste in my mouth was that this change had nothing to do with the language itself. It seemed as if they decided that using prime is not good style, so they forbid it. I haven’t touched Elm since.

kjeetgill 8y ago
I think rust went through a huge amount of simmilar changes pre-1.0. I think everyone was better for it. I appreciate they're taking their time to get it right pre-1.0. 1.0 is a fairly solemn promise and I respect them for not taking it lightly.
- noncoml 8y ago
  That’s exactly the kind of answers I got instead of giving me one good engineering reason on why primes were made forbidden just like this. Thanks for the demonstration.
  - star-techate 8y ago
    The actual reason is probably "when people use primes, they post code that gets syntax-highlighted by tools that don't know about primes, and this results in Elm code looking broken and stupid."
    - noncoml 8y ago
      Which is not a good reason to ban them completely from one release to the next. It only shows that they don’t really care about their users that much.
- 8y ago

protomikron 8y ago

In the end I think it's a good thing to be strict in language design and openly reject many ideas and suggestions. I guess it's a case of "too many cooks spoil the broth". Most languages have too many features anyway so removing them can be a positive thing.

vmchale 8y ago
> Most languages have too many features anyway so removing them can be a positive thing. This is completely unsubstantiated.

fouc 8y ago

I just wanted to let you know that a possible alternative functional MVU is Mithril/Meiosis http://mithril.js.org http://mithril.js.org - vdom lib - for the V http://meiosis.js.org http://meiosis.js.org - state pattern in conjunction with streams to give you the M/U Check out the gitter chatrooms, the communities for both are very FP oriented, and working on making it easier to do FP all the time. this guy came from elm: https://github.com/pakx/the-mithril-diaries/wiki/Coming-From-Elm https://github.com/pakx/the-mithril-diaries/wiki/Coming-From...

mst 8y ago

Can somebody take pity on me and explain why the ports system that's supposed to be used for JS integration can't replace the native modules?

Tehnix 8y ago
As far as I know, ports are strictly asynchronous, compared to native code, which can be synchronous. This means that if you are using native code for something that is 100% synchronous, you now have to go through a huge hassle of every calling site becoming async.

purplezooey 8y ago

had to realize for a sec that they weren't talking about the mail client

h4b4n3r0 8y ago

And that, in short, is why I prefer really freakin' old languages for doing real work.

always_good 8y ago

Article aside, the HN and Reddit comments really reflect our toxic entitlement culture. How many comments here seem to exist for no other reason but to get in a negative jab of their own? I'm reminded of Rich Hickey's great response (https://www.reddit.com/r/Clojure/comments/73yznc/on_whose_authority/do1olag/ https://www.reddit.com/r/Clojure/comments/73yznc/on_whose_au...) to a similar situation.

pjmlp 8y ago

Another proof that sticking with platform languages is a better option for productivity, even if the languages might miss a few shinny features.

yakshaving_jgt 8y ago
Yeah, productivity. Because spending 10 minutes writing asynchronous FFI code is definitely worse than spending a couple of hours debugging a runtime failure.
- pjmlp 8y ago
  It is always funny when people compare external languages to platform ones, but keep forgetting to include tooling, libraries and eco-system when comparing them, reducing it to grammar and semantics.
- vmchale 8y ago
  > Because spending 10 minutes writing asynchronous FFI code is definitely worse than spending a couple of hours debugging a runtime failure. Or... more than 10 minutes, because you have to re-implement a library that was already written.

msangi 8y ago

I would be totally on board with these changes if an alternative way of doing things had been offered. From the philosophical point of view they are exactly what is needed to allow Elm give as much guarantees as possible. The sad reality is that very little pragmatism went into this release and now stuff like web-sockets won't work [1]. This is very surprising because web-sockets are an use case where the Elm-architecture really shines. Things like this reinforces my idea that while Elm is a very nice language I wouldn't want to have it in production, or even in a side project, at least till it reaches 1.0 and becomes more stable. [1] https://github.com/elm-lang/websocket/issues/27 https://github.com/elm-lang/websocket/issues/27

lozenge 8y ago
Not only it doesn't work in 0.19, but the README doesn't mention it, the issue is closed (making it difficult to find) and the Elm release notes/upgrade notes don't mention it.
yakshaving_jgt 8y ago
Why can't this be done with ports?
- msangi 8y ago
  I'm not sure. I haven't looked into the issue much. In any case, I would expect web-sockets to work out out the box in a language that is specifically designed to run in the browser. If that's not working I'm sure that less common parts of the web platform aren't supported either. Normally I wouldn't care and implement stuff myself and contribute back, but it doesn't seem to be a realistic option in Elm. I appreciate that what's there is generally of very high quality, but I cannot pretend that there aren't many missing pieces and, more importantly, no clear roadmap
vmchale 8y ago
> From the philosophical point of view they are exactly what is needed to allow Elm give as much guarantees as possible. Pretty much every language falls apart when it comes to FFI. In Haskell, a foreign function `Int -> Int` can print to the terminal. That's just the way it goes.

jlengrand 8y ago

I love Elm. Discovered it last year and loved the language so much that I went on a conference later in the year on my own budget. I love how low the cognitive load of adding features is. Having a small baby, it helps a lot. That being said, some things really confuse me, and especially the way the governance model is accepted and cherished. We have a `almighty god` deciding what will and not be done, the accepted reason being that it's not 1.0 yet. I mean, with 0.19 coming out, all IDE support went out the window and the answer from the author of the language is basically : 'changes are known since last May, things should have been done already. I don't even know what the status is'. Communication is at the minimum lacking tact. Others could say straight offensive for not-core users. I understand PR is hard and not fun. But then find someone to do it for you, or act as to minimize it. At the moment, the advantages of elm far outweight the issues for my personal use. But I really wonder about the long run, but I'm really afraid someone gets really pissed and forks the language in the long run, fragmenting and ending up destroying this great community. That would really be a waste.

yakshaving_jgt 8y ago
Are you paying to use Elm? What's stopping you from sticking to 0.18? What's stopping you from building your own 0.19 IDE support?
- jlengrand 8y ago
  This is 100% what i mean. This exact way of thinking is what imho might well prevent Elm to strive as much as it could. And btw, I am (modestly) involved in the IDE support. So do check before being cynical <3.
  - yakshaving_jgt 8y ago
    My exact way of thinking is that you are not entitled to anything, and neither am I. I run businesses on Elm. I use it because it's the alternative that makes the most business sense (most confidence that I can release things without them breaking, and least chance of failure at runtime). I make money with this tool, and I don't pay to use this tool. If a better tool came along, I'd use the better tool. So far, Elm is the best alternative in my opinion. Everyone has this freedom to pick and choose their tools. And what does it mean to strive? Scala was a striving language. And? It's garbage. It tried to be all things to all people, and ended up being an awful tool. I find it absolutely amazing that so many petulant children in this thread believe they are facing some kind of authoritarian oppression because the language designer said "You know what? Synchronous FFI has almost only been a bad thing. All FFI should be synchronous from now on."

knorker 8y ago

This was confusing to read if you only knew about the email client Elm. In general I wish people spent more time naming things better, and reducing naming clashes.

hellofunk 8y ago

Wow: https://news.ycombinator.com/item?id=17843149 https://news.ycombinator.com/item?id=17843149