Hacker News Reader

The lesson:

Programming language adoption is based on politics, not technical merit.

This isn't inherently bad, but is important to remember.

Languages are successful due to the community that rises up around them, far moreso than anything inherent to the design or quality of the language itself.

Which can be correlated, but not necessarily so.

It’s not all one or another. PLs are a software product and they need proper marketing and PMF. You can describe the network effect as political but its the same kind of politics as getting your friends to change chat apps.

Why politics and not practicality? Taking a ton of time and resources (and potentially risking attrition) to migrate a thing that works to a thing that _hopefully_ works often simply doesn't make business sense. It's not a political decision (in the common usage of the word).

Practicality is a big part of the politics, but there's real politics at play as well. Different developers will have different levels of comfort with different tool chains, and different capacities to work outside their comfort zone.

This is overly reductive, but here's an example: if you have 3 developers, and 1 will be twice as productive in F# and the others will be 10% less productive, it's probably practical sense to switch, but the 2 developers will resist it, and it may fail for political reasons.

"Taking a ton of time and resources (and potentially risking attrition) to migrate a thing that works to a thing that _hopefully_ works often simply doesn't make business sense."

And yet it happens all the time. And the decision is rarely based on anything but a veneer of technical merit.

I don't think that's the lesson. The problem described is with maintainability. That's not political; that's technical. (It just looks political, because people say "No, you can't use that language" after they've seen the maintainability problem a few times.)

I've seen this pattern before: problems encountered with a new or different technology are attributed to that technology, while comparable problems with the existing system are seen as the fault of specific teams/developers or just as the sort of natural bugs you get in software development. The same kind of problem that's seen as a clear reason to avoid the less popular tool is seen as just something to solve or workaround in the more popular case.

That's how politics generally works: there always has to be a plausible "objective" reason for something, it just doesn't have to be applied uniformly or even actually true.

What you say may be true in general. But we're specifically discussing being able to hire someone to take over a code base in a language, and no, the dominant languages do not have the same problem. You can find C# programmers under any rock. F# programmers? Not so much.

The maintainability problem is a political problem, because it's hard to maintain because it's hard to find developers that know the language or are willing to invest in learning it.

That's true, but it's not entirely true.

I've seen countless migrations to React from other equally capable frameworks because "everybody uses React" it must be the best tool!

I've seen companies picking up Python because if you wanna do ML you gotta use Python, right?

Anybody can write Python, right?

Except now you have a Python codebase written by people that pretend to know Python, while they really don't know how to write a maintainable software program in any language, it just happens that Python is the only language they "know".

And now everything sucks, but at least it's trendy, right?

Programming languages are tools, if you hire someone competent in Ocaml but force them to use Java because "it's more maintainable" you now have two problems.

IMO

Yes and no, Jetbrains did an incredible job on Kotlin with seamless interop with Java, trouble-free mixed Java/Kotlin codebases, as well as reducing the learning curve and mental context switching as compared to something like Scala.

At my company there have been several devs trying to introduce Clojure as well as parallel forays to introduce Kotlin. Overall, Kotlin has caught on and spread much more rapidly and with less effort.

This is not a statement of which languages are "better" given all things equal or what problems each are suitable for, but in my first hand experience it is easier for the average Java developer to pick up Kotlin. Of course we as a company are also cognizant of the IntelliJ lock-in as I suspect using any other editor would run into the same random bugs / autocomplete annoyances that the GP experienced.

> Of course we as a company are also cognizant of the IntelliJ lock-in

There's your politics. Kotlin is succeeding because of it's ties to a very popular Java IDE, so developers already using IntelliJ tend to trust it.

It wouldn't do nearly as well without that built in base of support.

It's primarily utility, not politics. Yes, sure, Kotlin gets free press because Jetbrains and Google support it... but it's also because Kotlin is a brilliant language, it had an initial use case that was in extremely high demand (building Android apps) and JVM compatibility meant it had an enormous ecosystem of compatible packages from the start. But instead of just sitting back and riding on its initial popularity (that would be "politics"), the language has added more and more use cases (backend, multiplatform, JS), expanded its scope (kotlinx extensions), and built a following and a Kotlin-specific ecosystem of packages and tools that often surpasses the JVM equivalents in utility and quality.

The "brilliance" of any technology is not intrinsic to the technology. It's determined by humans.

It's always politics.

I see, so when I need to travel from Los Angeles to New York, deciding whether to fly on a commercial airplane or ride a bicycle, is a political decision? Reducing travel time by 99.99% isn't an intrinsic feature of airplane travel?

Would you say the 99.99% reduction in travel time is “brilliant”?

Me, I like sight seeing. A bicycle ride sounds brilliant. Even though it is much slower.

Yes, I would absolutely state that there are dozens, perhaps hundreds or thousands, of brilliant innovations, technologies and engineering feats that make it possible for a 757 to exist, and fly so safely, routinely and inexpensively that the general public takes it entirely for granted.

I’ll try make the point one last time then let you be.

“Brilliance” is a human attitude towards technology. It is not an intrinsic property of technology.

I agree that the word brilliant is an adjective that humans can choose to use or not use to describe a particular technology. Your initial statement was that making that decision is always due to politics, as opposed to a person's genuine opinion... or perhaps implying that people simply don't have the ability to evaluate something independently.

Because brilliance is about the people not about the technology it is political by definition

It actually is.

A country which would have made different political decisions may have decided to not provide a direct airplane flight, or as good of an interstate road system that makes the drive possible. They may have provided high speed rail instead that could have potentially been better if that’s what the country had chosen.

I think the fact that Google was not updating the java usable on Android might have also played a big role in kotlin adoption, don't you think?

Honestly I feel kotlin doesn't add much to modern java, and if possible I think it's generally better to use the native language to the platform. Probably a reason why kotlin is not that popular on the backend where people can use modern java :)

