Live data from Hacker News

Elm changed my mind about unpopular languages

blog.realkinetic.com

201–210 of 321 posts

Re: Elm changed my mind about unpopular languages

#201

Earlier quoted context omitted.

Worth noting that in our experience, hiring has gotten way easier for us since we became an Elm shop. We really struggled to hire React engineers (who have a zillion positions to choose among - why would they pick ours?), whereas there seem to be a lot more great programmers who want to use Elm than there are companies hiring for Elm positions. Here's a verbatim quote from a cover letter (one I happened to be reading…

Worth noting is that you haven't been able to find a single criticism of elm in years. You hired the language designer so it's understandable that you'd have an easier time with the language. However, you've consistently kicked dust in everyone's eyes every time anyone has anything remotely critical to say about elm. It's frustrating because you are so smart and so insightful and it just looks like you're deliberatel…

Maybe it would be useful to list your criticisms of the language? All Robert did was point out a single point about how NoRedInk's decision to go all in on Elm has been a net win on hiring, why such a negative comment without anything constructive being said?

Re: Elm changed my mind about unpopular languages

#202

Earlier quoted context omitted.

I used Java, C and C++ before coming to Python. Unlike theirs, Haskell's type system is complete -- even a function of functions can specify exactly what kinds of functions it uses for inputs and outputs. That makes higher order programming much safer -- and higher-order programming might be the best way to move fast. Haskell is also astoundingly terse. In Java and C my data type declarations were too long to fit on…

That complicated type system w/ type inference does come with it's own costs, usually bad compile speed issues. It's what I've noticed when looking at languages like swift, rust, scala & haskell. I'm currently dealing with it in a large swift project, and I would much rather go back to the extra verbosity of objective-c than have type inference at this point. But that was insightful, thank you!

The type system is probably not the bottleneck in any of those cases. As a sibling comment points out, ocaml has very good compile times, and the inference problem is basically the same as in Haskell.

In the case of rust, I suspect one of the biggest issues is the way parametric polymorphism is implemented. Basically, if in your program you end up using e.g. Box, Box and Box>, you're compiling Box 3 times.

I don't know enough about swift to hazard a guess as to where the build is spending its time.

My experience with Haskell is that compile times are neither great nor terrible.

Re: Elm changed my mind about unpopular languages

#203
post #17

> First, Elm has the natural predictability of a pure functional language; when you write Elm, the compiler forces you to consider every case. I'm a beginner with functional languages, but isn't the type system completely orthogonal to the fact that Elm is a functional language?

what does orthogonal mean in this context?

Re: Elm changed my mind about unpopular languages

#204
post #124

Earlier quoted context omitted.

Just tinker with Elm at work on your lunchbreak and say you uswd it at work. If you're awesome, no one will know and/or care where you picked up your awesomeness.

> say you used it at work Please don't do this. If you're not found out in the interview, you'll be found out on the job eventually due to your obvious lack of experience. Some of my most personally loathed coworkers have been people who have bullshitted their way into positions by claiming skills they don't have or aren't qualified in, making them a nightmare to work with.

Good developers should be able to pick up new technologies on the job though. And you are conducting interviews in such a way as to select for good developers, right? To the extent that that's possible anyway?

I'd rather just hire for good developers in general who are interested in working in Elm than to hire only for Elm experience. As you've pointed out, there are problems in doing the latter.

Re: Elm changed my mind about unpopular languages

#205
post #194

Earlier quoted context omitted.

Python 3 supports type annotations natively, and the mypy tool is an external typechecker that you can run just like any other static analysis tool during your build.

That isn't static typing.

Whatever you want to call it, it's a lot more static than it used to be.

Re: Elm changed my mind about unpopular languages

#206
post #162
post #14

I'm a Java dev with just some basic experience writing functional code, mostly in Java/Kotlin/Groovy/Ceylon (all of which are primarily imperative!). Can confirm: Elm is awesome, easy to pick up as long as you understand basic things like union types and immutability, and I found myself productive in it within a single day!

I notice Scala missing from your list - if you need the JVM or find Elm to not quite have what you need, it's a great language. It's basically the opposite end of the spectrum, design-wise - Elm is "let's create this highly opinionated, carefully curated language and try to make it perfect" and Scala is "let's throw every feature we can derive into our type system and let people work it out". It's got it's issues (mo…

Scala's flaw - and Elm's strength - is it is a massive language that allows for a large amount of magic to happen. Elm is by comparison tiny and extremely explicit, and error messages thrown by the compiler are almost always super helpful. But Elm can't (really) be used on the server, so it doesn't hurt to look at Scala there, though be prepared to have a hard time finding experienced engineers to hire.

Re: Elm changed my mind about unpopular languages

#207
post #38

Earlier quoted context omitted.

The communities for languages like Elm are definitely smaller, but they're also "passion languages", if that makes sense. Nobody is learning elm because they've been or feel forced to (like you might with React, eg) or because they needed to maintain a legacy codebase at an old job or something. They're learning it because they're interested/like it, etc. So when it comes time to hire you have a small(er) pool of can…

But are language enthusiasts really better hires in general? I've known many of them who loved the theory and toying with a language but were not any better at producing actual value than the average joe.

I think this depends on what you mean by “actual value”. A working product powered by a tangled yarn of hastily-assembled spaghetticode has a highly dubious long-term value, and what’s worse, your “average-Joe” coders might not even realize/see the value of what that “one overly-careful coder” brings to the table

Re: Elm changed my mind about unpopular languages

#208
> Even though Elm is a small language with a small community, that doesn’t affect the Elm experience in a noticeable way.

This conclusion was pulled out of thin air, with no justification from the rest of the article. The title is misleading, the article is really about why the author enjoys Elm over JavaScript...

The general rule of thumb that a larger active community leads to faster software development is more or less still true. There is no reason to suspect this is not the case with Elm.

It's all fun and games until you get hired to build a production-grade web stack in a dinky game-scripting language with no community, that you have written 0 lines of code in. Some people live and breath to reinvent wheels in 19 different languages. Not my cup of tea.

Re: Elm changed my mind about unpopular languages

#209
post #17

> First, Elm has the natural predictability of a pure functional language; when you write Elm, the compiler forces you to consider every case. I'm a beginner with functional languages, but isn't the type system completely orthogonal to the fact that Elm is a functional language?

what does orthogonal mean in this context?

It means that the two features are independent: you can have the compiler check types in non-functional languages, and you can have functional languages that do not have static typing. Elm happens to have both static type checking and language features supporting functional programming.

Re: Elm changed my mind about unpopular languages

#210

I don't get it. The author didn't address his original concerns, he just said "Elm is awesome", which may be true, but isn't a rebuttal of his previous points, which are condensed here: >You can go through the whole development lifecycle of the app and you’ll rarely encounter a situation where you can’t find a fix online in 5 seconds. Somebody else has already worked out the kinks. My strategy was flawless.

I suspect the missing connection is this: if you encounter a conceptual/technical bug with a popular language/framework, you can find a solution online quickly. If you write buggy code (especially bugs that don't reveal themselves until live in production) it involves much, much more pain to fix those. Elm helps significantly with the latter.

> Functional programming helps significantly with the latter.

FTFY.

Post reply on HN