Why and how we retired Elm
kevinyank.com
kevinyank.com
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].
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”.
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.
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.
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.
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.
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.
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.
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.
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.
This is news to me! I switched off svelte in 2021, and onboarded with solid in early 2022. This excites me to check out svelte again
> It was not meant to be faster.
Well, this whole discussion is performance so...
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.
What makes React so slow these days?
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.
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
To steal a phrase originally about VDOM: “reactivity is pure overhead”. Nothing comes for free!
React is easy to be quickly productive in... thus, it has footguns.
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.
https://emnudge.dev/blog/react-hostage
It's so easy, that we monkey patch react to debug it https://github.com/welldone-software/why-did-you-render
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
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.
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.
Fast enough is a myth. Instant apps are magic.
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.
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
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
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.
How much does anyone really know about a company they don’t work at?
And if that’s the issue (I don’t think it is from what o read) then they just have to say that and not the bit about functional programming.
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.
> 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.
Yeah, that was planned from the beginning.
If my current employer hired this dude as VPE, I would immediate quit. Just an asshole.
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.
Why hold people interested in Elm to a higher bar than the 90+% of hires who don't care about the company they work for and just work for $$$?
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).
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.
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.
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.
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.
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.
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]
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.
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.
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.
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.
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.
Every one of these leads to either more productive employees, lower ongoing costs, or happier customers. How are these not tangible business results?
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.
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.
> #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.
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.
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).
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.
That is pretty far from what I said. Try again?
> 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)
Sounds like they hired people unqualified to take over product maintenance.
If your engineers can’t wrap their head around ”FP-ish” JavaScript, they’re not exactly batting .300.
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.
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.
[1] https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
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.
Because 1.) Angular was still "the hot shit" at the time, 2.) React was already there, so you could have chosen that as well and it is still here.
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.
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
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?
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.
But most people wouldn't call Elixir "boring tech".
In the sense most people mean boring, Haskell with sum types, pattern matching, and pure functions is the most boring someone could ever hope to get.
However, most people wouldn't consider that boring either :)
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.
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)
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.
:shrug:
Do I get a prize?
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".
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.)
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.
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.
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.
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
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.
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
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
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.
They'll write 500 lines of inscrutable framework code to save having to write 5 lines of boilerplate 3 or 4 times.
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.
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.
[0]: https://docs.scala-lang.org/overviews/scala-book/introductio...
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.
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.
As with all things, balance is the key.
A team that gets shit done will later look back and see that what they've done is shit.
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?
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.
To whom it may concern: being respectful when attracted by someone is a thing.
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’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.
You made people feel bad for not questioning their preconcieved notions... that's a nono! :(
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.
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.
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 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'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 ;)
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 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.
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.
- “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”
Consider the source: https://www.cultureamp.com/
A completely generic me-too startupy startup. I can't even figure out what their product is.
Reminds me of mandates to get more on the engineering blog: makes an organic, authentic good into something performative.
LOL
E = \frac{1}{2} m (\dot{q}^2 - \omega^2 q^2) + \int \Gamma (s) ds + \frac{\sum_{n=1}^{N} (T_{\text{amb}} - T_n) \cdot \text{W}_{\text{AR}}}{\sum_{i=1}^{N} \text{SP}_i \cdot \text{AU}_i}
E: Effective rate of innovation
m: Mass
q: State space coordinate
q': Time derivative of state space coordinate
ω: Frequency
Γ(s): Gamma function
T_amb : Ambient temperature
T_n : Individual temperature
WAR: Wins against replacement
SP_i: story points
AU_i: total active users
or in production:
function calculateInnovationRate(I) { const { a, b, c, d, e, f, g, h, i, j, k } = I; const L = 0.5 * a * (b * 2 - d * 2 * c * 2); const G = e.reduce((acc, x, idx) => acc + x * f[idx], 0); const N = h.reduce((acc, x, idx) => acc + (g - x) * i[idx], 0); const D = j.reduce((acc, x, idx) => acc + x * k[idx], 0);
return L + G + (N / D);
}They provide saas tools for companies to do… HR-y/“company culture” stuff? It’s pretty clear.
I am not the one to be overly excited for that, I don’t really care for HR, but some people might?
Lmao it’s “pretty clear” but you use vague weasel wording to describe it.
> 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
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.
GitHub, Atlassian, Microsoft, plenty of greatly and widely used design systems out there.
The problem is different: they are huge investments that most non-large companies cannot afford for economic and logistic reasons.
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.
Maybe design systems work when you are the size of google, etc, but otherwise they are way more work than people seem to believe.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
"Whatever happened to Ruby?" https://www.infoworld.com/article/3687219/whatever-happened-...
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.
* 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.
Editions Open no-level price (US dollar) Licensing model Channel availability
Enterprise $15,123 2 core pack Volume licensing, hosting
Of course MS heavily push for SA and while it's not useful for the most SMBs it has benefits like unlimited virtualization rights.
[0] https://www.microsoft.com/en-us/sql-server/sql-server-2022-p...
[1] https://download.microsoft.com/download/0/f/4/0f4c1b3c-cbc4-...
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.
So yeah, there are web applications based on SQL server out there, despite my efforts to prevent it.
ChatGPT writes Haskell better than other languages I've tried like python or javascript. It even works well fixing the type errors.
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.
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.
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.
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.
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.
> What We Owe to Elm
Everyone who talks about Elm sounds like they have Stockholm syndrome. Don't think I've seen a single good experience lately.
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.
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.
I am curious since we have one major project written in Elm since 2017 and it has been a great success.
There are no obvious landmines in the Elm compiler.
I adore using technology that feels “finished”.
I personally view its infrequent updates as its best feature.
In this particular case, the workaround is luckily simple:
case String.fromInt n of
Just "-1" -> True
_ -> False
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.
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.
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).
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.
Elixir has been feature complete for a few years now. Do you feel it’s doomed as well?
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.
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.
You are not.
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.
It was kind of cool that they really explored all the avenues for making it work.
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.
> Codebases written in contained tech stacks can continue to exist and have features added to them
Phasing out might be a better term.
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.
Thank you for sharing the article. It makes good points, particularly on the historic context as well as the steam behind Elm waning.
I guess money was easy enough to get in the last two years so company can afford this kind of expensive experiments..
It uses Tailwind, though appears to be highly customized.
Despite the article I now want to learn more about the language Elm.
[1] https://gotoaarhus.com/2023/sessions/2529/elm-on-the-backend
The video will not be published online.
> 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.
[2] https://github.com/elm/compiler/blob/master/roadmap.md
[3] https://discourse.elm-lang.org/t/status-update-3-nov-2021/78...
EDIT:
In the second link, Evan says the following:
> 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.
Just a reminder to be kind :)
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
For an example see e.g. https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/
I often have to make these practical considerations too.