I think jimbokun statement is 100 percent correct which doesn't mean kotlin is a bad language.

> Honestly I feel kotlin doesn't add much to modern java

In that case, I hope you won't mind that I'll be ignoring the rest of your opinions on this particular topic.

I do not mind at all :)

Java is verbose by design while Kotlin is pragmatic. That's why I prefer Kotlin, even though on the backend I could have just as well taken the latest Java. That, and strict null checking.

Not just IDE. It's because Kotlin is a general purpose PL with wide utility and tooling which Clojure doesn't come close to. Clojure doesn't even work on mobile platforms.

I'm not a clojure dev but I don't think that's true, I think you can do react-native with clojurescript

Third party React Native bindings for clojurescript vs official Android framework apis in Kotlin are not really comparable when evaluating each language for an Android app I’d argue. But you’re right in that it is somehow possible through enough layers.

And basic similarity with Java- feels different and better, but not as different as F# from C#, or Clojure from Java.

Scala’s an interesting case, it rather did catch on.

Sure, I can see that. I was differentiating between internal company scale politics vs. larger-than-company politics. If Microsoft gave the same first-class promotion and support to F# that it did to C#, that would undoubtedly increase F# adoption.

My experience is a micro-scale observation that it did not take much campaigning to convince developers to try it (given the existing level of support backed by Jetbrains).

And if Visual Studio had level of ergonomics any closer to JetBrains IDEs....

Well, that’s because Kotlin is very trivially close to java, it’s almost just syntactic sugar over it. A language with very different semantics like clojure will of course not fit in as well.

Politics.

The similarity to Java, something many developers already know, is an appeal to current popular sentiment. You can advocate the superiority of Clojure's S-expression inspired syntax or immutably data structures or pure functions all you want, most people will just pick something close to what they already know.

Yeah, not arguing that, just wanted to point out that languages have different “activation energies” — one may be able to convince management to add some kotlin to the codebase, but it is much harder for a more exotic language.

> At my company there have been several devs trying to introduce Clojure as well as parallel forays to introduce Kotlin. Overall, Kotlin has caught on and spread much more rapidly and with less effort.

The reason might be, that Clojure is following a completely different paradigm and people are not willing enough to learn it.

> This is not a statement of which languages are "better" given all things equal or what problems each are suitable for, but in my first hand experience it is easier for the average Java developer to pick up Kotlin.

Yep, I would expect that to be the case.

There is a lot to learn for the average Java only (so far) programmer to really get Clojure.

>Programming language adoption is based on politics, not technical merit.

