I'm not surprised Elm is not viable anymore at a medium or large company, despite continuing to use it every day myself for side projects. The creator has deliberately shunned publicity or popularity for it in the last few years so adoption and therefore hiring has slowed to a crawl. We still have a vibrant and passionate small community, but the emphasis is on "small". No matter how superior it is to e.g. React it will lose out at a company level if you have pay the price of retraining all your frontend devs to "think in elm" to continue using it.
I'm mainly sad that we'll be losing the chance of any future Kevin Yank videos about Elm. I really love the videos of his I've seen on youtube, including non-Elm ones such as the one about how to use VoiceOver for devs [0].
What are your thoughts on the direct descendant, Roc? [0] I know it's pre v0.1 so maybe you don't have any, but as a fellow Elm lover it seems pretty compelling on the surface albeit less directly frontend-dev focused.
> it will lose out at a company level if you have pay the price of retraining all your frontend devs to "think in elm" to continue using it
This is something every framework is up against, since React won. It has become more and more of its own JS dialect, so devs that grow up with it also “think in React”.
On the other hand, React is super slow, a problem which is further exacerbated by the fact that rendering and invalidation happens somewhat indirectly, meaning it’s really easy to accidentally make something super slow.
For your run of the mill website, this probably doesn’t matter. But for interactive web content, it can absolutely be a competitive advantage to use something faster and more responsive.
Everyone seems to be saying that the performance doesn't matter, but as a general consumer and an employee with ADHD, I absolutely notice every millisecond, and have been known to abandon products over it (or make my own frontend, depending on the viability of alternatives).
Like, I can feel the delay typing in a web browser compared to native, and it drives me crazy. If the output doesn't seem like a direct response to my input, I lose focus. Simple as that, and react seems to be a big part of that problem.
We have ways to go in our apps, but solid has done wonders already. Currently I'm researching state caching and optimistic updates, both of which should also improve it.
I don’t think I’ve ever seen a web app where the performance of React was such a bottleneck that it would in any way justify migrating to another tech stack. You’d have to get so far into a project for that to become an issue that the cost of switching would be huge.
As soon as a web site adds the feature where content is removed when out of the viewport and the browser's find feature no longer works, that web site has reached this point and is deploying workarounds that harm the user experience. Facebook and Twitter have had this feature for most of a decade.
If you read my original post, one of my points was that React’s rendering and data model makes it too easy to render unnecessarily, which causes perf issues.
I would say “can cause” performance issues, but I wouldn’t say React is one of the primary reasons for poor performance. You can get very far with little optimization in React, so I am skeptical that the way React works fundamentally causes issues.
YMMV. I've been involved in multiple large-scale React projects at this point, and they all eventually suffered from performance issues, related to React's rendering model. And fixing it is always painful.
On Reddit, as another comment mentioned, yes, React seems to have been a major factor in how slow it became due to the patterns it encourages, and the massive JS sources.
You can only 'get very far' because browsers are crazy fast and you don't notice what's going on underneath. Until it catches up to you.
Then you would need to show me proof that other frameworks handle similar complexity with less performance degradation or optimize with less pain.
My general advice in such cases would be to strive for more isolation. Do use Redux. Don't be afraid to use multiple stores on one page if that allows you to isolate rerenders.
I have experiencing on both complex React projects and complex vanilla JS projects (think the scale and complexity of Figma). Vanilla JS lends itself to being more performant. Anything that happens in Vanilla JS happens for an explicit, developer-defined reason. Things don’t rerender unless explicitly asked to. This can be both good and bad. While Vanilla JS tends to stay way more performant as complexity scales, “stale state” bugs are much more common. It’s a tradeoff.
I had the exact opposite experience. I mean, first of all, people using "VanillaJS" get the DOM manipulation wrong a lot more often. And then I do hope you don't conflate code size with complexity, because of course, direct DOM manipulation takes one heck of a lot more code (unless you create and maintain your own bespoke framework creating your own headaches). You are basically contradicting the whole reason Facebook, a pretty big and quite smart company, started React in the first place.
You also don't seem to understand what "rerendering" means. And that is often a problem in terms of performance. A React component only executes to determine if things have to be changed in the DOM. Not understanding this is creates a lot of pain.
As I said, this project was about as complex as Figma: a feature rich collaborative editor. This designation has nothing to do with code size.
Go hook up the React dev tools to Reddit and look how much each component renders. You see that components are constantly rendering even though nothing apparent has changed. I get that ideally React would only re-render when something has changed, but clearly it’s easy to create situations where react thinks something has changed even if it hasn’t.
Another good example is the Facebook website itself. It’s just so slow. I get saying Reddit developers suck, but I don’t think you can say the same about FB developers given that FB made React. React is popular because it’s a good developer experience. It’s not the best choice if you want optimal performance.
Yes, that seems to be a common theme: you have a hard time believing anything that doesn’t fit with your preconceived notions.
Again, connect React dev tools to Reddit yourself. Given that you’ve been given a concrete example of a slow website, I have a hard time believing you can even differentiate a performant website from a slow one.
As well, people don't understand that React is an idempotent rendering framework. It's easy to reason about because of the same reason why functional languages are easy to reason about, it does not mutate but instead creates new copies.
The point is the same as functional languages, making immutable copies is what makes it easy to reason about, where reactive changes don't. There are ways to make VDOMs fast too, faster than reactive frameworks.
Well, we all seem to be in agreement that excessive rerenders are the leading cause of poor performance, and reactive frameworks are the solution.
The only performance bottleneck (I can think of) at scale with these frameworks is bundle size. Components are marginally larger in solid, and much larger in svelte. Fortunately, components don't all need to be loaded at once, and react has a lot of weight from the getgo. I cannot imagine a situation where the increased component size of svelte or solid would actually result in a larger app, even before weighing the performance gains from reactivity.
One other thing to note: An old team tried scaling with svelte once, and we ended up with react. This isn't related to performance, just DX. Solid is going much better, the primitives approach makes scale easy to reason with.
> Components are marginally larger in solid, and much larger in svelte.
That doesn't sound right. Components are usually much smaller in Svelte, both source and compiled output; if you have hydration enabled, the JS only contains code needed to hot-patch the DOM, and not rebuild the entire template including all the static parts as react/solid does.
When Svelte still called itself the "disappearing framework", the trade-off was larger overhead in the overall project due to repeated code, but in later versions Svelte ships a runtime with a shared library.
> we all seem to be in agreement that excessive rerenders are the leading cause of poor performance, and reactive frameworks are the solution
When we were hand-wiring components in Backbone, knockout.js etc, rendering was extremely optimized, since you decided on each and every action that would trigger it, and you did not want to overwrite potentially stateful DOM elements unless really needed.
It was way easier to get stuck into infinite loops, get desync issues, or simply completely loose track of chains of events, but unnecessary re-renders were not a major issue because they were much more expensive. React offered a solution to reason about the component tree more clearly, and along with flux and the unidirectional data flow, eliminate issues around stale data and mutations. It was not meant to be faster.
Yes, if the company like reddit, facebook - which has prestige, finances and ability to hire rockstar-10x-A-players React/JS developers is unable to get their shit right and their react fronts works like garbage then it simply means that there is no hope, for some reason it's simply not possible to make performant app with React.
The other way around is to point at great React based apps. Linear’s project management tool is so quick and fast. It takes a whole mindset embedded into a team to make a product fast from the get-go.
Or it's purposefully bad to incentivize people to use their app which has more tracking. I've had React frontends that were performant and plain JS frontends that were laggy. It's not really a factor of the framework.
Bullshit. "React is super slow" is just not true in any shape or form.
Especially not React itself. And even if React itself or the way it does things is "too slow" (which is the only metric that counts) then there are escape hatches or ways to deal with that.
I haven't used React in a long time, but when I did, one of the main reasons for using it was that it was much faster than most handwritten non-trivial DOM code because it managed to avoid the `write CSS -> read layout` anti-pattern.
Plus the vdom... Isn't great, the bundle size puts react at an inherit disadvantage, and the community has a knack for over reliance on bloated packages
Just people who don't understand how to write performant React, honestly.
There are ways of writing React that result in vast numbers of re-renders... it's not a best practice, but it's relatively easy to make happen, especially if you ignore the official recommendations and pull Stackoverflow answers from 2015.
Sure, to some degree, but you have to wonder why it's so easy for developers to footgun themselves. It's the fault of the language, imo, not bad developers.
React is easy to use without understanding the component lifecycle. The penalty is poor performamce rather than a non-functional app.
You saw the same thing in the before times with Adobe Flex. So much code from people who had no understanding of the lifecycle - apps that worked but were appallingly slow and buggy.
I believe the term is "fine grained reactivity". Basically, components do not rerender when data updates, only the specific part of the DOM dependent on that data.
This alleviates all the footguns that come with rerenders (including the infamous infinite loop) and often results in cleaner code.
I'm partial to solid[0] (there are lots of comparison articles, but I think [1] and [2] show it the best). I believe svelte is similar and vue is experimenting with this as well
That isn’t always true. Reactivity can make updates faster, but adds more overhead to creating DOM nodes because you need to set up the subscriptions that are used to eventually update them.
To steal a phrase originally about VDOM: “reactivity is pure overhead”. Nothing comes for free!
Maybe in theory, but solid still outperforms react in creations by a considerable amount, and I think most applications will find they are doing a lot more rerenders than insertions anyway
> it was much faster than most handwritten non-trivial DOM code
That would be incredibly rare. Despite the myth propagated, React is unlikely to be faster unless you were doing a ton of interleaved layout-triggering reads and writes. Even naive direct dom-diffing approaches like hyperapp/choo/morphdom can be faster.
That's not really the point made in the article, he mainly talked about the difficulties of maintaining a hybrid codebase split between Elm and another framework, and how their specific company situation nudged them to choose React to go all-in with
Elm is used in many medium/large companies. The biggest ones are NoRedInk and Vendr, the later reached 1B valuation recently with 600k+ loc Elm codebase.
> When someone tells us in an interview they’re excited about working here because they like functional programming (say), we count that as an indication they might not be a good fit.
Hmm. I’m not one of these tech-stack-driven types of developers they’re talking about in this paragraph, but even I had to raise an eyebrow here — this seems like the kind of rule that’d have a super high false negative rate. I understand the kind of person they’re trying to avoid hiring by accident, but… being excited about a cool language being a “point against” to try to serve that goal? Seems a little over the top
I interviewed somewhere once and mentioned that I did some projects in Erlang and learned a bit about functional programming. The founder told me that functional programming is a joke and that I'm clearly a computer scientist and not an engineer, and told me he'd never hire me as an engineer.
This was one of my first tech interviews after spending nights and weekends self-teaching. I only mentioned this at all because the dudes LinkedIn said he was involved with some Erlang orgs.
Anyway, I did take a non-eng role there, and it was easily the worst and most abusive (like verbally abusive, psychological abusive, generally fucked up) places I've ever worked. Eventually i got my first engineering gig at a more humane company and have been doing great since
I learned recently that the other company went to zero. Good riddance
(though I am bummed for folks who lost their jobs)
I've recently had an interviewer tell me that "Erlang is an academic language" and promptly stop the conversation after that. That's in a company that was attempting to make distributed applications easier to write.
This was both:
- factually wrong;
- a bright red flag that the company doesn't know their own domain as well as they think/claim;
- a bright red flag that their scope is much more limited than what they claim in the job description.
Even if the company despises Erlang for whatever reasons, it's still very valuable for them to examine and be educated about it. Erlang makes tradeoffs for X optimizing for Y, we'll choose a different tradeoff since we're optimizing for Z.
Once I interviewed at a company with many competitors. I continually asked "how will this company succeed while the competitors have a ten year head start? What choices do we make that the others didn't?". I got blank stares. Literally nobody was interested in examining the competitive landscape.
Oh, I've had that, too. I've interviewed with a few companies that create products that are literally years of research behind their (sometimes free) competitors. And don't realize, typically because they don't have the skill to even comprehend the difference.
And for fun, all these companies interviewed me on cloud development, rather than on their core offering, despite the fact that I actually happen to know a thing or two about said branch (i.e. I have both a PhD and commercial experience in the domain).
However, part of my response was that Ericsson had been using it industrially since the 90s, and that in fact Erlang was actually less academic than Python or Go. The recruiter handwaved this as "well, it's an academic language".
I’m guessing it’s probably the prolog-like syntax that gets it thrown in to that category by some. I’ve never heard someone consider Elixir “academic”.
1) "The founder told me that functional programming is a joke and that I'm clearly a computer scientist and not an engineer, and told me he'd never hire me as an engineer."
This sort of person intends to sleep in the bed that they make, so best to leave them to it.
On the other hand...
2) I'm an Elixir guy looking for work for a few months now. I've been applying to Ruby on Rails jobs where it makes sense (it was a thing I used to do). Should I be concerned that this is the perception out there? IS this the perception out there? I've heard this attitude from businesspeople in the past (such as from Brad Birnbaum, a former boss who is now at Kustomer; this was while I was at Desk.com) at times, "I don't want academics, I want builders". He said this to me repeatedly; in hindsight he was probably trying to signal to me that I was starting to look too academic.
Notably, all of the apps that the businesspeople I've heard say that, are now shut down after being bought out (and Brad is now a bajillionaire after a Meta acquisition). Hmmmmmm. But I guess that was the plan all along: To build only good enough to last to a buyout.
When you talk to a manager, you should lead that you are interested in building great products. Even if my company is using functional technologies, I want people who are professionally interested in learning business domains. It's great that you're interested in functional programming, but my fear is that I will hire someone who puts great effort into changing the culture to use avant-garde tech in a place that doesn't provide return on investment. (Or worse, drags us into a culture of malcontent!)
That isn't to say Erlang, but I've also seen an organization that struggled to hire because it couldn't find enough Clojure expertise and saw good developers onboard slowly because they had to learn domain, language, and paradigm in a practical environment.
There is a secondary worry in hiring people who present as tech-forward: if we need to make pragmatic decisions that mean using industry standard technology, will they leave out of frustration? If we need to make a decision to leave some technical debt there for business reasons and address it later, will this cause difficulties with the developer?
____
(That said, I know a fair number of good developers who have struggled to find work in this environment. It has nothing to do with Elixir.)
> I want people who are professionally interested in learning business domains
You can want in one hand, as the saying goes. If you select for people that care about business domains you're more likely selecting people good at feigning interest in your business(aka liars, or otherwise honest people who need to eat). Even if you get what you want you won't do well in the long run. I rarely see people who aren't passionate about technology avoid making a mess of it.
I have genuine interest in both. I build things because it's awesome to make someone's day better. It's a demotivator for me to put out software that doesn't work well. Technology is a means to that goal.
Because I'm wired that way, it's a lot easier to find people who are also wired that way. But I can say that there are absolutely places for people who are wired to be passionate for technology for its own sake. (Some of Fintech and adtech is a good place, for example.)
And if you feel you need to lie to work in a place with a product driven culture, then great. But don't be disappointed when the job is listening to calls with users and your conversations are around "which of these approaches will make the user's life better?" and there are technology radars that are justified by users' needs.
Not so long ago, everything FP or reactive programming was considered academic. Heck, even virtual machines, garbage-collectors, threads or distributed programming were considered academic. These days, who doesn't use most of these bricks?
Which means... sadly, it means that I have no clue what the future holds for Elixir, or Erlang, or any technology that is perhaps a bit too much in advance on its time.
I'm endlessly fascinated by the strong opinions people in software develop about tooling. I never saw it with such intensity anywhere else... I'd like to get more into that someday. Maybe because we use these tools with our minds so it's a very intimate thing. Maybe because people find hard to learn a set of tools due to so much of foundational knowledge behind it having been abstracted away so they develop mental defenses against other sets of tools as a rationalization of why they don't wanna lose the sunk cost...
I don’t think it’s a SWE thing at all. Just bog standard human behavior.
People like consistency. They hate change. If they get used to a specific tool or way of doing things, I’m pretty sure you’ll find similar behaviors.
The key is time spent with a tool. I would expect if you took away an engineer’s favorite CAD software, even if it costs many thousands of dollars, you’d see a similar reaction. Would they be able to do their job with another tool? Certainly. Will you hear about it? Even more certain.
> Maybe because we use these tools with our minds so it's a very intimate thing. Maybe because people find hard to learn a set of tools due to so much of foundational knowledge behind it having been abstracted away so they develop mental defenses against other sets of tools as a rationalization of why they don't wanna lose the sunk cost
It is both of those things, I think, and more. For me, at least in Elixir's case having come from Ruby, it is also that I am acutely aware that Elixir virtually eliminates entire classes of bugs that in some cases took me months to run down in Ruby.
I moved away from Rails and then back to it because I really wanted to join a particular company. The answer to 2 is somewhat yes, but Elixir no longer counts. People "build" with Elixir, it's the builders FP. This isn't my opinion (I try not to have one on this subject, fed of language snipes) just the general attitude I've noticed.
I'm really glad to hear that, because to me it does seem like Elixir is the FPL that is closest to satisfying a GSD mentality and not getting caught up in too many interesting rabbit holes.
We (Ockam.io) are definitely building very real and critical things with Elixir. We filled our remaining open position for it last week though so we’re not currently hiring for an Elixir person. Just wanted to point out there’s definitely companies out there that value it for non-academic reasons.
What was your method for hiring; were you looking for Elixir people who can come in hot, or people interested in it specifically that want to learn, or just "good software people" who'd be WILLING to learn it, or something else entirely?
I wasn’t the hiring manager for those roles, so I’m not 100% sure. If by “can come in hot” you mean people with existing Elixir experience, then based on who we hired I’d say that previous experience would have been required.
I find being a "builder's FP" more true of something like Rust than Elixir, in my experience. This is mainly due to the lack of static and algebraic types in Elixir, which makes debugging very difficult, as well as more annoying to reason about the problem domain, because you can't represent it in types as well.
> lack of static and algebraic types in Elixir, which makes debugging very difficult
In about 6 years of working with Elixir, I've found it easier to debug than pretty much every other language I've ever worked in. But to be fair, I've mostly been working on code I've written myself in that time (although you'd be surprised what you forget in a year and then go back to).
You can also add typespecs; I know it's opt-in, but it's something, and it will get checked.
Algebraic types are orthogonal to functional programming.
Functional Programing can be static or dynamic.
Also, Rust isn't an FP language, per say, it has way more in common with the imperative programming paradigm with some ergonomics lifted from the ML family of languages, specifically around it's type systems.
Answered already, but in $previousjob we had a team named that, for the reason given. I thought it was kind of clever but unique - 3 jobs hence I work for another company that has the same, so maybe more ubiquitous than I'd thought.
I think people who are earnest about the sentiment aren't screening specific languages. They're trying to find people who think hard about business problems and follow with implementation.
We do this. Our hiring process is impossible to pass for people who fixate on implementation. We have people do a simulated building exercise, and the developers that do well let the user needs drive the implementation.
We think we've noticed a correlation between some dev communities and people who lead with implementation. We've seen a little of this with Elixir, but I'm not really worried about it. We've found a number of people who really enjoy Elixir that are also user-first.
> Anyway, I did take a non-eng role there, and it was easily the worst and most abusive (like verbally abusive, psychological abusive, generally fucked up) places I've ever worked.
Sorry this happened, but it’s a good lesson for everyone: If interviewers do anything resembling “negging” in an interview, they’re trying to push your limits and see how submissive you’ll be.
The founder may not have cared about Erlang. He just wanted something to attack you with.
Some people think that lightly insulting people is a way to get them to work hard to prove their worth. It does work on people for a while, until they realize they’re being used and abused.
I would just stress to folks that red flags go both ways. If the work environment seems toxic from your experience as a candidate, chances are it will only get worse once you join.
> The founder told me that functional programming is a joke and that I'm clearly a computer scientist and not an engineer, and told me he'd never hire me as an engineer.
Man, that would have left me with such a bad impression that I would have ended it right there, no matter the role.
That said, I've taken jobs where I had to in order to eat, and at least one of them ended up being shit, so I empathise.
Yeah I almost cried partly because it was so unexpected, and partly because I was so desperate dealing with lots of housing instability, and this was one of the first companies that even reached out to me for an interview. I wish I had more of a spine back then because that ended up being hardly the worst of it
In a way I'm glad to have gone through it -- I think it's helped me to be a lot more compassionate in situations when I have any kind of leverage over another person, and it taught me precisely all the wrong ways to treat people in general. Probably most significantly, it showed me that there are major costs in committing to fucked up people, costs that might not be obvious at first. Like you can think you're aware what you're getting yourself into, you can tell yourself it's just for a paycheck, but if they get inside your head at all, you might be dealing with that shit for years. And you can be sure that predators like that are all about getting inside your head
Is there something about Erlang itself that makes it an attractive FP language for you, or is it the environment (Beam, OTP)?
As a web dev, I find the performance of the system and concept of the actor model appealing and interesting, although admittedly I lack an in-depth understanding.
I found the language to be too high a barrier though. This includes Elixir. http://efene.org/ looked promising, but when I tried to install it, I had some issue with something being outdated. Gleam is the next thing to try, although the more I read about it the less I understand, lol.
I've done some toy Elixir things and I really like it; not enough to get hired but enough to like the shiny packaging. (It might be that shiny all the way down, I just don't have the experience to say.)
Gleam though... that looks more to my liking _syntax_ wise. Familiarity more than anything, but might try some toy stuff on it soon.
BEAM interests me immensely from a user standpoint; I'm just wondering how much time it has in the world vs. containerization and orchestration.
Haven't heard of efene yet; thanks for that. Now my Sunday's ruined =D
After ten years of using Scala, I think if I was running a Scala team, the safest thing would be to hire people who are not excited about Scala. Like it, yes, but not be super pumped. Developers who are primarily motivated by the excitement of learning new technology tend to write code that commits everyone around them to learning just as much, just as fast, which obstructs and pisses off developers who are primarily motivated by getting shit done. A team needs to strike a healthy balance between powering up with new ideas and getting shit done, and having people in the team who skew to one side too much to either side of that balance is a recipe for conflict. Eventually people will leave, often highly productive get-shit-done people, unless you fire the disruptors first.
As an ex-Scala developer I feel like Scala is also the worst language in this regard, even compared to more academic languages. At least Haskell is somewhat prescriptive; in Scala people continually invent new ways to do the same thing. How many iterations of dependency injection or IO are we at now?
Ruby is another language where I wouldn't want an unrestrained/undisciplined amount of smart/clever code.
My impression of Scala from a few years ago was that the language itself was so flexible (ranging from 'not quite Java' to 'not quite Haskell'), that you'd really want strict adherence to a particular style (or set of features) for a codebase to have hope of being maintainable.
I love and hate ruby for this reason. I'm working in it now, and it does allow some really fast-to-ship coding, but some of the LargeBrainedOne's framework stuff is so weirdly overly abstracted and metaprogramming'd ...
They'll write 500 lines of inscrutable framework code to save having to write 5 lines of boilerplate 3 or 4 times.
I’ve had the good fortune to work at a small place where the understanding between R&D disruptor types and get-shit-done GSD types was pretty good. When R&D types contain themselves/keep the playground from spilling over until whatever they’re playing with is ready/explored, and the GSD types don’t bulldoze the playground and let it feed them new tools/approaches/ideas when ready, it’s like an organization level flow state. Wish I had a formula for how to replicate that, is magical.
In my experience, the failure mode for "GSD" is more likely a thoughtless approach of pumping out code, without consideration for efficiency or effectiveness towards providing value.
There is the other end of the spectrum though, where people who overwhelmingly focus on getting it done, quite often, don't apply the requisite care to the code. I encountered an actual example of this, where devs were copy pasting hundreds of lines of code, no functions/methods with liberal hardcoding to scores of scripts. Each had the same warts since they were all copies. They all got the shit done while nobody bothered to clean up the mess into reusable chunks.
As a new member of the team, I took the opportunity to cleanup when I got a similar assignment, which took an extra day. Subsequently when another dev had to do a similar task, he used my setup and basically had to make changes in 3 config lines which took a minuscule fraction of what he would have spent doing copy/paste and modifications. He was happy and I was puzzled why none of them bothered to do it for so long; my cleanup wasn't rocket science and any of them could have done it.
What are you doing running a company that uses Scala without having people who largely know the stuff already, though? Regardless of how quickly some newbie learns, the senior folks should already know all that stuff, or at least most of it. If they don't, that's the actual problem.
As someone who works on a legacy scala codebase, Scala's an easy language to get into this situation with.
Scala's flexible enough that the old lisp pitfalls apply (though not nearly to the extent of lisp). That is to say, learning the language itself doesn't necessarily mean you're going to have any sort of grasp on a particular codebase, or even a different part of the same codebase.
There's a particular style of scala that involves bringing in and stringing together dsls. Which is both extremely powerful, and can make code completely unreadable to someone who doesn't know that exact combination of packages.
If you're not careful, your bus-factor is 1 and even the other seniors won't have any idea what's going on right away.
> There's a particular style of scala that involves bringing in and stringing together dsls. Which is both extremely powerful, and can make code completely unreadable to someone who doesn't know that exact combination of packages.
This is main point which, more often than not, turns out to be a negative for Scala (there could be specific circumstances where this may be a big positive but, usually not).
The rule of thumb for me for Scala code is, only follow constructs/idioms/style mentioned in the Scala Book[0]. Most of the time, everything else is unnecessary trouble.
> there could be specific circumstances where this may be a big positive but, usually not
I mean, I think that those circumstances would be a solo passion project.
I still think scala is a beautiful and expressive language. But I think that expressiveness actually inhibits collaboration. If you're expressing novel thoughts in a novel way, you've added syntactic overhead to the already significant conceptual overhead.
So, yeah. Quite personally rewarding, but I can't recommend it for a work project in good faith after having worked in it. Enterprise projects should probably use java/kotlin if they want to be on the jvm, or go/python/js if they don't.
Most hiring rules have notable false negative rates and that's fine because you have multiple applicants per position and because getting it wrong can be very expensive.
Personally, I think being excited about a cool language is a mixed signal. An interest in technology is great, but on the clock that has to be thoroughly suppressed in favor of actual business needs and constraints. At home, I like fucking around with all sorts of stuff. At work, I'm a confirmed member of the Boring Technology Club. [1]
If you think that a technology/language/etc is cool and better than the rest but it is not as common as <mainstream thing>, of course you’d be excited to learn that a company is using it.
If you’re a company that chose a very niche language because <a number of reasons> and discard an applicant because he likes the same very reasons, LOL, you’re a bunch of idiots
Well, they're moving away from said language, so why would they want to hire someone who joined because they liked Elm but then doesn't get to use Elm at work? They're more likely to leave the company than someone who doesn't really care so particularly about Elm (or whatever language or tool it may be). So in OP's case, it's a sound business decision.
Adversarial take: if your company says it does Elm, then hires people (who took Elm as part of the decision of joining) and then decides to stop using Elm, why should we push the guilt of leaving to the employee? I mean, it looks a bit like bait-and-switch, and "We the company altered the deal, pray we don't alter it any further".
How is that employees should be loyal to any decision upper management does? What's the limit? What if the company decides to go into JBoss/JQuery? What if the company decides to stop doing software altogether? What if the company becomes a mercenary army a-la-Wagner? Where do we place the line between employee is guilty for not continuing/company is guilty for changing everything that matters?
I think you're reading guilt where there is none. I just mentioned that it's a sound business decision, as well as a better decision for the employee who likes Elm, to not hire people who like using a tool your company no longer uses. There's no guilt on either side, it's just pragmatism.
I totally agree. I engraved Angular 2016 in our Tech Stack. Fast forward 7 years now, and we are on Angular 14.
Accomplishments so far? Large and stable platform as well as a Low Code Editor on top of it. We systematically componenized every useful piece of Frontend there was and evolved from a library into a platform, while other departments jumped ship every now and then (jQuery, React, Vue, etc.). After years of resistance all finally joined out platform, because it is fast, stable, convenient.
Moral of the story: consistency is everything. A tool is a tool.
For sure. I used to be a real tech snob. And I still like experimenting. But I've had to admit that the particular technology used just doesn't make the difference I would like it to. E.g., PHP is a "fractal of bad design" [1], but Facebook seems to be an ok business. Or Javascript was clearly a frightful hack job to start, barely adequate for mouse rollovers and a little form validation, but now you see plenty of companies doing fine using it front end and back. These days I would much rather have a good team and a good culture than my favorite technology.
Facebook hired dedicated people to invent their own hack-language over PHP to deal with PHPs problems.
Sure, a business can succeed with a crappy language. But that doesn't mean the language has no impact, otherwise Facebook would have just sticked to it.
I don't believe that I said language had no impact. What I said was, "the particular technology used just doesn't make the difference I would like it to".
Agree completely. I prefer react over angular, but when you have everyone working with the same tech stack, and all of your apps look the same, it's very easy to always be productive. How does service x work? Oh, just like the last 3 I worked on. Context switching isn't just expensive in the short term, it's expensive over weeks and months for these kinds of decisions.
Because you're looking to thin it differentially, such that the odds of a good hire go up, or at least the odds of a bad hire go down. One kind of bad hire is the technology-lover who values their own preferences over the needs of the business.
E.g., a friend of mine took over a team with a couple of strong FP advocates on it. They had written a core tool in very FP-ish JS. They enjoyed the novelty of the greenfield work, but once it was down to just making the changes users needed, they got bored and moved on. The remaining part of the team tried picking it up, but it was too alien, either because of the FPness or just because the code was opaque. Either way, they eventually had to rewrite it.
Or personally, I have made a lot of good money coming in after some would be brain genius, ripping out their supposedly cutting edge work, and replacing it with something boring. I remember one place where a core part of a system was build on the 0.7 version of then-fashionable technology. Except it wasn't even 0.7 as released, but something with custom patches applied. None of the people there could maintain it. Looking at git blame and doing a little web searching, it turned out the developer responsible had then done a self-promoting conference talk about their amazing work, and then quit shortly thereafter. After I removed it and replace it with something much simpler, not only could the people there maintain it, but it worked better than before.
> Because you're looking to thin it differentially, such that the odds of a good hire go up, or at least the odds of a bad hire go down.
I'm certain you could increase the odds of a good hire in all sorts of other ways by seeking correlational stereotypes, but some of those (age, gender, race) would be seen as... very bad, possibly illegal, and some others (traditional-ness of first name, for example) would possibly also work but would be highly questionable. Heck, I bet you could find a correlation with whether or not the person used an AOL email address or not. What makes filtering by this stereotype correlation superior, ethically, to those other stereotype correlations? If "interest in new tech" is an immutable attribute of the person's personality (which it almost entirely likely is), then in both cases you're filtering based on immutable attributes, so they should be considered ethically equivalent on paper, where you have a lot of false negatives, but your "good hire" rate goes up.
> One kind of bad hire is the technology-lover who values their own preferences over the needs of the business.
So basically you want to hire non-technology-lovers who simply "GSD" and don't care about things like long term maintainability or test coverage (or test runtime, or code quality, or...) because at the end of the day that's just added fees you can charge to the client when you have to revisit the codebase in the future. I see.
> So basically you want to hire non-technology-lovers who simply "GSD" and don't care about things like long term maintainability or test coverage (or test runtime, or code quality, or...) because at the end of the day that's just added fees you can charge to the client when you have to revisit the codebase in the future. I see.
No, you have it exactly wrong. What you describe are good development practices that provide actual long term business value. What you want to avoid is someone saying "yeah I'm excited to use the nested lambdas and variants and callbacks and asynchronous systems" because this shows they just want to play with toys, not solve problems the business has like too many bugs, or slow runtime, or missing features. Engineering is about solving problems, and technologies are tools to solve them.
> What you want to avoid is someone saying "yeah I'm excited to use the nested lambdas and variants and callbacks and asynchronous systems" because this shows they just want to play with toys, not solve problems the business has like too many bugs, or slow runtime, or missing features.
How does that sentence show that, exactly? All it shows is that they're interested in new technologies. That says nothing about whether or not they are interested in "[solving] problems the business has like too many bugs, or slow runtime, or missing features". Those two are not mutually exclusive; one can certainly care about both.
Taking it a step further, who gets excited about "[solving] problems the business has like too many bugs, or slow runtime, or missing features". That certainly sounds like what someone would say to please their interviewer more than anything.
On its own, it doesn't. But if they don't show some interest in what the business is doing as well, it's a red flag, because they will probably end up building something the business doesn't want or need, or fulfill requirements without foresight or understanding into future business direction, but rather based on what they find stimulating (aka more complicated than necessary, at the limits of their understanding).
> Taking it a step further, who gets excited about "[solving] problems the business has like too many bugs, or slow runtime, or missing features". That certainly sounds like what someone would say to please their interviewer more than anything.
Anybody working in a small team where you have embedded people from all aspects of the business and work together to make the company successful.
So, me, and everyone I'm interested in working with?
If you're in a giant company and the only satisfaction you can get from your work is the toys you get to play with, to me it's just a sign of corporate disfunction and misalignment between business and engineering.
But interestingly, some of those examples you cited are literally solutions to some of the problems you cited, so... For example, a language like Elixir that has "trivial concurrency and immutability" enables a test suite that can run across all of your cores at once and is deterministically guaranteed (assuming you watch how you touch shared mutable state outside that code, such as a database) to not step on itself while doing so. Compare this to any one of a number of mutable languages (such as Ruby) that claim concurrency but in actuality often contain deep software bugs that result in flagging, nondeterministic tests UNLESS they are run single-core. That is absolutely a solved engineering problem that then may prevent other mitigations like having to run the test suite across 25+ cloud machines (in single-core mode) and waiting 25 minutes for a test result before being able to continue, which then directly increases developer productivity.
Also, being interested in those 2 things is not mutually-exclusive. I LIKE that this is a tangible business result of a fundamental language design decision.
If you can explain why you like them in terms of business value they provide, in the context of the specific problem this code is meant to solve, then I agree.
But without these, it's like hiring a construction worker who will use any excuse to use a backhoe, even when it isn't suitable, just because they love operating it. It's childish and unprofessional, and as an employer, even if you have full time backhoe work for them to do, you want to avoid hiring them, because they'll probably cause a lot of damage to your building site driving the backhoe everywhere when someone else with a wheelbarrow would have been more suitable. Their excitement clouds their judgement about the efficacy of their tool of choice, and they will apply it when it isn't optimal.
Elixir is great for massively parallel web facing problems, and if you can explain it as a tool you have in your toolbox for solving this kind of problem then great. But if you say Elixir is awesome and then want to use it to generate graphs from CSV files for internal business metrics, you've lost me.
> But if you say Elixir is awesome and then want to use it to generate graphs from CSV files for internal business metrics, you've lost me.
uhhh, so Elixir is a general purpose language that solves everyday problems. and just happens to havethis phenomenal almost "no-code" solution to literally the problem you just presented, with Elixir Livebook.
...
The VM is 35 years old. The syntax is Algol inspired, the Elixir syntax is 10 years old, FP as a paradigm has been around since 1958.
It's not some new and shiny toy, it's simply unfamiliar to you.
I think the majority of programmers don't have that problem, especially with semi-regular discussion/contact.
In the past, when I really wanted to try something and the boss didn't agree with spending work time on it, I spent my weekend time on it (back before I had a kid- Seems like a luxury, now!). Most of the time, I came up with something I could demonstrate on the following Monday which got accepted. Sometimes, it didn't, or my hunch/effort was unsuccessful (but I wasn't unhappy because at least I tried).
Being able to run a test suite in parallel on your own machine is massively more useful than having to run it across a bunch of machines in the cloud. First of all, clouds go down (the external-dependency problem), or become unavailable when Internet isn't available (and also cost extra money). Secondly, you get instant (more or less) feedback on whether you broke anything, and that allows you to maintain velocity without having to backpedal. Thirdly, if the suite is run concurrently in a deterministically-random fashion (where it outputs the seed before the suite starts), you can often identify reproducible concurrency bugs that will NOT (or be very unlikely to) show up on your multi-VM cloud test runner (which run all the tests single-threaded on separate machines). Fourthly, if we're talking a functional immutable language, those types of bugs (which are some of the worst and most costly of bugs to track down and fix... I know this from experience, a nondeterministic session-loss bug at Desk that it took me a month to fix likely lost thousands of customers, not to mention the cost of essentially benching me for a month plus the benching cost of the previous devs that took a stab at it and failed) are rarely found to begin with.
Every one of these leads to either more productive employees, lower ongoing costs, or happier customers. How are these not tangible business results?
Oh I agree with the potential technical benefits. I think the business justification is pretty weak, though.
The business benefits you listed are defensive. That is, if the business is doing well, those are things you might optimize for. The same way you'd, say, try and decrease power consumption.
There are companies where an order of magnitude decrease in ongoing costs opens allows a whole new kind of product. But order of magnitude increases in the things you just listed are rarely developer process improvements or refactors.
Customer happiness is a fun one. If you have a buggy or unreliable app, you'll frustrate customers (I am very aware of this, if you check my post history). You won't _make them happy_ just by building reliable software though.
As someone whose #1 priority is reliability right now – fixing bugs faster very low on the list of things that matter. The problems users have with our platform are a combination of the wrong architecture, and non existent tooling for customer communications.
Which gets back to the original post. We want to hire devs who can identify out what our users need most today, figure out what we can do about it (if we can at all), and then implement what makes sense.
I see your points, and were I at a company currently (I'm looking), I would prioritize the business-leading things, of course.
> #1 priority is reliability
Yeah, mine is too. (In fact, I think we're approaching a crisis of reliability out there, if we're not there already.) That's why I went with Elixir, and it's paid off so far. The only time the site's been down in years is due to my hosting provider, not me... (So of course I'm looking for another hosting provider...) I have to deal with the occasional 500 errors as well, which, as it turns out, are also largely due to my hosting provider and not my code (but sometimes my code...).
The thing I realized about reliability way too late is this: The utility of a service (or a person) to a person drops off VERY quickly if you dip below 99% reliability (or arguably, 99.9% reliability). Something (or someone) that is 90% reliable is practically useless, because it is bound to fail at the worst possible time. So in all the software I write, I focus on this, and in all my relationships with people (or orgs, or bosses, or my son, or my S.O.), I know that if I commit to them, I must be as reliable as humanly possible because the costs of every slip-up are huge and rise exponentially as they accrue.
An example of a service that is just unreliable enough to be a huge annoyance (which has also caused bad communication failures as well in my experience) is SMS. SMS failures are the worst.
I am too stuck in single thread front end integration tests to be able to relate. Are you actually talking about testing full stack or just some backend tech. We almost never have problems with our cloud testing, it is expensive. We need it to have some control over the front end work, benefit is that running the back end stuff is trivial and fast.
I have a design bias- I pretty much refuse to build anything for the front end that is not easily testable without using a headless browser as part of my test suite. Headless browser driving adds so much more resource consumption and time to the test suite over time that it defeats the entire purpose of a test suite, which is to (as quickly as possible) assess if any logic in the app has begun violating expectations, so you can proceed with building the next thing quickly without backpedaling and without waiting.
I completely understand that individual browsers may have this or that problem or idiosyncrasy and that may need to be tested but I'd put that in QA, not your official standard app test suite. At the most I'd test whether endpoints actually spit out HTML, CSS etc. but not actually check the rendering step. I do have a JS suite as part of my full test that uses jsdom to check DOM manipulation but it is only because it is not resource-intensive and runs fast.
> One kind of bad hire is the technology-lover who values their own preferences over the needs of the business.
OK. This is not a mutually-exclusive relationship. One can prioritize both of these; the best team player will prioritize the needs of the business (and the team) more, however. This to me seems like you're really addressing the problem of "vanity/primadonna devs" who are not team players, and not just devs who really like certain technologies which will possibly blind them.
I also think experience tempers this quite a bit. I've certainly had dev experiences where I became enamored with an idea or trendy tech, felt I absolutely had to implement it, and then ended up regretting it later. I think this happens a lot with younger devs and that's OK because that's how you learn. (Make sure they get assigned the mess cleanup when it doesn't work out though. LOL)
At hiring time, it can be very hard to tell the difference between "vanity/primadonna devs" and "devs who really like certain technologies which will possibly blind them". And even among the latter group, there are tradeoffs in hiring them. There are many reasonable places to set the dial on how much a hiring manager wants to take risks on that. But I maintain that, as with many other hiring criteria, erring on the side of caution is a reasonable choice. As I said, I think being excited about a cool language is a mixed signal.
There’s plenty of code that can be so complicated that it becomes easier to rewrite versus understand. I worked with a coworkers who made the most absolutely spaghetti-like JS modules, insisting on event emitters and queues and stuff like that for even the most basic tasks. The result was an incomprehensible mishmash of events shooting from file to file to file. Touching how these events were handled in some way might destroy how they were interpreted for completely different tasks, it was wild. It’s very possible that the code in question wasn’t just opaque because it was “FP-ish”, giving the parent the benefit of the doubt.
Depends on what you mean by "FP-ish". I never saw this code, but the way this was described to me as high church FP, the kind of people who really wanted to be working in an ivory tower FP language and so had coded as if that's what they were using.
I don't think it's unreasonable for average Javascript programmers to look at that and say, "WTF", the same way that they'd look at code from somebody who wrote C in Javascript.
I mean it depends, right? There are several technologies out there that are fantastic because they are less annoying, have fewer footguns, easy to debug, easy to read, good tooling (docs, tests, package management), and respect the programmer's sanity. Is it wrong to only want to work with such systems? If some company rejects me because I'm a tech stack fanboy without asking and understanding why I care about the stacks that I do, that means they don't respect my sanity. Hate to say it, but most "boring" technologies with a legacy from, say, pre-2000-ish, cared zero about those things.
So, great. Buh-bye.
Nb: many technologies post-2k also don't care about those things. So yeah, don't be shiny new on those either.
Sure, but you're now evaluating the technology in business terms. That's very different than somebody who loves the ideas of a language. I don't want to start a language war, so I won't name one. But consider all the developers who were very excited about "blockchain" not because it improved anything practical for their projects, but because it was a hot concept.
The point is there are languages where the "ideas" of the language are these "business" ideas. Technical choices can also lead to good/bad developer ergonomics.
Do you really believe that there's an experienced developer who doesn't believe, "Technical choices can also lead to good/bad developer ergonomics"? Maybe try assuming I already know the basics of the field.
> Most hiring rules have notable false negative rates and that's fine because you have multiple applicants per position and because getting it wrong can be very expensive.
I think it depends on how you define "fine". Perhaps "fine" for the hiring company, but it externalizes the cost of wasted job leads for candidates.
It's funny because that slide shows why we use Elixir. With the clustering BEAM offers out of the box we've been able to eliminate things like memcached, redis, and rabbitmq from our production environment.
But most people wouldn't call Elixir "boring tech".
This is the right attitude. I make a conscious effort to find reasons not to use a technology in excited about at work because my excitement otherwise will bias the decision in the other direction.
He doesn't go into much detail here but what I _imagined_ he meant was that if someone came to an interview excited about Elm but knew nothing about the company, that would be a strike against them. If someone came excited about Elm _and_ was interested in the company's product that was fine.
But this is just me filling in the blanks as I think they should be filled in. It'd be great to see him spell this out a bit more.
> If someone came excited about Elm _and_ was interested in the company's product that was fine.
We're talking about a company that makes workplace engagement surveys. I have trouble imagining anyone is actually truly excited about that product. No 5 year olds ever said that they want to grow up to write engagement surveys. They aren't saving the world.
And that's ok. Most products aren't very exciting when you get right down to it. One of the most toxic beliefs in tech companies is that everyone should be obsessed with the product.
I had a leader once who told us outright any mention that Haskell was a motivation for the job is a red flag. He explicitly didn't want people who were significantly interested in us due to our Haskell use. Turns out Haskellers tend to be drawn to Haskell companies in no small part due to Haskell, so we failed to hire basically anyone after the leader came aboard (most were all yes but a single no from the leader) and then the leader pushed us to move off Haskell citing difficulty hiring and that he had hired people in another office who didn't know or want to learn Haskell. Dirty tactics.
> I had a leader once who told us outright any mention that Haskell was a motivation for the job is a red flag.
> then the leader pushed us to move off Haskell citing difficulty hiring and that he had hired people in another office who didn't know or want to learn Haskell. Dirty tactics.
Oh definitely. There was even more bad actor nonsense too but I don't wanna say to much or else I sky demask myself. But I promptly quit and the dude went from buttering me up to to make me stay to insulting my new job in the exit interview real quick once I made it clear I had no interest in being his employee. I had never experienced someone so manipulative in a workplace before.
If my current employer hired this dude as VPE, I would immediate quit. Just an asshole.
In our interviews one of the things we look for is people who care about our mission (improving workplace cultures, basically). Its not a requirement but it is one of the factors when it comes to making a decision, particularly if we have more qualified candidates than roles.
> If someone came excited about Elm _and_ was interested in the company's product that was fine.
I'd even say if someone is excited about Elm _and_ was interested in making a great quality product (great UX, accessible, performant, maintainable etc.) that would also be a good fit.
I also mentioned above that the engineers we hired to work on features that happened to have Elm front ends would have been working on Ruby on Rails backends most of the time, and we generally expected engineers to be willing to jump into both sides of the stack, even if they specialised in one or the other. A person who is really excited about functional programming and joining only for the chance to work in functional programming languages might end up grating against working in a rails codebase. That's the sort of practical thing we were trying to avoid. (The same would be true today for candidates who are super excited about TS / React / Next.js - they're still going to be expected to occasionally jump into whatever backend stack their team is using).
Be honest though, I'd say a good 95% of jobs are literally something I could give 2 shits about or I have absolutely 0 interest in what their core offering is. I have rarely worked in a place where I was "excited" about the company or its mission.
Sometimes the tech stack itself IS the interesting part of the job or there were interesting problems to solve, but the company itself?
Sorry, I honestly don't care outside of the paycheck.
I'm not suggesting people have to care deeply about the company they work at. I'm just saying that I'd expect people to come to an interview having read the company website and job description. That's all.
It does feel like a landmine they've set up, perhaps another benefit for them of moving to React is that they can stop worrying about it?
I've seen a lot of companies that superficially resemble Culture Amp. I've seen one that uses Elm. I'm probably going to come in talking about Elm.
I have some sports-related decoration in my living room. It would be a weird experience for someone if they came in, saw it, started discussing sports, and I was put off by that.
Besides, it wasn't liking a particular _language_ they took as a bad sign, it was _functional programming_.
If you like functional programming, and you encounter a candidate who also likes it, and you consider that a red flag ... that seems highly irrational and inconsistent.
(Not trying to sound combative. I appreciate the original post! Just being candid about something that sounds odd to me).
Edit: I would bet there's more context that was out of scope for the original post. I would not be surprised if it were much more than just "liking functional programming." If someone is overly zealous to the point where you might wonder if they'd start an uprising or storm off in a rage if asked to do anything other than functional programming (or anything else for that matter), that would be a red flag.
I think it's the over-zealous part. If someone can't name a few cons of some technology relative to its competitors, they probably don't have a balanced perspective of when it should be used and when not.
I’ve twenty plus years experience building software on the JVM. From EJB’s of early 2000s to original Spring, then the more recent Spring Boot, a plethora of other JVM tooling. Then I’ve used various languages on top of the JVM, Groovy, Clojure, ETA, Scala. I haven’t used Kotlin only because not had a role that needed it. Then I have a list of non JVM languages, frontend stacks and sysadmin/cloud or as they like to call it DevOps
Scala has been my JVM language of choice for the past ten years.
When I was last applying for jobs my experience with Scala seemed like it was a huge negative for the companies I interviewed at. It was “you’re one of them” and things got frosty after mentioning I’m reasonably experienced in Scala and its functional programming libraries and enjoy it as find I have less bugs.
If I removed Scala from my cv and never mentioned it I got a much more positive experience.
Some of the roles I didn’t mind it going frosty. My red flag radar went up aswell and I got the sense of big balls of mud and I’d probably hate it but needed a job. Some it was a huge disappointment, exciting company, exciting projects, perfect fit skills wise but I was seen as a Scala developer not a great fit for Kotlin as excited as I was to use it because of the companies projects.
Not sure what I’m trying to say but this “not good fit” attitude doesn’t seem uncommon if you have used specific languages/tools/things people interviewing you don’t like or didn’t grok. Tech talks a lot about diversity which is mostly virtue signaling and forget diversity of minds is also good.
> It was “you’re one of them” and things got frosty after mentioning I’m reasonably experienced in Scala and its functional programming libraries and enjoy it as find I have less bugs.
You made people feel bad for not questioning their preconcieved notions... that's a nono! :(
I run an OCaml project, but I would reject interview candidates who say they are primarily interested in the project because of OCaml. It's definitely a negative factor in the evaluation. I don't need someone adding baroque functional programming purity into a working project with real customers and regular developers. Plus there's a vast amount of C code which is not going anywhere, so I assume they would hate dealing with that.
There's a well-known phenomenon where a person who has just learned a programming language will tend to write code that resembles the idioms of a different language that they have more exprience with, until they learn to write properly idiomatic code in the new language. For example, someone coming to Python from Java might write so-called "Java-flavored-Python" until they become more familiar with how things are generally done by experienced Python coders.
Your comment comes across to me as "I run a project written in C-flavored-OCaml, and the last thing I want is for someone to come along and pollute it with properly idiomatic OCaml". Because otherwise, if you had good reasons to choose that language, and your code takes advantage of the language's strengths, wouldn't the code already be "baroque" to some degree? Why would you assume a new person would make it worse?
That's not what it sounds like to me at all. To me it sounds like they have some FFI into C and that OCaml may just be a part of the larger project. There is nothing that indicates that they write "C-flavored-OCaml."
You can look at the project yourself: https://github.com/libguestfs/virt-v2v I've been writing OCaml for 20+ years and C for 40 years, and other contributors have similar decades-long experience in programming.
I'd likely fail that filter, but not for love of baroque fp purity. my career has largely tended to be at the bottom of the stack, building the bricks that other team members use to build features, and I would be excited about ocaml because I think it gives you good tools to build solid and composable components. I would also do good work in the C part of the codebase if needed, I just wouldn't be excited about getting to work in C.
It's more that it's a negative indicator. From time to time when we advertise a job we get a candidate straight from a university research background who can't wait to tell us how they love functional programming. We always pass on these.
Yeah, that seems like a weird rule to have. If anything, I’d want engineers to be excited about languages, tools and paradigms, even if they weren’t exact fits with the current stacks we’re using.
The whole article’s point is that these change, anyway. So those people they’re rejecting on this silly rule might eventually become the people they crave if functional programming becomes cool again at Culture Amp in 5 years.
That would be reasonable if the post put it that way, and said they ask lots of additional questions and back and forth to determine this specific thing.
But as it is stated, it just seems like an overly broad rule that will hurt more than it helps in the vast majority of cases.
> if functional programming becomes cool again at Culture Amp in 5 years
I think that's kind of the thing they're actively trying to avoid. They don't want one type of programming to become popular and have the team decide to spend $X and y months and switch to it because it results in increase in some nebulous programming productivity or whatever because they hired a bunch of z programming paradigm fans, and then later spend more money and time to switch to another thing etc etc when the importance of programming language or frameworks on the making money aspect of the business is not clear at all.
But functional programming might be the best choice for some project in the future. And this whole decision just seems like an overreaction.
To discount candidates entirely based on their excitement about one paradigm (saying nothing of their excitement of others) seems like it’s just pushing the needle to the other extreme.
(I'm a front end engineer at Culture Amp, and have been involved in hiring)
Perhaps the wording in the blog post is too strong, because people in this thread seem to be interpreting it as a hard rule. The wording was:
> When someone tells us in an interview they’re excited about working here because they like functional programming (say), we count that as an indication they might not be a good fit.
When we do interviewers each person fills out a scorecard for the candidate with several criteria: things like technical skills, communication, UX thinking, interest in the company product/mission, etc.
Under "technical skills" I would usually have counted interest in Elm as a positive, as long as they weren't expecting to only write it. As I mentioned elsewhere in the thread, they'd also be likely to be contributing to Ruby on Rails codebases... so they better be open to, and maybe even excited by, different paradigms, because that's going to be part of the job.
Exactly. Idk if anyone here has used Culture Amp, but from what I've seen it could be built with any boring framework with a form builder (Django, Symfony, etc).
Especially since it's Elm. How many people would have any idea how to even use it & not mention that they're excited by it an interview? Counting that against someone is probably an even worse interview practice than being overly reliant on leetcode. And I hate leetcode driven interviews.
It also seems like the type of bullshit people would spout when asked "why do you want to work here". (Real answer is because i like money, but you can't say that in an interview, and talking about language is generally pretty safe)
To be honest, I don't ask this question, because of this. Why ask people to lie? Better talk about their interest and how we can both benefit from aligning them in the context of our tech stack.
It is a job, not a religion. I want to work at X due to some combination of having skills that match their needs, room for growth, reasonable work culture and reasonable compensation. Just like everyone else who applies. I am not going to have some deep seated emotional attachment to the company, and i am definitely not going to have it at the interview stage. For that matter i might not have even heard of the company before seeing their job advert. My knowledge of what the company is really like at this stage of the game is very limited.
Because it's 30 minutes from where I live and the office seems friendly. Most people in the world choose their job for prosaic reasons and because they need to pay rent, they're not on some heroes journey. Employers in the software world need to stop it with the self-inflated ego. You have firms out there who write ad software for billboards and they'll ask you whether you truly believe in their mission during an interview
Thousands of companies that have openings for positions that match your skills, that advertise at a time when you are looking for a job, and that are roughly within your reach (geographically or sponsoring a visa)? I don't believe you.
> I understand the kind of person they’re trying to avoid hiring by accident
I think I might be that kind, firmly in the ivory tower.
I always feel frustrated and isolated because people just don't engage and acknowledge my concerns. I post in a busy Slack channel that the new API we're developing wont respond in less than half a second on my own computer, I ask if my setup is wrong or if our API code is just slow as shit. Nobody answers, but it reinforces my role as an ivory tower trouble maker. Two months later everyone is panicking that the new API is slow as shit. Or I find that our test database has a millions of plaintext passwords from real users (yes, some of you reading this were probably included), after arguing that this is effectively a data breach and we're failing our customers I finally prevail, and we wipe out the passwords from the test database at least, but this causes some extra work fixing some automated tests. Again, I did the right thing but in the end I was viewed as a trouble maker. Etc. This reflects my entire career. It just feels like something is wrong with the industry.
> I always feel frustrated and isolated because people just don't engage and acknowledge my concerns.
I've adapted by expressing only my highest concerns and making myself not care as much, honestly.
The amount of this you have to do if you're this type varies from place to place in my experience.
> I post in a busy Slack channel that the new API we're developing wont respond in less than half a second on my own computer, I ask if my setup is wrong or if our API code is just slow as shit. Nobody answers, but it reinforces my role as an ivory tower trouble maker. Two months later everyone is panicking that the new API is slow as shit
Then if you bring it up you're just dragging everyone through the mud ;)
Anecdotally in interviews, it seems that most people that say that they like functional programming, tend to like the idealized notion of functional programming more than actually building real-life systems with it. When asked about their past experiences with functional programming you'll rarely hear about anything else than toy projects (in contrast to other things people often list as things they are "excited about").
Connected to that (anecdotally) when working with them, those same people tend to be the ones that try to make the code "clever" or overly perfect (in an attempt to fit into the ideal functional programming paradigm). That usually leads to code that's extremely hard to read and maintain as a team.
I think full functional programming languages can have its niche, but I think most projects are better served programming languages that only borrow from functional ones in certain aspects of the language/standard library.
I agree that this sounds concerning, but in the context of the article, I see where it's coming from. They identify as a "product organization", not a tech one. They want people who are more excited about the problem they are solving than the tools they will use to solve it.
It reminds me of an article I've seen that talks about how companies have such generic "values" that they're not even worth having. Innovative? Well, of course. Integrity? Duh. Better values would be those that not everyone will agree with because it tells you what that company actually stands for. "Product over Tech" seems like a great one.
Anyway, as someone who has definitely been super intrigued by FP, I was initially alarmed by this comment, but understood it better after some thought. After all, he's not saying it was a litmus test, just something they noticed that might be a hint for who would and would not work well at this particular company.
I work at Culture Amp and have been involved in hiring decisions, including for people who were excited about Elm so happy to comment here. As others have guessed, this is an "indication" not a "rule", and it was more about people who were applying _only_ because of the tech stack, rather than a sense of wanting to build a quality product, or alignment to the company's mission (improving workplace cultures). We hired plenty of people who mentioned Elm. I mentioned Elm in my interview.
Part of the reason for this is very pragmatic: during the time when Elm was in common use at Culture Amp, almost all of the APIs that Elm would have been talking to were written in Ruby on Rails, and our engineers were expected to be able to contribute to work that required changes in both the Elm front end and the Rails API. If someone was a functional language purist, and only wanted to work in say Haskell on the backend... then they wouldn't enjoy being on one of our product teams where writing Ruby on Rails code was part of the day-to-day.
I felt the same and wondered what the right answer would be. I generally haven't interviewed at companies where I didn't know enough about them to be excited about their domain, and then be excited about their domain, but ultimately as a dev they pay me to write code so I want to also be at least as, if not more so, excited about doing that.
I guess the right answer, if the goal is honesty here, is to couch it in terms of "I'm mostly excited about <your problem domain>, but to be honest one of the reasons I even decided to go this far in the interview process is <tech feature>" or something? I'm not good with people, so I'm as much thinking out loud here and asking for feedback as much as asserting what I'd do.
It's always seemed to me like one of the main perks of having your company use a weirder functional language was the ability to attract talent that preferred it to more standard choices. An experienced developer might be willing to actually take a pay cut if it means using a favorite language rather than grinding out another Python/Typescript CRUD app or what have you.
I understand where the author is coming from, but I think having a preference and being excited about a tool your going to be working with all day is a reasonable thing, and it's ok if developers are excited about a technology for its own sake as long as they can make that compatible with continuing to make the business work.
I’d wager some big bucks that this never actually happened. Sounds super made up. No way they were like “Well Shelly really knows what she’s talking about, but too bad she’s excited about functional programming… that’s just so 2015.”
I think it's fair, even though I'm probably someone who would be knocked by it. You make different tech decisions when you're motivated by the results vs the technology, even if it's not conscious
What's unfortunate is that it's really hard to get motivated by a lot of the products our industry pays us to produce, so we drift towards focusing on the technology instead
I worked at a place that doesn't hire developers who use Visual Studio!
Another only hired ugly and disabled women for specific jobs to combat male sexual misconduct. Of course, an "ugly, crippled woman" got pregnant by a co-worker in no time.
It’s best not to hire an employee who is excited about anything. These people are running high on emotions and will almost certainly be a troublemaker later. Better to hire a professional who is ready to work and is cautious about rocking the boat.
something I always remember from my brief time lurking on comp.lang.lisp is a post saying a really good language is one that would get you to take a job just because you would get to work in it. it's the pleasure of using a tool that fits well in your hand and works with you to get the job done.
Some nuggets of wisdom from the article when managing an engineering org:
- “if the only reason an engineer wants to work for you is because of your tech stack, that may be a warning sign. Culture Amp therefore avoids hiring engineers who are purely technology-focused. As a product company, we seek to hire people who are mostly excited about our product and its mission, and who are happy to learn new things when necessary to progress that. When someone tells us in an interview they’re excited about working here because they like functional programming (say), we count that as an indication they might not be a good fit.”
- “Perhaps the greatest challenge for engineers as they reach more senior levels in their career is to make decisions that balance the moment-to-moment joy (or frustration) that a given tool affords them, and the costs (or benefits) that same tool might create for their team, company or client over time and at scale”
Because if there was something more concrete to offer that isn't done better, either from them or from the firm they represent, they'd go with that instead.
At least those that talk publicly about company culture. It feels performative and inauthentic, but maybe that's necessary to compete? They are selling culture surveillance technology of some sort.
Reminds me of mandates to get more on the engineering blog: makes an organic, authentic good into something performative.
Culture Amp is a performance review system that lets you give/receive feedback to/from peers and/or their managers. Please view their post with that in-mind.
Maybe it’s just because I’m also based in Melbourne, but I’ve worked for two or three places that use cultureamp, it’s a pretty solid service to help manage personal development goals and employee surveys etc. I even used to work for a competitor of theirs, and I’d rate their stuff much better, I wouldn’t write them off just because you’re not familiar with them.
> if the only reason an engineer wants to work for you is because of your tech stack, that may be a warning sign. Culture Amp therefore avoids hiring engineers who are purely technology-focused.
For the case of senior engineers conflict with this:
> Perhaps the greatest challenge for engineers as they reach more senior levels in their career is to make decisions that balance the moment-to-moment joy (or frustration) that a given tool affords them
> Culture Amp was well on its way to doing this in 2018, when things started to get hard for the recently-formed Design System team.
This is the problem right there. Design system teams never work well. A design system that’s complicated enough to need a dedicated team always creates more friction than it’s worth. Turns out that it’s really hard to standardize UI components in a way that makes them flexible enough to be used across different teams.
The only design systems I’ve seen work well are the minimal ones that just define the color values of the visual theme and look of some basic components like buttons but leave the implementation up to the individual devs.
Just speaking it off my ass here, but it could be the scale of those companies that make those teams viable. Like let’s say you have some standardized systems that can cover the use cases of 20% of your teams. If you have 1000 teams vs 10 teams, covering 200 teams might make economic sense, but 2 teams wouldn’t
I work at Culture Amp and was once team lead of the Design System team.
Its not hard to justify the team. If 4 front end engineers in a design system team can solve some common problems (writing components, improving accessibility of existing components, writing docs, answering technical questions etc) in a way that makes 40 product facing front end engineers more effective than 44 who don't have access to the team... then the team is a net positive.
At our scale we'd need to give a 10% improvement in efficiency to the product engineers. Both the engineers in product teams, and the various levels of leadership, have seen enough to believe we're making at least that much of a difference. Like almost any other company... measuring that accurately is a nightmare (and would require a significantly larger team just to measure ) but its a safe enough bet that we continue to invest in it.
The problem, with something like a Design System and many other aspects of organizational management, is that efficiency measuring tends to ignore the overhead, the death by a 1000 papercuts, and only focuses on the sweet points.
There’s also the part where they just let teams get away without fulfilling their responsibility to update both versions of a component and just let their tech degrade.
I'm at the point now where I think a design system team is huge mistake unless you've got 25+ people to permanently staff it. At best the team will provide more consistent UI/UX. At worst they will slow all other teams to a halt with poor documentation, bugs, and broken libraries.
I've seen three different ~100 person companies throw decades of person years into building out design systems, each to eventually throw it all out. By which time many teams have been forced to adopt the half finished project, so now they've got to tear it all out.
We all know now not to build our own databases unless there is an extremely unusual need. In another decade or two we'll say the same thing about design systems.
There's nothing wrong with some CSS colors and basics. But you'll only invite ruin if you try to build out (or wrap) React or Angular libraries. I'd guess right now that a full design system library takes about 25 person years to complete and 10 person years per year to maintain. By which time the target language and libraries will have changed so much you'll have to start over at the beginning and start upgrading.
Every company I've seen try this staffed the team with about 5 people. So they've got about 5 years to get to 100%. What has changed in the front end in the last 5 years? I know one design system team that started 5 years ago on an Angular 1 design system. No they don't have Typescript, no it doesn't work in Angular 16. I know another design system team that started about 6 years ago in Angular 1, then restarted 4 years ago in Angular 2, leaving most of the company on the Angular 1 version which was about 40% complete. Then 3 years ago they decided to stop forward progress for a year to go back and add Typescript types to existing components. They still aren't 100% on the Angular 16 version.
(I think Typescript is great, but I'd guess it adds at least an extra 5 person years to the timeline, since you have to be pretty great with Typescript to accurately apply it to a design system.)
All this to say, building out wrapper libraries for a design system is _really hard_. Just the documentation is probably 5 person years of work. The whole thing is expensive, tricky, and error prone. Unless you can staff 5 teams of 5 permanently, the front end just changes too fast to keep up. The ecosystem will look so different in five years, you'll need a whole division working forever to keep up and move to new tech while simultaneously maintaining the old versions.
And heaven help you when your designers get tired of the look of it after a year and want to redesign it all again. Because they will. (Wasn't that the point of all this, easy changes to the UI?) Now you've gotta go back and update all the half finished Angular 1 code and release a new version, along with your half finished Angular 16 library.
The golden path here is to just provide some basic CSS for buttons, tables, uls, inputs, etc, along with documentation and a site that shows it all in use. Put it up on a CDN with a version in the name so teams can upgrade easily. This whole project could be done in under two person years, just a UI engineer, a designer, and maybe a QA person. It's quick, and after it's over, everyone can work on something else. There's no need to keep a big team staffed forever. There's no need to do a rewrite for React Hooks or whatever. The CSS will work forever. Next year when the designers want a new set of colors, spend a few months to have someone release a new version. Don't change any of the CSS selectors. DON'T CHANGE ANY OF THE CSS SELECTORS. Everyone bumps the version on their CSS src tag and it just works. Easy day.
The problems were not with Elm per se but rather maintaining both Elm and React components.
> It seemed we were faced with a choice: Elm or React. Continuing to support both was fast becoming unsustainable for us.
> The thing that ultimately tipped the balance in React’s favour for us was that we acquired another company whose entire codebase was written in React, and whose team knew nothing about Elm. Overnight, we went from a company that was writing about equal amounts of Elm and React (and which might well have decided to double down on Elm) to one that was writing about 75% React.
They were considered, I was on the team that considered them. (I work at Culture Amp and at one point was leading the Design System team).
To be clear: embedding Elm in React is easy (we host the main NPM library for doing so: https://github.com/cultureamp/react-elm-components). But embedding React in Elm is harder, as Elm doesn't give any easy "escape hatches" to interact with native JS code.
The main opportunity is to use Web Components. Elm knows how to render any HTML component, including `x-my-custom-button`, which could render using React or something else. We looked into options for this, including prototyping https://www.npmjs.com/package/backstitch as a way to embed our React components as Web Components for consumption in Elm. (No open source packages existed to do this at the time).
We also did quite a deep dive on using Stencil, which has a React-like API, to create web components for both React and Elm - even including publishing new plugins for the ecosystem to generate Elm bindings for your web components. Kevin went into some of the detail for this in the post if you're interested.
I remember looking closely at Elm in 2016. I was a year or two into being the first and only web-focused software engineer at a hardware startup. Working solo, moving fast, refactoring aggressively as we iterated and sought our product’s UI, I was craving more help from my language than JavaScript and React alone could offer.
Elm was appealing for all of the reasons described in this post. Functional programming, static typing, batteries included so there would be fewer dependencies to juggle. Improve predictability of my code, cut down on bugs, make it harder to screw up, easier to refactor. People using it seemed to love it!
But TypeScript’s promise was too good. The JS I already knew but stronger! Keep my existing React code base but refactor it to be safer! No need to learn entirely new syntax; instead, adapt my ways of working to let the compiler be a better collaborator! Easy to break out of it when I absolutely had to!
Elm offered many of the same things but require more faith. You invest in different syntax and the Elm way of doing things and you get more safety, better syntax. But the risk of being stuck on a path that’s hard to get off, the cost of ramping up, the challenge of onboarding anyone in the future — that was not in my budget. Even if it was, even if it offered much of TypeScript’s value but did those things better… Was it going to be so much better than it justified the risk? I didn’t see how it could be.
I went TypeScript immediately after the 2.0 release so I could use @types packages from definitely-typed. I spent a week refactoring the entire project and never looked back. It was one of the best investments in technology that I ever made.
I remember a ton of advocacy for Elm on forums and blogs until then. I’m far from an Elm insider so this is pure speculation but if I had to guess, I’d bet wasn’t the only person who doing napkin math about the right frontend language/tooling investment right around that time. I wonder to what degree the rise of TypeScript clipped Elm’s wings and whether a different timeline, maybe Elm getting started just a year or two earlier, would have allowed the project to hit some critical mass to change the future.
Once again, backwards compatibility is the main name of the game.
Indeed, if Elm had emerged earlier that could have changed everything, but I'd wager that it is poor leadership and close-mindedness which really killed it off for good (Elm users will deny this, but as the world has moved on, Elm remains stagnant).
There is no shortage of complains about the devs uncanny protection of the core language and their opinionated approach to allowing interoperatbility with the JS ecosystem. Which is a shame because pragmatism always works out against dogma.
Imho, TS is just a crutch that helped JS to collapse from its own weight but still leaves many issues of FE development out in the open. In an alternative timeline, Elm would have been a path towards more harmoneous fullstack development which is more accepted by people coming from the BE side of things.
> maybe Elm getting started just a year or two earlier, would have allowed the project to hit some critical mass to change the future.
It's an intriguing thought exercise, but even with a head start it would have had serious issues like it has today; the pace of the language is _SO SLOW_ that in today's world it just has a hard time due to that.
I'm not asserting that it SHOULDN'T be slow, that the reasons for doing it that way are bad, or anything like that; it just is what it is, and that's a downside for many people.
IMO these days you have to have very strong justification to use anything other than the top 2 or maybe 3 “mainstream” technologies in any field.
Unless you’re doing something extraordinary (and you’re probably not), most software can be built with VueJS/React TypeScript C# Python Postgres MySQL/MS SQL.
That’s your entire stack covered there.
These technologies get the job done, people know them, there’s massive community support and critically important when you’re hiring, you’re fishing in the big pool.
Also, ChatGPT knows these technologies well and that’s increasingly important.
Any other technology choices really need very strong justification.
And, if your company is still using some branch of the technology tree which several years ago looked like it might have something to offer but has since become obscure or withered in its popularity, it might be time to do as Kevin Yank did and prune that branch off your tech tree.
MS SQL? I've been a ("full stack") web developer for 18 years now, and I've never seen anyone use MS SQL for a web application. That's immediately a tell that I'm in a bubble, and obviously you are as well if you think MySQL/MS SQL are even in the top 3 (behind Postgres, MongoDB, Oracle?).
Since you mentioned it, I just asked ChatGPT and in a list of 30 unicorn companies based around web applications, half of them were built in Ruby which isn't even in your list.
If becoming a successful company is part of the justification for technology choices, you'd need a very strong argument to not pick Ruby.
I'm not really sure that's true, but if you want to make strong recommendations I feel they need to be backed by data, and not some hunch on what technology is popular right now. And Ruby has been less popular for over a decade now, and it's still used by half the most successful companies out there. So the data isn't on your side here.
>> I've never seen anyone use MS SQL for a web application
Are you working in the corporate world? The data you request is that on my local job board there are > 833 jobs for MS-SQL - that's mainstream.
MySQL/MS SQL - I would not use them personally but they are very popular. Industry acceptance and popularity matter when pragmatically choosing a tech stack for a company.
Ruby is definitely not in my list - it may be fine if you are a unicorn company with a vast flow of developers who want to get on board the success train, but for the other companies hiring is a nightmare.
Again, my local job board has 148 Ruby jobs versus 1554 Python jobs versus 855 C# jobs.
The fact that a technology is used by big companies does not mean it is not in decline. Facebook still uses PHP - a technology clearly in decline. Like it or not, Ruby's best days are behind it - the fact that so any successful companies are built with Ruby is historical information.
And besides, its up to you what you think the list is of modern mainstream technologies - doesn't matter what I think is in that list.
The point is that choosing something less than mainstream such as Elm or Haskell or whatever is likely to cause problems.
And for the record - that same job board returned one job when searched for "Elm", and it was actually an ad for a Ruby job.
I have been a full stack dev for a while as well. Some time ago, I lead a project based on C#/ASP.net/SQL server. The SQL server instance would lock up/use 100% CPU for days every other week, even after restarting and with no load. That, along with many other problems with the tech stack made me say "never again".
So yeah, there are web applications based on SQL server out there, despite my efforts to prevent it.
SQL Server actually rocks. I was extremely skeptical about it going into a new job having mostly used Postgres, but it’s actually so much better than Postgres in some dimensions it’s kind of crazy. I always assumed proprietary DBs were just a scam, but there’s definitely reasons to choose one, especially in the enterprise space.
I would be interested to hear a concrete list of things SQL Server is "so much better than Postgres" in. It's difficult to draw any meaningful conclusions otherwise.
I'm sort of the opposite of GP. Having worked with SQL Server the first 5-6 years I've transitioned to using Postgres more over the last 3-4 years and really prefer it. That said SQL has some nice features, off the top of more head:
* It's pivot/unpivot query syntax is a lot nicer than the comparable Postgres extension.
* The ability to define a clustered index for a table that's maintained automatically.
* The ability to define materialized views that are maintained automatically.
* The db engine can automatically use materialized views to accelerate queries matching the view definition.
* It has some really cool support around temporal tables. Not just defining them, but using them in queries. Like, there's a pretty simple query syntax that lets you join together multiple temporal tables and say, show me what the data looked like at this point in time, or show me how it changed during this time period.
The main problem with SQL Server IMO is that many of the cool features you discover are gated behind a SQL Server Enterprise license, and it's crazy expensive. Upwards of $10k per core per year, IIRC. The last time I looked at RDS instance prices I believe SQL Server Standard was about 4x more expensive than Postgres, and Enterprise about 8x more expensive.
Edit: as a sysadmin the quite easy to configure default maintenance plans with backups is a godsend. It is still very awkward what you need reinvent the wheel (or use/buy a 3rd party product) to just backup databases on schedule in PG/My SQL.
> These technologies get the job done, people know them, there’s massive community support and critically important when you’re hiring, you’re fishing in the big pool.
There's probably some company out there who used this argument as a reason to not switch from Perl to Python that are regretting their dwindling hiring pool.
I really felt this story as someone how had to abandon coffeescript like 8 years ago in a similar fashion.
The syntax was easy, simple, and enoyiable. But at the end of the day, when you implement something like react or angular in real projects can get messy really fast.
At least a lot of the good things of coffeescript still kinda live in TS and new versions of vainilla JS.
I have used elm for a smallish (10 people or so?) team writing software for revenue, and regretted it. that was 4-5 years ago. my reasons had a lot to do with the community around elm, which other comments allude to. This group had different concerns to mine:
The thing that ultimately tipped the balance in React’s favour for us was that we acquired another company whose entire codebase was written in React, and whose team knew nothing about Elm. Overnight, we went from a company that was writing about equal amounts of Elm and React (and which might well have decided to double down on Elm) to one that was writing about 75% React.
By that time, TypeScript had grown to be capable enough (and developer-friendly enough) to balance much of what sold us on Elm originally: a usable type system, good-enough error messages, etc. React had baked in some more useful state management primitives that roughly matched Elm’s “batteries included” state management.
if you like the ideas in elm but don't want to commit to it I'd encourage you to check out elm-ts (https://gcanti.github.io/elm-ts/). It has a little bit more boilerplate than elm (I find elm to be quite verbose already!) but a better experience for individuals and teams overall, I would say. It's a good example of how "TypeScript had grown to be capable enough (and developer-friendly enough) to balance much of what sold us on Elm originally: a usable type system.."
I feel much happier writing functional code than OOP code...
And I don't believe much in engineers believing in the company's mission. That is an HR delusion, in my opinion. Yes, of course, some buy-in is good, even ideal, especially later on. But really. At some point, you want a job, you want to get paid, you want it to be somewhat meaningful, but how many choices do you have? I don't have a lot of choices of companies that want me, so I don't much care about the topics I work on. Unfortunately companies care a lot about what they think I want to work on, and they deduce it from facts in my CV I am legally obliged to disclose.
Yea this looked a bit odd, and I'd not heard anyone say it before. I have therefore made a mental note for job interviews: "I was attracted to your job ad by your tech stack, but I made the application because I was just BLOWN AWAY by your awesome mission to re-invent inventory cataloguing."
Man, it's 2023 and Elm is still the best thing to use for one-man SPA apps. Unfortunately, the author is right and it's Elm-or-nothing most of the time, no real coexistence of Elm components with TS/JS ones. That adds to the state of Elm being essentially abandoned by its creator.
I'll keep using Elm for now for my one-man UIs, the language doesn't feel old but rather "done". I'm still productive as hell with it, TypeScript will never match. But I'll also never recommend building their startup with it and won't force it to anyone anymore.
Because the language is frozen in 2019, it's last meaningful release.
It was doomed to end this way due to the close leadership and being developed behind closed doors by a single developer.
This kind of projects, as amazing as they are, and Elm is absolutely an amazing language and project that has changed and influenced web development meaningfully, are just untrustable.
If you can't have a discussion with library authors where they confront their ideas in the open, you need to move on or pay the consequences.
To be clear I don’t use Elm in production so my thoughts are purely speculative. However, when you remove FFI to JS - in a language which is focussed around the web platform, which evolves pretty quickly - and you only have a handful of developers, it strikes me that just keeping up with the Web API bindings alone, is a lot to undertake. For example, if you want the new Web Transitions API, I guess you’ll have to hope you can call it through JS ports.
As others have noted, the Elm architecture has influenced many more pragmatic frameworks that have taken the key principles while still allowing work to get done.
I’ve used Elm a few times for hobby projects and while it’s super nice to model state and render most HTML and CSS (and is even enjoyable to write), you always feel that one day you’ll become too locked in and that Evan may decide to go live on a farm.
> What is lacking in the 2019 release and in what ways does the frozen feeling make things bad in reality?
Things I've personally missed include websockets, missing features in the browser interface like preventDefault in the Keyboard API, etc. It's not a big deal, but if you need lots of less covered APIs and have to develop ports for many little things, it becomes an annoyance.
In professional contexts, I haven't had trouble with Elm, but others have reported missing the kind of features people usually require, like server-side rendering, the ability to deploy a private package repository that doesn't feel like a hack, etc.
0.19 was a great version, but it is very barebones, and some new developments that have happened in other ecosystems just didn't happen because of the way contribution works in Elm.
If you only need what's already there, Elm is glorious. If you don't, you know it. Evan can't really be blamed for it, as he's always been very clear about that, but at the same time, it's kind of a pity to see such a great work that can't really be extended.
> If you only need what's already there, Elm is glorious
But how can you reliably know that'll be true in the future? Elm scared me away because I thought I'd be going along perfectly fine and suddenly get a straightforward new requirement that is strictly impossible.
(For those who haven't looked into Elm the issue is that to call javascript functions synchronously you have to be whitelisted by the compiler. One of the explicit reasons for this is that the language designer thinks it's bad when there are multiple competing libraries solving the same problem).
For instance, the projects I worked on were professional software. People don't care so much about SSR and first page rendering speed. We also didn't need the latest shiny browser APIs, or to tweak CSS to perfection, and we reasonably could say that this wasn't going to be the case in the future.
In that context where many devs were backend devs or self-taught, so using JS wasn't that important, since we were going to train anyway. Actually, training to Elm felt much saner than training to JS.
However, the tech remained niche for all the reasons I quoted in my first message.
A number is not a string, you should not have to convert to strings like this. Evan's response on that issue is very typical - ask a question, get a negative reaction, completely ignore it and years later zero indication of a fix or change.
> If you can't have a discussion with a library authors where they confront their ideas in the open
Interestingly, for the most part you can't do this with Rails authors. It does not make me super confident in the future of Rails. From the authors point of view, I suppose it saves them time arguing in public in useless ways.
It wasn't clear to me that you were only talking about when there is only one maintainer, but it does make sense to me that the problem is _greatest_ when there's only one maintainer, sure. It still doens't fill me with confidence even when there's a junta.
With Rails, we also suspect there is one person, the original author, who has outsized authority within the plural authors, who at least occasionally, maybe more, makes final decisions without even internal discussion among the committers "committee"... but since it all happens in private, and nobody ever reveals anything about what happened there, it's hard to say how much internal discussion there is amongst the plural authors, or how often big decisions get made by fiat. It does feel very... politburo.
Do extremely basic bugs get left for years on the Elixir issue tracker without even a comment from the creator? What about pull requests to fix literal typos which prevent certain features from working as expected? I absolutely love(d) Elm, but despite all the talk about making Elm inclusive and a place to be friendly, it's an authoritarian nightmare where every criticism has to be couched in a million disclaimers and the creator likely ignores you no matter how good your point.
I still take the overall point that Elm was simpler, but it’s funny how people react to curly brackets.
When I look at the provided screenshots comparing Elm to JavaScript, I see no meaningful difference in terms of visual noise. Maybe I’ve just spent too much time with too many languages.
I can't be the only person who wondered why a company was still using the Elm email client.
Edit to add: There are enough names and acronyms available. To avoid even temporary confusion, and to make literature searches easier, try to avoid popular ones from yesteryear that were used in your general discipline.
I wish I had, just once, had as thoughtful and thorough manager as Mr Yank (terrible name for an Aussie) seems to be (at least as far as you can ever tell from the self-presentation of an article).
TL;DR: they bridged Elm with React, and when they started using Web Components there was an impedance mismatch between the bridges between Elm/React and WebComponents and the bridge between Elm and React, so they had to pick one of Elm and React.
That's a bit too short, I think. TypeScript plays a role as well, as does an acquisition.
I liked the description of the internal discussions. Working at a larger company where decisions are made in a completely different part of the organization and you're stuck dealing with the ramifications leaves me a little nostalgic for a smaller firm where it's practical to engage all stakeholders.
No, they didn’t end up using WebComponents. The real issue was that it was too much trouble to have Elm & React in the same codebase. They were migrating the code to Elm, but then merged with another company. Now 75% of their company was only familiar with React. Only 6 people were strong Elm advocates.
Because React and TypeScript had progressed since they first decided to use Elm, because the cost of maintaining two frameworks was high, and because the cost to switch to Elm was out of reach, they decided to “contain” Elm by no longer permitting it for new components.
I would say the Web Components portion of this article is a detour, mainly he was explaining his discovery you can't utilize web components to marry React and Elm together as one would hope. The real TLDR is it's too hard to hire Elm devs.
They had an acquisition where the code became 75% react over night due to the acquisition. This was the major turning point. Purely business, purely popularity. It wasn't technical superiority.
I always felt the lack of an ABI would hurt Elm, even though I understand the reasons for it.
If you are "ML curious" then I think that Fable / F# is currently the strongest option for compile to JS languages. It definitely benefits from being a mature backend language already.
I must admit, I read this headline and wondered why I should care which email editor they used. I read half the article and still don’t know what Elm is but I’m guessing it’s a language?
At the moment I have a bit of an opposite problem from the "don't hire for passion only": I can't find a new job because I can't hide my passion and experience in Python well enough and somehow Python is regarded as very unprofessional in Germany, so not many companies want to use Python for Full Stack development at all.
The first time I heard about Elm, I was overjoyed with its promise. For the first time, it made me interested in working on a web FE. To bad it ended the way it did.
Thank you for sharing the article. It makes good points, particularly on the historic context as well as the steam behind Elm waning.
> NOTE: My goal is to get some early feedback from the in-person audience, so the video will be held back for now. I am not announcing a release, and the roadmap and this status update are still the primary documents for long-time Elm users to set expectations about this work.
> As I allude to in the roadmap 410, nearly ten years of working in constant interaction with “silicon valley mindset” had taken a toll on me in many ways. Within the dominant value system, there are specific rewards and punishments for specific behaviors, and despite my personal views on this value system, I had internalized certain patters of thought and behavior by interacting with it online.
I think sometimes HN gets excited about technology and forgets that tech is made by humans.
This 'reminder to be kind' bullshit is why I got so frustrated with Elm, and ultimately quit using it. For the same reasons, I actively recommend against using it, and I will recommend any place I find using it to migrate away. And I love the actual language and approach, it's in many ways the best experience I ever had in web programming. Ruined by this awful passive aggressive approach to management which itself triggers criticism (by the Elm 'team' disengaging at the slightest hint of 'negativity' such that everyone is always walking around Evan on eggshells).
I want to be kind, but sometimes you also have to be HONEST.
Evan doesn't just hide from confrontation. He and his team bans everyone who are confrontational. Like me. They wouldn't even acknowledge that they banned me, which is just cowardly. No one I worked with who used Elm would go close to talking with their own account on the Elm reddit because they were sure they'd get banned.
I argue hard because I was raised that way and I believe it's the best way to quickly find the truth. Like Steve Jobs said: strong opinions, loosely held. You argue hard, then when you are convinced by the other side, you flip with absolutely no time in between trying to "save face".
> He and his team bans everyone who are confrontational.
I have a very distinct vibe. And sometimes people don’t want me at their parties because I don’t fit their vibe. Sometimes I’m invited to parties and then asked to leave because I don’t fit the vibe. I don’t think anybody at fault in these situations :) It’s hard to curate communities, and it’s hard to fit in
In my opinion, Daniel Dennett's quote, "There is no polite way to suggest to someone that they have devoted their life to a folly," is highly relevant to this situation, and I respectfully disagree with your viewpoint.
I only looked enough into Elm to determine it's not for me. But this relates to the main reason I made that decision: it's explicitly designed to be hard to integrate with javascript.
Integrating React and Elm is hard because they can only communicate via message passing. Synchronous js calls are restricted to packages whitelisted by the Elm compiler.
Same, I never got Elm, I'd want to work as close to JS as possible. I like TypeScript but I likely wouldn't use another compile to JS language, if only based on the npm ecosystem size in general.
Then I heard the horror stories about Elm, and how the creator really hates criticism while simultaneously carving out features in the compiler for his friends, and I decided it wasn't for me.
Parent comment implies that TypeScript + React + Redux combo is superior technology and the only reason Elm got traction in the first place is that mentioned combo hadn’t been invented yet.
I'm mainly sad that we'll be losing the chance of any future Kevin Yank videos about Elm. I really love the videos of his I've seen on youtube, including non-Elm ones such as the one about how to use VoiceOver for devs [0].
[0] https://www.youtube.com/watch?v=38qQzmkXGS4