Hacker News Reader

Comment by Skinney | Hacker News Reader

The customer was involved from the very beginning. Everything we do at Vy is done in close collaboration with the customer.

Our experience is that previous Elm experience isn't necessary, as the language is very easy to learn, and people get productive very quickly.

View on HN

> Everything we do at Vy is done in close collaboration with the customer.

To understand this correctly; 'we' means the company 'Bekk' and the customer is 'Vy', right?

I don't find it too strange that it is relatively easy to onboard new Elm programmers when they are part of the same company. But what happens when competing companies want to bid for jobs at Vy? Vy is after all wholly owned by the Norwegian Ministry of Transport and Communications, so new future contracts are bound to come up. A language decision like this–beyond the merit of the language itself–might create a vendor lock-in that can stifle competition. Without being an Elm programmer myself, I am not sure that the technical merits of Elm is really worth it when taking the competition aspect into condsideration.

This is exactly what I was trying to say without being that direct.. :-)

> To understand this correctly; 'we' means the company 'Bekk' and the customer is 'Vy', right?

Right.

Good question! Vy has their own developers for this very reason. The teams here are a mix of Bekk and Vy developers, should Bekk be replaced by another company, someone will still remain to train the new developers.

I can understand that this might be useful from a technical point of view. From a business point of view I am not sure such a technical choice and symbiosis give the most bang for the buck.

> A language decision like this – beyond the merit of the language itself – might create a vendor lock-in that can stifle competition.

As distinct from the endlessly changing dot Carousel :]

Everyone should just use Java for everything, because "enterprise". Am I right?

I don't doubt that you can learn Elm quickly. But how many good developers want to use what might be an obscure technology in a few years.

From the Study of Programming Languages Not to Learn in 2019: "the five languages not to learn in 2019 are Elm, CoffeeScript, Erlang, Lua, and Perl."

The availability of developers is definitely something that should be considered when choosing technology. That said, NoRedInk, one of the companies earliest in adopting Elm have said they have had an easier time of hiring after they change to Elm from React. They are at least an indication of the opposite of what you are suggesting.

Also in Study of Programming Languages Not to Learn in 2019:

"As a final word, we wanted to reiterate that while the languages that didn’t perform well this year are useful and powerful in their respective fields, they may not have ranked as highly on our list because of the three metrics we chose. Therefore, if you really want to learn Erlang, Elm, or Lua, go for it — after all, these languages may make a comeback by 2020 because of your interest in them!"

I think one has to take the result in that article with a grain of salt as they only look at a very limiting set of metrics.

Also in the specific case of Elm I would recommend that people give it a try as it is a very different programming language than the most common languages and a great intro to the realm of strongly typed functional languages and functional thinking in general. Even if you don't end up liking or using it, it is a good thing to have experienced. There is always something to learn from learning new programming languages! ^^,

Personally, I would love to spend some time learning Elm. My point is not about Elm itself, but how smart it is to choose Elm for a project in 2019, at least in Norway.

Elm was chosen in 2017, and initial development was being done by 2-3 developers. Now, development is being done by 15-20 developers. Some of those developers came because of Elm (like me) and some came because our problem domain is interesting, and then learned Elm on the job.

Choosing Elm for a project in 2017 seems to have been a very good move.

I don't agree, but I hope the project is successful in the long run as well! I guess time will tell..

Elm could completely disappear from the face of the Earth next year, and I'd still be glad I learned it, and would still recommend it to others. The concepts have made me a better programmer in general, whether in Node, React or vanilla JS. Hard to explain until you've actually used the language.

Good developpers willing to use a tech that might be obscure in a few years?

Considering JS graveyards, I would have sworn that was 100% of frontend devs until now.

I think there is a clear distinction between languages and frameworks.

But again, what are the clear benefits for the customer of choosing Elm compared to the more popular choices in the market, given the (IMO significant) drawbacks of a niche language?

a) Many things that are runtime exceptions or silent errors in other languages, are compile errors in Elm.

b) Immutability, strong type system and few language constructs make local reasoning very easy. Developers spend less time chasing bugs.

c) Easy to learn. In virtual all jobs that I've had as a frontend developer, there's always been something new to learn. I spent more time learning Ember than I did spend on learning Elm.

d) Less churn. Javascript and related frameworks are, to me at least, exhausting to stay up to date on. Elm changes at a much slower pace.

I would argue that Typescript and React or Vue would have been a better solution for the customer. Yes, Elm might be better in some aspects, but I could name quite a few benefits for Typescript as well.

I think the technical reasoning is okayish, but from a business perspective I don't think the customer made a good choice.

> I would argue that Typescript and React or Vue would have been a better solution for the customer. Yes, Elm might be better in some aspects, but I could name quite a few benefits for Typescript as well.

Go on then. ;)

I would think most people on Hackernews are familiar with Typescript, but some of the benefits from the top of my head:

- Better tooling - Easier to work with existing javascript code - Superset of javascript - Larger community and ecosystem - More developers are familiar with it - Easy Server Side Rendering

I’m someone that only vaguely knows Typescript and doesn’t know Elm at all, so please forgive me if these seem obvious but would you mind expanding on some of your points?

In what way is the Typescript tooling better? i.e. what can you do with it you can’t do with Elm’s tooling?

Also I’m intrigued by the claim of “easier server side rendering” is it difficult to run Elm code on top of node.js?

We actually do have react in production as well. The header on our website is a react component, and our app is written in react-native. We also tried out flow for a while.

Elm compiles faster, has better error messages, is a simpler language (so our apps tend to stay simple, so easier to pick up again after some time) and has less churn.

We have experience with other technologies, we just find Elm better :)

The article lists several: static typing, guarantee of zero runtime errors, sane error handling using rich enums.

Other advantages: async is baked into the framework and isn't an afterthought like React. Immutability is standard and doesn't require a competing ecosystem of immutable datastructures like React. Also significantly smaller download sizes [1]

I also question that Javascript the language doesn't change: it's gone through several big language changes, and a growing number of devs wanted more changes, so stared writing in Typescript or Flow.

[1] https://elm-lang.org/news/small-assets-without-the-headache

Elm is so small, I'd almost argue that it's easier to learn Elm and The Elm Architecture than it would be than to worry about some almost equivalent combination of TypeScript, React, Redux (which was inspired by TEA, afaik), etc.

From a business perspective, having 0 JS crashes or errors in production is nice. I say that as someone who works at a startup that switched to Elm in 2017 and have had that very experience.

Just so. After having done JavaScript development for a few years, I really can't take the Elm FUD here seriously.

I'm starting to think that there really are a lot of front-end devs who don't know anything but JavaScript.

What's "FUD"?

Fear, Uncertainty, Doubt.

Describing a situation as worse than it really is.

That "study" says "which languages you probably should not learn as a first programming language".

Sure there might not be a whole lot of Elm jobs out there. But if there is one and you feel like learning Elm, what does it matter?

Also, since you talk about good programmers, surely a potential employer won't list it as negative that you've been able to switch technologies during your career? To me that's a strength rather than a weakness.

Erlang (via Elixir) is absolutely flourishing right now.

Reply on news.ycombinator.com