This is a very serious problem in a production system and it's not a political problem. Having a mixed language system is never as maintainable as a mono-language system, assuming that mono-language is up to the task.

>they leave and now the project has this magic F# part that nobody really knows how it works but everyone knows how to work around.

IMO C# is picking up a lot of small things that make it incrementally better than it was before, and at some point it's not worth the hassle to go to F#. F# features are gradually added to C# so C# developers have time to pick them up as well.

You cannot add the best features of F# to C# without making it a fundamentally different language. You're not gonna make C# into a type-inferred FP language by bolting on some random half-understood bits anymore than you can make a cat jump better by gluing rabbit legs onto it.

It's the core paradigm and philosophy that makes it great, and if anything, what I've seen hold it back from its potential is insufficient support requiring essentially importing C# idioms into the language just to interop with existing libraries.

Absolutely - F# is greater than the sum of its features. While it's good that C# keeps getting features inspired by F#, they fundamentally won't change the way it's written. The actual experience of using global type inference, immutability, sum types, currying (& partial application) and well thought out exhaustive pattern matching cannot be replicated by bolting them onto a fundamentally imperative OOP language.

The lack of sum types is the main offender that blocks any C# code is evee be even remotely close to F#.

Lack of a "unit" type is also a huge issue. e.g. need to create Task<'T> and non-generic Task, or Action<'T> and Func<'T1, 'T2> due to "Void" not being an actual type...

Meh - it's not really about "best features" or whatever. C# is getting expressive enough where it's not a pain point and it has widespread adoption and is platform default = no reason to go F# unless you're looking for a FP language.

It's true that bringing in a new technology without support of your team is a bad idea. However just rejecting F# per se because C# has a lot of features is missing the point. Engineering is about trade-off and if for a given project with a given team F# is the best choice - given the information available - please go for it.

I think F# in the context of C# replacement (as a superior language) is not worth it.

If you have a team looking for a functional language on .NET it's amazing - so I don't dismiss it - it's just a very niche thing on .NET platform.

> Engineering is about trade-off and if for a given project with a given team F# is the best choice - given the information available - please go for it.

What objective measure can someone use to determine whether F# is the best choice?

Pure data-driven decisions would not be possible here, I'm afraid, because there are not enough studies about which language/framework is the more productive in a given situation (and doing such a study is super tricky, because the competences of the participants can very greatly).

What is possible however is to first analyze the core attributes of the techs which are relevant for the project and team such as: good supported libraries for the problem, support for immutable data-structure, expressiveness of the type system, experience of the team with the tech etc. You can then decide which tech fits better the environment. If still undecided you can try to build a prototype on a short period (at the risk on giving up on technologies which are hard to learn but could be rewarding on the long term).

I don’t think it matters what language people think is most productive. What really matters is what language you can hire for. In the end you have to have people to do the work.

I used to be a very big fan of a certain functional language, and invested serious time and effort into projects in that language, but hindsight tells me every single time it was a mistake. It was a mistake because if you cannot hire people to do the work then the project dies when it needs to grow.

People used to do very big projects in COBOL, which most hacker news readers have never even seen, and as someone who did some COBOL, I can confirm that it was absolutely terrible, but the projects got done and by and large with less tech stack Jenga or superfluous trash that infests so many projects today. COBOL died when the majority of people moved on, not because st80, pascal, ada and C were better, but because the industry switched to platforms where the dominant languages were day one different: pascal and C. Mac, Windows, the Unix workstations.

Maybe those platforms used other languages because they were better. Certainly I can’t imagine the Mac built with COBOL, FORTRAN, bcpl (worked for amiga, somewhat), etc. but the dynamic of leaders is different from the dynamic of followers.

I see two thinks to distinguish in your discourse. First the hiring pool. I don't see any consensus here. If you take Haskell for example there are so many talented devs knowing the language without opportunity to use it professionally that they will rush on the first job offer. Now if you take Clojure it may be different. There may be enough positions occupied to make it hard to hire. I don't know, so I'm speculating. In general a good dev should be able to pick up a new language in a few months and in my opinion the potential hiring problem may be exaggerated?

