zlacker

>>whoish+(OP)
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...

>>bojo+Nc1
Can you talk a little about why you replaced Haskell as your language of choice?

>>all2+GU1
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.

>>bojo+Tn2
> 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.

>>tome+5v2
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.