
Re-writing the site of Norway's largest transport provider in Elm - Skinney
https://blogg.bekk.no/using-elm-at-vy-e028b11179eb
======
kfk
I work mostly in Python for data analytics but I like to play with front end
from time to time. So I tried elm. I loved learning about the elm architecture
and the concepts of a ml type of language. But the community and the
principles of it threw me off. I need a simple parser and found this
[https://package.elm-lang.org/packages/elm-
tools/parser/lates...](https://package.elm-lang.org/packages/elm-
tools/parser/latest/)

I guess if you have a CS degree you can understand how that parser works, I
couldn’t. The community tried to help me on the forums but you are supposed to
know a lot of key functional concepts to even understand their answers.

Then I learned about how they decided to throw away Javascript interops. I
mean I love benevolent dictators but this was too much. Just fyi their
benevolent dictator thinks if you need a library you should program it
yourself. I can see his point but in Python word there are so many amazing
libraries. That principle sounds good in theory but it’s theory, the rest or
the world thrives with libraries.

However I became a better programmer thanks to elm. I would love for something
like ocaml to pick up more steam in data analytics. I think though python won
that battle for good principles (easy to use) and not for being functional, or
controlling side effects or having less bugs. If you think about it that’s
exactly why Excel is still so popular, it’s a monster but it’s easy to use.

~~~
wwweston
> Then I learned about how they decided to throw away Javascript interops.

Is this true? I'm not an Elm user yet, but I've been eyeing it and my
understanding was that there was interop:

[https://guide.elm-lang.org/interop/](https://guide.elm-lang.org/interop/)

It'd be a big deal if that _weren 't_ there -- FP stuff I may or may not be
used to? Bring it on. Stretch my CS knowledge? Cool. No 3P libraries? That'd
make it wrong for a lot of use cases.

~~~
Skinney
Elm has interop, it's called ports.

What the poster is referring to is that Elm 0.18 had an unsupported,
undocumented way of calling javascript code directly. This was inherently
unsafe (Javascript can throw exceptions and Elm doesn't support exceptions,
let alone catching them) and people were abusing it, so it was removed from
the language in 0.19.

------
_greim_
> To test out the latter, in the summer of 2017 we tasked a team of summer
> interns with the renewal of our seat map application, a crucial component of
> the ticket booking process. They were to use Elm, a language they had no
> prior experience with. To our surprise they took to the language very
> easily, and their work turned out great.

I think programmers—myself included—tend to be surprised by these stories,
because we envision two learning curves: general programming concepts, plus
the additional weirdness of learning Elm.

But "general programming concepts" unpacks into: A) valuable stuff everyone
needs to learn anyway, B) a bunch of hard-bought mental discipline which Elm
makes obsolete, due to its lack of side effects and mutable state. Going cold-
turkey into Elm, newcomers fast-forward through a lot of things JS learners
for example have to wrestle through.

[edit for clarity]

------
vlangber
I wonder how involved the customer was in the choice of technology. I think
the long term costs of choosing Elm will be higher than any perceived gain
during the initial development period.

The number of developers with Elm experience in Norway is small, and I think
it will make it harder to attract good consultants that want to work on it.

~~~
as-j
I'm in the process of replacing an Erlang service. Erlang is incredibly well
suited for the task, and it's a terrible choice for us.

Initial development was done, system worked and ran for years. Team left,
turned over and then 5 years later no erlang developers were left on staff.

The service is business critical, and you don't need 1 developer, you need a
team. 3 would provide some basic backup, but you need 5 to fill out the 24/7
on-call rotation. (yes people need vacations, weekends off, etc)

Sadly it's not the entire stack, far from it, it's one mission critical
service that's part of a very large system. So the excitement they get from
growing, enhancing and scaling the system is already a bit restricted. Problem
is, trying to hire is SF is already hard, and now we just selected the pool of
engineers to be a small subset of those.

So now the cost of 3-5 engineers, the work to hire them, manager and deal with
turn over. Wow.

Sadly (not sadly) we replaced the service with an AWS offering for $1000/mo.
World changed in the 9 years since the Erlang product was first written.

It's turned me off niche languages.

~~~
Zanni
Sorry, am I reading this right? You replaced a service that required a team of
five Erlang developers with an AWS offering for $1000/mo? Why wouldn't you do
that regardless of the language involved?

~~~
as-j
Sorry for the late reply. It actually needed little development, 1 person
would be just fine. But it was also scaling, and bugs crop up. Unfortunately
bugs crop up some days at 9pm on Friday, or 2am on Sunday. Since it's business
critical this need attention immediately, stop/restart isn't always good
enough. So this means you need someone who can supply emergency patches on
call all the time. (trust me turn if off, and turn it on again doesn't always
work, yay persistence, yay retries)