Your second point is about platforms. A FP language hosted on a popular platform has a lot to gain. That's the Clojure story. Rich Hickey tried different solutions / languages before but only Clojure was successful enough. Because it's tied to the JVM.

But... nowadays most popular FP languages are hosted on a popular platform (JS/Web, JVM, .Net) so if a FP language builts a community that is big enough (no need to be big like Python) it will be sustainable.

Last comment: if you think about sustainability on the very long term, such as COBOL projects, then choosing the default language of the platform (JavaScript for the web, Java for the JVM etc) may be wise (because the platform is more likely to die after the other languages). The truth is that most software project don't have such a long life so it should be only one criteria among other for the choice.

So to conclude given a good choice for a platform (BEAM for distributed systems for example) I think languages do matter, because they offer different trade-offs (less state bugs with FP languages for example).

>What really matters is what language you can hire for

The whole mental framework of hiring for a language comes, I think, from HR/business people assuming that programming languages are like natural languages and that language experience is a central, fixed component of a candidate's identity.

In large parts of the industry we simply don't believe this at all, interviews are about algorithms / problem solving and experience filters at senior levels are about business problem domains. Getting up to speed in whatever language is just part of onboarding.

At least part of the answer is, "more than one team member knows F#". It can't be just one person's pet language; a significant number (half?) of the team needs to be comfortable working in that language.

It can't be a small wart on the project either. If there is one small section that is inconsistent with the rest it's going to be a pain point.

I love F#, but don't think it's ideal if it's shoe horned into a C# project. You then have this boundary layer you have to maintain.

because people have shit to do and no time to study a new language at work

Which is really a positive - if you start a new effort in F#, it basically self-selects for the most technically curious or proficient devs. Most corporate C# code-slingers are fearful of learning it or putting themselves through the mindset shift required to grok basic FP principles. "Do you know or are you interested in learning F#" becomes the only interview question required. But I do agree, if you have to build a team around the "least common denominator" then pick the boring tech stack and go.

Introducing something into an existing team and starting a project or team are very different things.

