Comment by bojo | Hacker News Reader

Comment by bojo | Hacker News Reader

Matanuska Telecom Association | Software Engineer - Systems Engineer | Full-Time | Alaska (UTC-9): REMOTE

MTA is an Alaskan ISP serving the southwest area of the state. The software team consists of 7 devs who support a relatively complex business enterprise environment. We're looking to add another Software Engineer and a dedicated Systems Engineer (DevOps) to our team.

As the hiring manager I want to be clear about a few things:

- This is a 70 year old enterprise telecom, not a high speed startup

- This job may interest you if you want great benefits and long-term job stability

- We have an existing environment running onsite on VMWare; the Systems role is designed to support, improve, and make adjustments to our tech stack over time

- Our core backend language is F# these days (replacing Haskell after 5+ years in production), frontend is React

- Our DevOps tooling is built around Terraform, Chef, Nomad, Vault, Concourse CI, Sensu, Prometheus, etc

- Must be authorized to work in the US

Software Engineer: https://mta.csod.com/ux/ats/careersite/4/home/requisition/59...

Systems Engineer: https://mta.csod.com/ux/ats/careersite/4/home/requisition/60...

Can you talk a little about why you replaced Haskell as your language of choice?

I'd love to hear how Haskell fell out. Someone important rotate out?

The short version: The team had no problems with the language when I introduced it back in the day, but after writing over 300k+ SLOC of production code over 6 years we bumped hard into a lot of the typical ecosystem problems that tend to crop up in discussion. We still have systems we support written in it which won't be phased out for years, but no new projects will be written with the language.

If the team had been full of diligent Haskellers they'd have stuck with it, but they aren't really the type to align with a language/paradigm, and so a slow pivot into F# was decided ~2 years ago via a well documented RFC process.

I'm personally still a Haskell fan, but my hand isn't on the keyboard anymore. Not my place to make the tooling choice for them.

No one above me cares about this type of choice since we're a small backend department to internal customers. As long as the team is delivering results by the deadlines we commit to we get a lot of freedom to use whatever tooling we think makes sense.

> we bumped hard into a lot of the typical ecosystem problems

I think those are the things we really wanted to hear from you about!

I'm actively working on improving the Haskell ecosystem. I'm aware of a lot of "typical ecosystem problems" that cause challenges for onboarding of new Haskell users but I'm not actually aware of many problems for users who are onboarding and generally successfully using Haskell. I suppose general tool cruftiness might be one of those but I think it's a much bigger problem for new users than experienced users.

If you could mention the problems you ran up against I would appreciate it.

There's a journal [0] on infinitenegativeutility, discussed here 40 days ago, with a section called "What pushed me away from Haskell?". That author points at issues that are primarily cultural. One example is a relaxed attitude toward backward compatibility from the GHC team.

[0] https://journal.infinitenegativeutility.com/leaving-haskell-...

If I grab an old Haskell project, even one without any external dependencies, I can often safely assume that it won't build any more with any recent version of GHC because everything has been changed just a little tiny bit.

That's an issue that would more affect experienced/long-term users than newcomers to haskell. I haven't used it myself. I'm just pointing at one person's perspective - someone who professes to still like Haskell - about why it's no longer a first choice.

- Tool chain issues. Similar to the blog Nzen posted in a comment here, upgrading compilers could be a pain if breaking changes were introduced

- Poor ecosystem fit for an enterprise environment. We weren't willing to write libraries for some of the things we needed to support: DB2 access, SOAP, etc. Ended up writing C# wrapper services for a lot of that early on

- Poor library ecosystem in some cases. What felt like a good choice would be unsupported a year later

- Perhaps our own fault for committing to using Reflex for a heavyweight frontend. The team did an amazing job, but supporting GHCJS, the tooling around it, and trying to get faster dev iterations became a huge drag on the team

- Indirectly had to support it due to Reflex, but Nix. It's another rabbit hole that requires collective interest and a willingness to peel back the layers to make things work. Was another drag on the team

At the end of the day I'd say the biggest problem was cultural. I firmly believe that in order to have a successful Haskell environment, you need devs committed to the language and would label themselves "Haskellers". My team learned it and became expert engineers, but they are by no means Haskell language pros who thoroughly understand the inside outs of the language and its myriad of extensions. It's just a tool to them and they only used as much as they needed to.

Very helpful, thank you!

> ... so a slow pivot into F# was decided ~2 years ago via a well documented RFC process ...

I think I'm in love. But not authorized to work in the US.

What's on RFC? Great post by the way, thanks!

https://en.wikipedia.org/wiki/Request_for_Comments

We use this process to make some of the harder more nebulous decisions that require a bit of research and investigation from the entire team. While it does suffer a little from "decision by committee" we haven't ran into it as a problem in practice.

It's a great way to give people a chance to try and introduce new technology, processes, or paradigms. If they're committed they'll get the entire team excited and involved. If the team isn't interested it doesn't make it to the end of the process - and that's ok!

Interesting, thank you for explaining!

Request for comment. Internal proposals on development processes

This looks interesting, but I'd like to double-check something - both job postings say "at our Palmer HQ facility", as opposed to your post mentioning that it's remote. Is remote allowed, or is it on-site?

Remote is fine. I think that's a consequence of how HR posts it.

Are you open to applications by senior devs from outside the US? You mention US work authorization, but on the other hand, this post has been up for a while now.

One must be physically present and eligible to work in the US.

I have worked F# before while supporting fantomas and F# lint. What does authorise to work in the US mean(for global remote)?

It means we require people to physically be located in the US, but no citizenship requirement.

Reply on news.ycombinator.com