Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elm in Production: 25K Lines Later

charukiewi.cz

Post reply on HN
Print view View original

241–250 of 278 posts

Re: Elm in Production: 25K Lines Later

#241

Post by Skinney »

Tarean wrote: post #237
Skinney wrote: post #204

Earlier quoted context omitted.

json.loads('foo.json') (what is that? python?) requires that the json matches your types exactelly. This, at least for me, is rarely the case. And yes, it is. Here is code from my own project: Json.map3 HintTemplate (Json.field "ID" Json.int) (Json.field "Text" Json.string) (Json.field "Image" Json.string) Where HintTemplate is a record type containing an integer id, a string text and a image url. What about this is…

That's reasonably similar to handwritten haskell json parsing: instance FromJson HintTemplate where parseJson = withObject $ \o -> HintTemplate o .: "ID" o .: "Text" o .: "Image" I wrote and > out but there is a definition like map3: liftA3 f a b = f a b This works for all applicatives, though. Is it normal for elm libraries to copy paste code like the map3 definition?

Not sure what you mean. It's normal that different packages have their own version of a given function, like List.map3, Json.map3 etc. But the implementation is different, so it's not copy-paste. It has to be this way in cases where generic types is not enough and something like interfaces/typeclasses is required.

Re: Elm in Production: 25K Lines Later

#242

Post by moogly »

moomin wrote: post #28
akuji1993 wrote: post #5

Earlier quoted context omitted.

Not into Elm at all right now and also kind of not convinced about functional programming, yet. But the article was definitely worth a read. I need to slowly open up for FP, I guess.

I'll make an observation: I write C# for a living. The great thing about that is that it has a truly great debugger. But, as you rapidly discover, it's easier to debug some code than others. For one thing, you want to be able to go back to the start of the function and re-run it. That means that methods that mutate internal state are hard to debug. Also, it's even better if you can follow the chain of reasoning witho…

Dumb question: Have you tried IntelliTrace in VS Enterprise (sadly only available there)? It tries to solve many of the issues you're mentioning. You can even start a remote IntelliTrace debugging session in production.

Re: Elm in Production: 25K Lines Later

#243

Post by Skinney »

hudon wrote: post #234
fbonetti wrote: post #205

Earlier quoted context omitted.

Elm's primary selling point is "no runtime exceptions". The subheader on Elm's homepage even says this[1]: Generate JavaScript with great performance and no runtime exceptions. Type safety doesn't come for free. If you want to build an application that doesn't have runtime exceptions, you have to specify what external data should look like, how to translate that data into a native datatype, and what to do if that exp…

Elm's type system will not catch this bug at compile time, it will still be a runtime exception, unless you're saying Elm's compiler does an HTTP call to that endpoint to verify that the interface matches the response object?? The only difference in your example probably is that Elm will force you to handle the case where your interface doesn't match the response object (missing field, in this case). But nothing in E…

> ... it will still be a runtime exception ...

No.

> The only difference in your example probably is that Elm will force you to handle the case where your interface doesn't match the response object

Which means that no exception have been thrown. You've handled it, however poorly, and so you've made a conscious decision about how to deal with it.

In TypeScript, this is much easier to forget, because you don't have a compiler that forces you to deal with it. If you're lucky, this causes a runtime exception at the place the error occurs. More likely, however, no exception is raised, and you get an error down the line which is hard to notice and hard to debug.

Like, there's nothing in TypeScript that forces the developer to use the correct types. A lazy developer could just use "any" everywhere. So if the programmer doesn't handle this well in JavaScript, they will do the same in TypeScript, and the end result will be the exact same: a runtime failure. This, however, doesn't mean that TypeScript isn't a great tool that helps developers avoid runtime errors, it just means that this particular programmer doesn't take advantage of the tools at his/her disposal.

Re: Elm in Production: 25K Lines Later

#244

Post by KirinDave »

dmitriid wrote: post #110
enalicho wrote: post #102

Earlier quoted context omitted.

It is no different from using a code generator for anything. Json2elm is designed to _help you_ write decoders, not replace decoders. Once you know how to write them, json2elm is mostly useful for generating boilerplate.