But I share some of your reasoning and am curious how this actually plays out (I haven't seen any examples so far). One project I worked on, when starting they wanted to do Clojure and they ended up using RoR because everyone was using it and Clojure was a hiring concern. In retrospect RoR fell out of favour, there's a bunch of vacancies for it but it's not very hot so it's hard to find devs and they are forced to take "learn on the job" just like with Clojure, plus you need to compete with a bunch of employers looking to support their projects in now out of fashion stack. I think using Clojure would give them a unique candidate pool and be a hiring differentiator. But that's just speculation. I haven't actually seen how this choice works out in practice.

Jane Street (OCaml) and Jet.com (F#, sold to Wal-Mart) are two obvious $B examples. It seems to be more industry-dependent as well.

It worked well early on but once we ran out of F# devs to hire we regressed to the mean.

Arguably that's a "good problem to have". A startup in its early days pretty much requires all its engineers to punch above their weight class. Every company slows down/averages out as once it starts to scale.

Willingness to try a language or framework is an extremely poor selection criteria for being able to use it well or even being willing to learn how to use it well. I've seen enough shit-ass Ruby or Kotlin or Scala from people who were like "awesome, I love learning new languages!" but never got past "oh, what's the fastest hack I can find to do this in a similar way to how I'd do it in the last language I used?"

This argument 'it selects for intelligent devs' needs to die.

it just selects for people who have hipster level enthusiasm about function programming. That doesn't mean proficient.

Many talented developers have a life of their own, and can do well without changing the language.

That's why Joel said 'smart AND gets things done'.

> C# is picking up a lot of small things that make it incrementally better than it was before

agree. C# is kind of morphing into F# with new features like record.

C# is Microsoft Research’s multi-decade play to convince Java programmers to become Ocaml programmers so slowly that they don’t notice.

Given that Java was Sun's attempt to bring C++ developers half way to Lisp, and C# was born out of a lawsuit due to stuff like adding Forms, COM, events and P/Invoke to Java, maybe not.

I can’t remember if it was a joke or serious, but I recall some comment on HN a while back trying to explain why Java was an ML.

Is it this one? https://news.ycombinator.com/item?id=26366665 The comment itself makes sense, though I don't know how is the adoption of new features in the ecosystem.

C# is OO by default, F# is functional by default. Both support either but it's easier to use the tool dedicated to the style you want to program in.

I see this take a lot, and vehemently disagree.

An OO language with record types and pattern matching expressions, plus a vague hint of union types in the future; is not a functional language. Depending on who you ask, it's either a quasi-functional OO language or a bloated OO language. I used to be in the first camp, now I lean towards the latter.

Over time, projects morph into the average of their framework. If you started off badly, if it survives long enough eventually someone will refactor it into something acceptable. If you start off using FP features, eventually they will be eroded away; through friction with external dependencies, or later developers being less invested in the paradigm. In both cases you're usually left with an inconsistent codebase.

When people say that C# is morphing into F#, my usual thought is 'have you ever seen an FP project?' Take some time and read some FP codebases, and compare them with a typical C# codebase.

(side-note: one of the most widely used FP language for web development is elixir. There are a few good open-source elixir projects you can read to get a feel for the structure. Almost all elixir projects follow the same structure, and it's about as anti OO/SOLID as possible, yet still conforming to a vague onion architecture.)

Jesus, you described what happened in my company exactly. Now no one wants to touch that code, the build system is a constant pain, we are stuck in an old version of the tools. The way out is going to be a rewrite.

> I've heard of F# only projects doing great, but I think you need to have a team committed to doing F#.

This is very accurate, and speaks more towards the sociotechnical systems at play here than anything else. It's not just about being a fan of F# and getting management to approve you using it. You need to cultivate an environment where others want to use it too.

I don't know the history of F# at Olo, but they use it in production projects and in a lot of internal tools. It has been well received, C# devs usually have no problem picking it up when needed and enjoy it. We are still ~90% C# but the F# code isn't going anywhere.

I've been that guy. & yeah, found greener pastures a couple years later

No regrets, canopy was an absolute pleasure to use https://lefthandedgoat.github.io/canopy

> No regrets

The victim of this pattern is not you

Consulting and working full time have the same problem, you need to program for the customer, not for yourself. If you work with people who are unwilling and/or unable to learn a tool, then DO NOT use that tool. It doesn't matter how much better it makes your life, you've taken a more or less functional organization and given them a bus factor of 1, where that 1 is you and clearly if you're so high on your tool you're willing to shove it down the orgs throat, you're probably looking to leave already.

Doesn’t that sort of increase your own value to the organization though as well? It would vary based on the situation but it seems like this could sort of work to your advantage if you’re the only person who can reasonably work on something critical (and others can’t be bothered to learn)

I guess, but I think that behavior falls under a dark pattern of employment.

I'm not saying you can't introduce new ideas into your organization, but this is where the politics of development comes into play. You need to get buy-in from your team and management, otherwise you're intentionally hurting your organization.

It also means when there's an outage due to X during christmas or whatever, then you're the only person who can reasonable work on it. Great work.

Only if you can ensure no one ever replaces what you wrote with their own solution.

You become critical in the short term, but also critical to the business to replace in the long term, in the same way that a vendor tripling their price often results in short term profits while customers transition off of them, leading to a long term decline in revenue.

I'd argue it increases your importance but decreases your value.

You become a single point of failure for the org, so you're more important, but you're removing value from the org because you're making it more difficult to scale the organization.

It's your bosses job to make sure there aren't single points of failures. If you try hard to become one, they might start trying hard to make you not one. You're now a bottleneck, after all.

Some places have toxic cultures so that's the norm, but if you're fortunate to be at a better place, don't force their hand to go down that route!

(There's also the aspect where if you're the only person who can do X, but now someone needs to do Y which will actually be ten times more valuable to the company than X, you've closed off that opportunity for yourself!)

I have a conscience, if I did anyone wrong, I'd regret it; the code I left behind has stood on its own

I was that guy too at one job. It was wonderful to work on a few F# projects, but I have no doubt they quickly went away after I left.

I have been on the 'receiving' end of such persons actions. We had one guy who worked probably 50% of his time on using not F#, but another "nice" thing. It never worked well and he spent an incredible amount of time patching it and fixing issues with it. I threw it out the day after and replaced it with some older boring technology, and the problems just went away.

Bravo. Yeah, I learned my lesson.