This can't be 1 person anymore, what if they person takes a vacation. So
that's 2 people. Perhaps the 2nd person can be much less capable that the
first, they just need to hold the system together for how ever long it takes
the lead dev to come back from his 2 week hiking trip in the amazon....yeah
not good enough. So then you end up saying we actually need proper on call, so
now you're hiring a team.

What if it was another language? Let's assume it's a core language of the
organization. Then you don't need a team, but capable Sr/Staff Engineers who
can jump in during emergencies. Might not be the perfect fix, but then you
have a series of people who can duck tape it together until the person
responsible is available.

Using Erlang tied our hands, and made a decision to throw a project business
requirement.

------
mhd
So no non-Javascript fallback for a quite important site & service?

~~~
jimbo1qaz
[https://www.vy.no/en](https://www.vy.no/en) does not load on Firefox, with
Javascript disabled in uBlock Origin, or Developer Tools.

~~~
jimbo1qaz
It also takes nearly 2 seconds for page content to appear, on Firefox with JS
enabled.

------
bgorman
An alternative worth considering to Elm is Bucklescript with the bucklescript-
tea library. This project gives you a more powerful, but similar language
(Ocaml/Reason) with a more direct interop mechanism than Elm ports.

------
ggregoire
> A common misconception is that it is risky to use a non-mainstream language,
> since it will then be difficult to find developers with the right
> experience. We have found, however, that we don’t need people to know Elm
> beforehand.

Are there a lot of people who actually want to use Elm tho? Seems like the
real risk to me, not finding anyone interested in learning and using Elm.

~~~
_greim_
From the POV of someone hiring, there's a sort of geek-magnet effect that
kicks in if you start hiring for something like Elm. You get the kind of
people who like learning new things, who would otherwise completely ignore yet
another React or Angular dev job listing.

~~~
mnsc
> people who like learning new things

Problem is that also attracts those where new technologies is not a mean but
the end goal. So when they start to get productive in the "new technology"
(that's now "one year old, ugh") and if the shop ain't up to the task of
rewriting everything every year those people move on to the next hype baby
[1]. Being a geek-magnet should be a very minor and explicitly stated short-
term factor in deciding what tools and technologies to use.

[1] Yes, this is anecdotal and based on one former colleague!

------
imedadel
Something (weird) that I noticed in many Scandinavian websites is their short
domain names. I don't know the reason, but I like the fact that you can type 5
letters and access the service that you want.

~~~
elektronaut
For .no, I reckon it's a combination of small population and the fact that you
need to be a citizen to buy one. Until recently, they were only available to
organizations. There's also restrictions on the number of registered domains
you can have (100 for organizations, 5 for individuals), that limits squatting
somewhat.

~~~
kaivi
You made me wonder -- what happened to ulv.no and sau.no?

~~~
hdfbdtbcdg
Probably too politically divisive.

Nothing gets Norwegians arguing more than wolf politics.

~~~
kaivi
We should control greenhouse emissions by releasing more wolves into shopping
malls.

------
roschdal
In my opinion, this is a case where a supplier (IT consultant company: Bekk)
uses a non-standard unpopular technology, to implement a technical solution,
for a customer who is state owned and has almost monopoly (Vy/Norwegian
Railways). I suspect, the reason for this choice, is to lock the vendor in.
For the customers of Norwegian railways, the results is a more expensive train
journey.

~~~
cstpdk
What's your evidence that train journeys have gotten more expensive in Norway
due to this?

FWIW i am Danish and almost all of our public IT projects are done in .NET,
almost always the reasoning is "more developers, more mainstream, less lock-
in". Our IT projects are always hilariously belated and more expensive than
budgeted. More often than not the same contractor (one of 5ish big
corporations) keeps getting the same contracts from the same departments
because they have pre-existing knowledge of the system they previously built
(hint: this is lock-in). Now, the last part is changing somewhat due to EU
tender rules, which I think Norway also abides by (they are not in EU, but are
committed to complying with most EU laws)

~~~
arcturus17
Isn't being locked to one of five big vendors that do .NET a bit better than
being locked to _the_ vendor that does Elm, though?

------
caspervonb
Hmm, personal preference but preferred the old NSB site. This takes forever to
load.

------
adreamingsoul
Is the mobile Vy application also using Elm?

I live in Oslo and use Vy to travel outside the city. I find the overall
experience to be excellent, and appreciate the friendly and simple interface.

~~~
Skinney
react-native. Although the seat selector is written in Elm and loaded via web
view.

------
winrid
Tried to use latest Elm with Websockets. It's just not ready yet but I look
forward to when it is.

~~~
IfOnlyYouKnew
I was frustrated by that as well. In the end, I actually found a solution that
was surprisingly easy and works well. I'm about 90% sure it was
[https://github.com/billstclair/elm-websocket-
client](https://github.com/billstclair/elm-websocket-client), although it's
been a few weeks and I can't check right now.