If you need a code generator to generate boilerplate... something's wrong with your language

So... you don't use yo/yeoman? At all?

Re: Elm in Production: 25K Lines Later

#245

Post by Skinney »

jnbiche wrote: post #239
Skinney wrote: post #219

Earlier quoted context omitted.

Cool! Does it enforce third-party libraries as well? A thing that typescript and/or flow doesn't support, is JSON. What if a JSON object doesn't match the type? This can cause sneaky bugs later :/ I'm not saying that typescript/flow is bad. Whenever I have to use node.js, I end up using typescript. But I've been bitten several times by the fact that typescript isn't as strict as Elm forces things to be.

> Cool! Does it enforce third-party libraries as well? Yes, as long as you lint those libraries, too. > A thing that typescript and/or flow doesn't support, is JSON. What if a JSON object doesn't match the type? That's why you do runtime validations of your incoming JSON if you feel like you can't trust the data (and if it's an external API, you probably can't). How is this different from Elm? > But I've been bitten…

It's not different from Elm. My point was that Elm forces you to do it, there's no way around. With Javascript+Flow or TypeScript, you need discipline to end up with code that is as reliable as Elm.

Me, personally, I take short-cuts when I'm pressed for time, stressed, or in a bad mood (which happens more often than I'd like to admit). I can always improve the code later (which turns into never). In Elm, I can't cut corners (as easily). This makes me write better code using Elm, which in turn makes me happier.

You --can-- get the same experience with Javascript, but it does require more from you, the developer.

Re: Elm in Production: 25K Lines Later

#246

Post by rtfeldman »

tarr11 wrote: post #222
antouank wrote: post #150

Earlier quoted context omitted.

For an average JS developer Elm is totally alien tech compare to React or Angular To turn your argument the other way. The JS landscape, where "trendy" libraries change every few months, is also alien to anyone that doesn't keep with the latest libraries every few months. Is that not worse? I don't have to explain "JS fatigue", it's a fact. For example, I just got into a new team, and I have to now use what they use.…

Agree in general that Elm is nicer than Redux. However... >>> You don't have to transpile or add a linter, or a type checker, or stitch new libraries every few months because the trend changed. Elm is still in alpha, and is adding and removing breaking features all the time. (See ports for example) [1] >>> No webpack or babel or eslint or immutable.js or typescript or flow or any of those. If you are integrating elm…

> Elm is still in alpha, and is adding and removing breaking features all the time.

Elm has had 2 releases since 2015 which had breaking changes. The elm-upgrade[0] tool has automated away a lot of the upgrade progress, and the compiler tells you about all the remaining things that need to change.

Put another way, Elm doesn't actually change very often, and when it does, it is typically a smooth ride. (I've been around for 5 breaking releases, and all but one of them were very easy.)

> If you are integrating elm into any kind of existing application, you will likely need webpack.

If that existing application is already using webpack, then sure, you'll probably keep it. But you don't need it for Elm.

For example, we use Elm at work (on a 150,000 LoC Elm code base) and we actually moved away from Webpack because Elm doesn't need it and we weren't happy with its UX. :)

[0] https://www.npmjs.com/package/elm-upgrade

Re: Elm in Production: 25K Lines Later

#247

Post by hudon »

Skinney wrote: post #243
hudon wrote: post #234

Earlier quoted context omitted.

Elm's type system will not catch this bug at compile time, it will still be a runtime exception, unless you're saying Elm's compiler does an HTTP call to that endpoint to verify that the interface matches the response object?? The only difference in your example probably is that Elm will force you to handle the case where your interface doesn't match the response object (missing field, in this case). But nothing in E…

> ... it will still be a runtime exception ... No. > The only difference in your example probably is that Elm will force you to handle the case where your interface doesn't match the response object Which means that no exception have been thrown. You've handled it, however poorly, and so you've made a conscious decision about how to deal with it. In TypeScript, this is much easier to forget, because you don't have a…

I agree that Elm is more strict at compile-time than TypeScript, there is no argument there.

What I have a problem with is using an example where the programmer is lazy in TypeScript, then assuming the programmer is NOT lazy when coding in Elm.

If you just print an empty error string and your app continues running assuming it decoded successfully, you can be in as bad a place as the app that crashed. Actually, in some mission critical cases, failing hard is safer than continuing with corrupt data.

In both cases, TypeScript AND Elm, you must do work to handle the failure to decode gracefully, it will actually be less work in TypeScript because you have less to specify. The only difference is that in Elm, you are reminded more often to do that work.

Re: Elm in Production: 25K Lines Later

#248

Post by rtfeldman »

StreamBright wrote: post #218
antouank wrote: post #150

Earlier quoted context omitted.

For an average JS developer Elm is totally alien tech compare to React or Angular To turn your argument the other way. The JS landscape, where "trendy" libraries change every few months, is also alien to anyone that doesn't keep with the latest libraries every few months. Is that not worse? I don't have to explain "JS fatigue", it's a fact. For example, I just got into a new team, and I have to now use what they use.…

Well sure, but as an architect/CTO I do not care about trendy, I care only about properly working, easy to develop and maintain and wildly used so I can hire for. Elm is none of these at the moment, but React is.

Properly working, check.

Easy to develop and maintain, big check.

Widely used so you can hire - it's usually easier to hire Elm developers because there are more people who want to use it than jobs hiring for it. The opposite is true for JS. So...better than check, at least for right now! :)

Here is a CTO giving a talk about his company's experiences with Elm:

"Elm from a business perspective" - https://www.youtube.com/watch?v=DvQI1KntMhk

Re: Elm in Production: 25K Lines Later

#249

Post by Albert_Camus »

StreamBright wrote: post #218
antouank wrote: post #150

Earlier quoted context omitted.

For an average JS developer Elm is totally alien tech compare to React or Angular To turn your argument the other way. The JS landscape, where "trendy" libraries change every few months, is also alien to anyone that doesn't keep with the latest libraries every few months. Is that not worse? I don't have to explain "JS fatigue", it's a fact. For example, I just got into a new team, and I have to now use what they use.…

Well sure, but as an architect/CTO I do not care about trendy, I care only about properly working, easy to develop and maintain and wildly used so I can hire for. Elm is none of these at the moment, but React is.

> I care only about properly working, easy to develop and maintain and wildly used so I can hire for. Elm is none of these at the moment, but React is.

As a CTO and the author of the OP, I can say with confidence this statement is false. Elm works correctly, is easy to develop in, and is easy to train developers that have experience in other languages to write Elm.

Re: Elm in Production: 25K Lines Later

#250

Post by Skinney »

hudon wrote: post #247
Skinney wrote: post #243

Earlier quoted context omitted.

> ... it will still be a runtime exception ... No. > The only difference in your example probably is that Elm will force you to handle the case where your interface doesn't match the response object Which means that no exception have been thrown. You've handled it, however poorly, and so you've made a conscious decision about how to deal with it. In TypeScript, this is much easier to forget, because you don't have a…

I agree that Elm is more strict at compile-time than TypeScript, there is no argument there. What I have a problem with is using an example where the programmer is lazy in TypeScript, then assuming the programmer is NOT lazy when coding in Elm. If you just print an empty error string and your app continues running assuming it decoded successfully, you can be in as bad a place as the app that crashed. Actually, in som…

The difference here, is that a lazy programmer, when forced to handle this particular case, would use "Debug.crash 'should not happen'", which causes the Elm application to crash at runtime. The TypeScript program doesn't force you to deal with it, so the lazy programmer can assume everything works, no exception is raised, and you're now running with invalid state.

To catch this bug in TypeScript, you'd have to write runtime validation, which you are less likely to do, since you can just do JSON.parse. Elm, again, forces you to write runtime type validation, and handle the potential error (which could be something simple as crashing the entire application).

When it comes to reliability, that makes all the difference.

And I'm not arguing that Elm is great because of poor developers either. I do theese sort of things when I write typescript, simply because I just don't think about the error case that often. Elm is a wonderful straight jacket that makes me a better developer <3

Post reply on HN