The Niche Programmer
ano.ee
ano.ee
I never thought of myself as a "niche programmer," but, as it turns out, I sort of, am.
I write native UIKit applications, using Swift. No PWAs, no hybrid systems (like React, Electron, or Ionic). I'm pretty good at it. I've been writing Swift, every day, since it was announced in 2014. It's no longer an "edge" language; it is now the baseline, mainstream, native development language for Apple systems, and I'm a fluent speaker.
It means that the apps I write are really small, really secure, really fast, accessible, highly usable, use very few system resources, leverage the latest Apple tech, have almost no external dependencies, work extremely well, and I write them very, very quickly. Also, because they are UIKit, I can get pretty ambitious, as UIKit is a very mature, ship-oriented system. I am looking forward to using SwiftUI, but am yet to be convinced that it is suitable for really ambitious projects.
It's really difficult to find other native Swift developers that work the way that I do. Part of that, I hate to admit, is probably because I'm 60, and I got really sick of sitting in meetups, with a circle of avoidance around me. I have come to understand that I have "cooties." I won't go where I'm not welcome.
But I have also come to realize that an awful lot of apps for Apple systems are written using hybrid systems, and that many folks are unaware that there are Apple app development languages, other than JavaScript.
And they're only available for one proprietary platform [1], no? Excluding half of the user base for phones (in the US), and probably much more for personal computers, seems like a really bad business move in many cases. And depending on the type of application, it could be considered a different type of accessibility problem. It's depressing, but so often we have to compromise technical excellence and even user experience for economic reasons; in this case, using a cross-platform technology to develop a suckier app that can reach all host platforms is often the smart business move.
[1]: Well, one platform for each form factor.
I do this for the love of the Craft.
But I completely get you, about the business reasons. I can't, in good conscience, argue against most deployments of hybrid systems.
What is sad, is companies that release shoddy hybrid apps, developed by lowest-bid offshore shops (who often do a better job than onshore ones), then refuse to continue supporting their crapplets.
The other thing that bums me out about cross platform “solutions” as a fellow UIKit/AppKit dev is their lowest-common-denominator design, making them incapable of the features that make each OS unique and interesting. I’d like to see the opposite approach, where if platform A was missing something that platform B had, the framework would instead fill the gaps and provide that capability on platform A too. At least for me that’d make cross platform development a good deal more pleasant.
As you noted, a robust set of widgets and capabilities out of the box is important too. The miles-long dependency list that comes with the typical JS app stack is unappealing at best, and nothing is worse than having to hunt down an implementation of a widget you need only to find that the 4 options available all have huge holes in functionality in different places, with 2 in some state of disrepair and 1 not being suitable for your project for some miscellaneous reason.
Might this be asking for patent trouble, though?
Also, I use lots of dependencies. It's just that they are generally ones that I wrote.
I have control issues, I guess...
Everyone wants to write unique UI, but I've learned that's a trap. I write about that, here: https://littlegreenviper.com/miscellany/the-road-most-travel...
Actually, that's not the sad part. The sad part is that Apple, despite being one of the richest companies in the world, basically doesn't care about any attempt to make this situation better, and actually actively works against it.
I work on a cross platform desktop application win/mac, and the process of dealing with OSX development is so frustrating it essentially does not make sense for the size of the user-base. You need Apple hardware to develop. You need an Apple developer account to develop. Xcode is incredibly unstable. C++ support of Clang is out of date. IT management of a fleet of OSX devices is a pain. Notarization and code signing fails regularly due to Apple server downtime. Documentation is horrible, many issues you face must be solved through forum posts where other people shotgun debugged their way out and shared the results. OSX systems are not dependable as long running build servers, frequently causing issues with keychain locks, expiring credentials, volume dismounts, blocking remote access, etc.
On top of that Apple happily blocks any attempt you make at doing cross platform work properly by avoiding support for cross platform APIs: OpenGL is stuck 10 years in the past, and now officially deprecated. Vulkan is not supported. Only supported graphics API is Metal, which is proprietary. WebGL2 support took 5 years to arrive in safari after chrome/ff. WebGPU is likely to follow the same pattern. IOS is locked to a single browser engine. Any attempt to make a webpage behave like an app, works on android but not ios. (example: https://caniuse.com/gyroscope).
Apple doesn't want hybrid apps to work at all, and is busy strangling any initiatives for cross platform APIs. If the browser were invented today Apple would be the first to proclaim a proprietary alternative that would be incompatible and split the world in half. It has created an ecosystem isolated from the world, just the way it likes. As a developer you can learn their ecosystem, and place yourself inside it. However, don't fool yourself into thinking that you are allowing Apple users to use your application, no sir, instead Apple is kind enough to allow you to develop your app for Apple users, and that kindness may expire at any time.
I really cannot understand why a developer would choose to live in such an uncontrollable, closed down, anti-developer system, and even evangelize it.
Apple hates you, why do you love it back? Is this stockholm syndrome?
I do what I do, get the results that I get, and I don’t need to justify it to those that view me with contempt.
A number of years ago, I did take a few months, and learned native Android development (Java, at the time). It was a serious effort, and I spent months, learning the IDE, build system, Play Store, etc. I did publish an app on the Play Store (long since deceased, but I still get Google spam, from it).
I found it to be unpleasant, and returned to the Apple fold. This was nothing against the system. I just didn’t like it.
But usability is always reduced, in cross-platform systems. I have been writing cross-platform stuff for decades. Usually, I wrote the Apple part, and another developer wrote the [usually] Windows part. We have tried things like Qt, which is acceptable, but not especially nice.
No matter how much people crow about how hybrid systems are "every bit as good" as native systems; they are wrong.
If you (and/or your users) care a lot about the Quality of the user experience, then native is the way to go. This is especially true, if there are unusual user interface concepts and widgets involved.
No matter how you write it, though, a released software product is a Responsibility. I liken it to having children. Making them is fun. Having them, is less fun. Once they are in your life, you are Responsible for them.
A native app is limited by capabilities of the platform. Perhaps Xcode is so bad because AppKit does not quite support the use case.
On the other hand you have VSCode, a slow Electron app, but, by it's nature, really easy to extend.
Electron seems to eat a lot of resources, but it can still be fast. I think it tends not to be because the people building stuff with it aren’t necessarily well-versed in writing software. Or perhaps they don’t have the time and resources to make it happen due to constantly shifting business goals, for example.
By all means vscode rarely presents performance issues for me anymore, even on my 2017 MacBook Air. Some things can be slow, but they tend to be specific to extensions and not vscode itself.
Anyway, the actual end result was impressive for how much code we were able to reuse, we were able to build it pretty quickly, etc.
But it wasn’t that great in a number of more subtle ways, like in terms of usability as you mention. Accessibility features were missing in some cases. Various behaviours didn’t match the OS quite right, and we couldn’t easily find ways to make it happen. Text handling of all things was extremely convoluted and hard to get right.
You’re right that it suits cases where you want a skin over a more complex back end service. But even then, I’m not convinced it isn’t worth learning to build with native tools.
We’re obsessed with saving time. Every team I’ve worked on that tried to save time was just saving time to build more stuff with corners being cut. It’s rarely actually worth it. Make a few things, do it well, and I bet you’ll see better results than if you build 100 shitty things.
I’m not particularly successful in software so who knows, I’m certainly not an authority.
Sounds like a dream scenario. Pure native Apple development is without a doubt the most seamless, intuitive, and enjoyable dev environment I've ever worked with. And libraries like UIKit put anything the JS ecosystem has on offer to shame.
What type of applications do you? Are you contracted or a solo dev?
Pretty much a solo dev. I'm semi-retired (but work harder than I ever did, when earning a paycheck).
Since 2012, I've had over 20 apps on the App Store, but most have been retired. I think I'm down to three or four. I list them here[0].
I'm in the process of rewriting AmbiaMara[1] (I'll clean up the docs, as it gets closer to release). It's a ways off, but it's coming along nicely.
I've been enjoying Elm for a few years, because it keeps me away from most of the bloat and churn in web UI tech / frameworks, and it's enjoyable (for me) to work in. It really helps to keep my sanity and avoid burnout. Your choice of Swift is really appealing to me... I'm not a huge fan of "apps" in general though. Still, I would guess that Swift will be around for a long time.
I'll add that it helps to be financially sorted (and no longer motivated by trying to become uber rich).
Yup. I'll have to admit that I was quite nervous, when I was first being shown the door, repeatedly, upon looking for work at 55, but I've managed to "lean in" to living humbly, and being happy with my work.
It's not an "either/or" choice. We don't need to be a captain of industry, or raking in big bucks, in order to be a highly-relevant, productive engineer. I think that some of these companies were insanely self-destructive, to have ignored me; but, as things have turned out, I'm glad they did. I needed to be pushed out of the nest.
I have been writing systems for all my life. These usually have some kind of a "backend," which could be a device and/or network-connected server, and a "frontend," which is what a user of the system sees and interacts with. In some cases, I designed the backend, and in others, I adapted, or wrote, a frontend to an existing backend. I've written a number of realtime APIs; some of which have lasted for decades. I do good, robust, work.
I've really enjoyed writing software that presents a user interface. Over the years, I have come to enjoy the process of developing a "mental model" of a software system, and presenting it to a user. I come from an artistic background, so making it aesthetically-pleasant is also something that I like.
Here's an example: I'm in the process of rewriting one of my apps; a "speaker timer."[0] Simple enough, and the iOS system already has one, so there's no "burning need" for the app; but it's something that I use frequently, and I'm not so happy with the "stock" one.
But the one that I wrote a few years ago (Actually, it started with an ObjC one, in 2012) is too complex and awkward. It needs a rewrite anyway, because it's "dated," so this gives me an opportunity to "get it right."
I'm just finishing the initial setup screen. This screen is actually a greatly simplified amalgam of three other screens in the previous version. I think it works great. I'm not moving on to the other screens, until I consider this one "done," meaning that it has all the autolayout complete, works on an old iPhone SE, running iOS 14, has all the voiceover strings done in English, and has zero (as in "zed") bugs; even small ones. I use a personal process that I call "constant beta," where the app is always at "beta" quality; although it may be incomplete. This results in astonishingly high Quality, and a fairly predictable ship schedule. It also means that integration testing starts from Day One.
Just this morning, I spent a couple of hours, chasing down a weird bug, that turned out to be an iOS14 issue, on iPhone SEs (the 1st gen). I couldn't get it to happen on any other devices, running iOS14. Even though it was a UIKit bug (that seems to have been fixed, since), and it was on a deprecated OS, on a deprecated hardware platform, I still figured out how to work around it, and fixed the issue in my app (for the curious, it was because a toolbar that is directly attached to the safe area insets of the main view would cause a weird hang, upon rotate).
There's three more screens to go, and each one will receive the exact same level of attention. Once that's done, I'll do the localizations for the three other supported languages, and give it accessibility testing.
All along, it will be tested on devices, ranging from iPhone SE (1st gen), running iOS14, to iPad Pro 12.9 (running the latest iPadOS), and even Macs.
All that, for a $0.99 app. It sells like crap, and no one really cares, but I won't do any work, unless it has this kind of polish.
I'll probably write a Watch app, after I get the main iOS/iPadOS/Catalyst one done. I'd started one, previously.
I'm quite aware that this is a commercially infeasible workflow, and I don't care. It's like having a kid's trike, that was made by Mercedes engineers.
Yes, I think this is a really important point. I've discovered over the course of my career that I'm unintentionally very picky with my work. Being in a position (financially) where I'm not forced into work that makes the days feel really really long is amazing.
I like getting older because one's preferences, opinions, and control are so much more refined.
Xcode is a bug farm. I would be filled with chagrin, if it were my project, but it's always easy to be a Monday morning quarterback.
It gets the job done.
Wouldn't surprise me a bit, if it could be done with Eclipse (not my favorite IDE).
It's certainly doable command-line.
So, keep using the native tools as close to the platform is smart strategy on the long term (as fads come and go).
SwiftUI however has made UI Testing at any level unviable.
Man, this makes me sad. I come from a traditional engineering field; in meetup situations, the old guys were ALWAYS the most popular people around due to the sheer volume of problems they've solved and situations they'd seen. I got to talk to so many people whose names are synonymous with their (admittedly niche) fields (except for Ted Anderson[0], who's pretty well-known in the relevant industries) and learned a ton from all of them.
This is so fascinating to me and I guess just a reminder of the HN echo chamber.
Some people i've worked with don't even know what imperative vs declarative programming is. As they say, you become your lowest minimum standard, and that applies to mainstream programming teams too.
It’s a useful pattern when you need to encapsulate some complexity.
Then I found myself working at a lisp shop and learned a whole lot more about it
native iOS in objective-c is getting there too, I think. I see a lot of job listings for it with surprisingly high rates considering everybody is supposed to be shifting to Swift.
The others do still have lots of Objective-C, mixed with Swift (eg. Linkedin, Reddit, etc, slowly transitioning to Swfit).
Airbnb and Uber are the only one that use mostly/exclusively Swift from the Faangmula companies. Most small Startups, that were started after 2016 use mostly/only Swift, but most large companies still do have a lot of Objective-C code.
All this to say that I heartily endorse the OP's strategy.
I've worked at two companies (Apple and Spotify) that I'm pretty sure I would never have been able to get into as a "common" engineer or data scientist with thousands of other applicants for the same role.
Joke aside, data engineers do a wide variety of engineering work related to data. Often that's around data warehousing and business intelligence, sometimes it's work on big data streaming or storage systems, or building yet another integration for marketing.
The breadth is a challenge, which makes it fun and also hard.
Thankless work so that the analysts can turn on the faucet and get nice clean data for their fancy algorithms and models
Also bonus if you know how to run a business and give guidance on what type of house to buy before putting in pipes.
Is there any chance for someone with my profile to get a job in this? Remotely of course, as any remote job would pay times better than anything I could get in my home country. If yes, where does one learn about it more? I see Coursera has some course, but better asking from someone with your experience I guess. My approach to a job is that you do it in order to get money to fulfill whatever you enjoy in life, as long as I'm paid I'll be the best I can. Thanks
Most of the data warehouse work is data transformation and scheduling, so Apache Airflow and writing DAGs in python is a large part. For some of the larger streaming things you've got Kafka and others.
Also every cloud has it's own stack that is sometimes worth using.
A lot of the time they do ETL/ELT mostly with airflow nowadays.
Some use little more than SQL and if they're lucky something like DBT to template and schedule the queries.
A lot of SQL now runs on data warehouses of which snowflake and Google bigquery stand out, but it's SQL nevertheless.
A few lucky ones get to use Spark which is more interesting as it's written in scala or python, but from my experience 99% of the time businesses are better off training business analysts to use SQL and writing the queries in snowflake.
Another interesting area is real time data, for existing e with Kafka. This can be challenging and fulfilling except a lot of the time businesses people will tell you it's cool but they don't want the data to keep changing so could you please aggregate it every day... So you end up with an overly complicated batch system anyways.
For me the sweet spot of practicality right now is Airflow/DBT/python/snowflake.
If you want a fun language, it's really the wrong place to be.
The work can be very fun, but you must take the fun from data analysis. The best software engineering can do for you is to not get on your way (and SQL excels on this).
I'd say the people working with Spike are the unlucky ones. Because they have to focus more on their tools, and not on the analysis.
If I quit my job, it is leadership/management’s responsibility to find a replacement; It’s also their responsibility to encourage knowledge sharing, cross-training, and have resource redundancy within the project.
Edit: It all makes so much sense now https://news.ycombinator.com/item?id=31226278
So maybe Ruby is not niche enough or the hiring company thinks it's no problem teaching someone Ruby, idk. But I'm surprised again and again how little companies care about my actual experience. It's all algo questions or something about deployments/Kubernetes.
That's going overboard - tons of small companies use Ruby, but yes its way easier to find someone who already knows Python than it is Ruby.
I have a track record of picking good pls:. I picked ruby (2003), Julia (2009), elixir (2015), and most recently zig (2019) and no others.
Oh, and while I'm thinking about it, knowledge of how to program a Transaction Processing Monitor) will rarely go amiss.
https://wiki.c2.com/?TransactionProcessingMonitor
The essential idea is apparently to have a central server which does not know your application code directly, spawning workers—application code processes with some communication protocol. The supervisor can then have better uptime guarantees because it doesn't crash when application code crashes. With some more tweaking (what tweaking exactly?) the supervisor is able to enforce transactional consistency: if a worker crashes, we can roll back any partial updates it was doing. Is that about right?
Would be interesting to know about your “how to program” comment in greater detail. Do you mean just the idea of buffering client connections and maintaining a worker pool? Or is there some hard problem around transactionality that needs to be solved and a particular perspective for it? Both? Neither?
To start to understand this, think of a world where
* http and webservers do not exist
* sql and databases do not exist
* ram is measured in kilobytes
* storage measured in megabytes
* there is network connectivity but tcp/ip is not pervasive and there is no dns
* files exist and there are myriad wonderful binary data storage formats
There are so many other weird things but best just to dig into the docs:
https://docs.oracle.com/cd/E72452_01/tuxedo/docs1222/pcb/pbi...
I'm a Machine Learning Engineer, and that seems to check all those boxes. It is niche, it has low offer, and crazy high demand. Sure, salaries are high, but the interview process isn't easier, in fact is way harder. As an MLE I need to excel both as a software engineer (yes, that includes leetcode), and in MLE/science/data science.
For example, the last position I entertained included a phone screen and then 4 rounds: behavioral, coding, machine learning expertise, and a science round, where I was given a problem, had to find 2 papers and make a presentation explaining my approach to solve the problem using the ideas from the papers.
At this rate I'm considering leaving Machine Learning altogether, since the barrier to entry is too high for the people already in.
The barrier for entry means that interviewing for the job, even with experience, is very difficult. As others said maybe the different is there is huge demand. Still I find it paradoxical. You'd think having experience in a field with high demand and low offer would be a pretty good deal. And yet it would be easier for me to find a job as a generalist than as an specialist.
My advice to get in is based on my experience so YMMV.
I'd say the easiest way is to transfer internally to an ML position. That's how I got here. If you are a solid engineer, teams are happy to fill in your ML knowledge gaps. Anecdotically most people I interview got to ML the same way. If your company doesn't have official ML Engineer roles or ML projects, you can position yourself to jump in when the opportunity arises, or even pitch a project yourself (leadership seems to be suckers for ML-for-anything).
The second easiest way is as a student/new grad/junior. Expectations for juniors are lower so it's always easier to get in. The ML round of the interview is mostly theoretical so students aren't at a disadvantage.
I wish my anecdotal interview experience was LeetCode-less, though :)
This is NOT true of all niches. The pay will only be great if the demand for programmers in that niche is high.
Most of the interviewers don't even know to solve those leetcode problems in an optimal way with Clojure.
It might vary if the programming language is not functional.
There are of course performance requirements for almost any project, but whether your service requires 1 ms or 3 ms in production matters a lot less than whether or not your colleagues can actually understand your code.
As a c dev one of the biggest mistakes I see is some optimizing to get better instruction generation but using shifts instead of divides or things of that sort. If you optimizing like that you probably spent more compute time optimizing than your optimization will ever safe. Plus like the complier in C at least handles that for you.
For example, an extra factor of log(n) is hardly ever relevant, constant factors are almost guaranteed to dominate there.
On the flip side, people are also sometimes surprised to see how quickly an n^3 algorithm becomes infeasible even for very modest data sizes.
Of course, understanding big O is still very important and being able to apply it to real-world problems instead of just online code puzzles is even more important.
But I think it's importance is a bit exaggerated in the coding community, when there are arguably much more important skills for engineers such as building good relationships with your colleagues, knowing when to cut corners to get work done on a deadline, and knowing how to negotiate salary and promotions.
For improving performance of larger pieces of code often times it's not really important to talk about big O, but much more about how the data is transformed through the system, how lookups are done in memory, how operations are composed together. Then look at what would be possible in an ideal version of the code, and work towards that in steps. This approach can have orders of magnitude improvements, without changing big O.
If you're starting from scratch, this is much easier. Simply never make your code slow :-)
Program PowerPascal;
{$X+}
{
Who: Michael Warot
When: November 12,1989 (my 26'th Birthday!)
What: The beginnings of a language compiler,
takes source from STDIN, and generates
Assembler Source for STDOUT
}
pp002.zip Power Pascal v0.002 (c) 1993 by Mike Warot
Its a very old OS2-oriented Pascal compiler.
Source: .pas (Borland Pascal)
Output: .asm (32-bit => Masm 6.0 + Link386 = > lx .exe)
Documentation: comments in English
- Amperity uses Clojure ($1bil+ val) - Mercury uses Haskell ($1.6bil val)
I started using Elixir last year after being a long-time Python dev.
Apart from the pros of using a niche language as espoused in the OP write up, the downside I see can be the lack of community, 3rd party libraries and tools and lived experiences which could be discouraging.
Elixir libraries are also pleasantly backwards compatible in my experience (with the occasional exception to be sure). At my company the effort required to maintain currency has been 1/10 that of Ruby in my experience.
I frequently hear that elixir lacks the 3rd party library support of Ruby. If you use sheer quantity as the criteria, then definitely, but in the 6 years I’ve been using Elixir, this has interestingly never gotten in my way. I’ve always either been able to find a library or the problem simply isn’t gnarly enough to deserve a library. Maybe I just haven’t picked the right problems with which to experience this lack though :).
All that to say I think Elixir and Clojure are very similar in these regards!
Not nearly as much as Erlang apparently. I can’t ever bring it up without someone trying to drive the convo towards Elixir
Generally speaking extracting data isn’t the hard part. The hard part is organizing it and presenting it in a meaningful manner.
When Clojure came out I learned it as I was also programming on the JVM at that time. I even joined the local Clojure meetup group. I never worked on real world projects in Clojure but the community around it is awesome. I still have fond memories of that time.
I also learned Emacs and the tooling around it. There was a time when I knew that I'm done with Java, but I didn't know what's next. I ended up choosing Kotlin over Clojure. Kotlin is a great language and I don't regret going in that direction but sometimes I still think about what could have been...
Then I moved to node/typescript and now I'm learning Solidity because that's what's being used in the web3 space. I guess it is still not the time for me to finally embrace Lisp.
You can find a list of companies that hire without any prior Clojure experience on this page: https://jobs-blog.braveclojure.com/2022/03/24/long-term-cloj...
So our hit rate with the Python dev interviews is like 1/10th of what we had with "niche language" so yes mainstream devs are easier to find, but they are 10x as hard to filter. Further the original excuse was that niche language devs were expensive, but by the time we find a python dev who actually has any domain knowledge & experience, we are paying the same.
Throwing more lower-skilled people at a project just makes it move slower and reduces quality.
The median level of skill and conscientiousness (particularly) is just so low.
Which is to say - most of the stuff you expect a senior to just be able to do as part of their job while also writing better code.
A large enough org may be able to offload much of those tasks to dedicated people and/or teams. Similarly a mature enough platform could have lots of BAU dev that can go to grunts because the basic infrastructure already exists and the workflows are well known with good tooling.
So it really depends on organizational size & maturity if its a good trade.
But either way, grunts depend on the lifecycle of the product. You bring in grunts to run the plant once you've built it. When you are in the process of building the plant you have a lot of dev work you want experienced (domain & tech) seniors doing. Foundational decisions and implementations that come from having some scar tissue in the tech & domain. Throwing grunts at the problem early will just allow you to re-implement your previous mistakes in similar ways.
And yes Python doesn't feel like a great system building language, it will probably be tucked away into the same corner as Perl in a decade or so.
As a result I am on my own for more than 20 years and do mostly as I please (assuming the product does what my client wants and does it nicely).
As one niche dev to others, get involved with your niche language/tool online (web based community) and make sure the website advertises jobs.
A lot of recruiting companies go through agencies which only deal with mainstream tools and languages, so unless you produce your own 3rd party addons and get known that way in your niche tool/language, you need to come up with other ways of getting known as its very reputation based and it can be extremely clique even when the devs are sparsely populated around the world!
Fortunately Github is slowly increasing the number of languages it lists and Linked in is helping people get in touch, but you have to find ways to make your self known, its better today than it was a decade or two ago or even earlier.
I was also looking at using Erlang in embedded space and came across https://www.grisp.org/ which is pretty cool.
I stumbled across a strange new (to me) language that had clean, readable syntax, an imperative style (I didn't want or need nested class definitions), and was very parsimonious about the use of parenthesis and brackets, to the point where it relied on indentation and whitespace to indicate control flow, instead of the traditional curly brackets.
And thus began my career as a "niche" programmer focusing on Python.
Wow that's strange to read from someone who blogs about programming !
The idea of a language or tech switch sounds really interesting and I'll keep that in mind.
I even found at one point an F# to JS compiler/transpiler and was able to set up a webpack config that let me write F# in a JS project.
I'd love to be able to use this at work - unfortunately my coworkers were less excited about pursuing this.
I was wanting to work with people who cared more about the work they were doing than those I had been working with. I thought functional programming was a way to so this. I thought that by learning these languages that I would find the programming promised land of good tools and good users.
I never found anything like that though. I couldn't find many jobs using these languages and the few I did seemingly were too difficult to be hired in. And I was never successful in evangelizing them in the roles I was already in.
The F# landscape seems to be worse than it was a few years ago. And I am fairly certain it will never change for the better. I think being .net hinders it in a way that the JVM doesn't hinder clojure. C# is a pretty good language and platform and the community is fairly aligned with the Microsoft's direction and influence on the ecosystem.
Also check this page for a list of companies that hire without a prior Clojure experience required: https://jobs-blog.braveclojure.com/2022/03/24/long-term-cloj...
Almost every day a new job appears, so there are definitely options, and feel free to e-mail me if you have any questions at all (e-mail in my profile).
Also my job involves writing cuda code... does anyone know if cuda is niche? Def not as niche as clojure but I'm thinking cuda stuff is niche enough to have the properties purported by the author.
I live in Europe and work for a European company and it is near 100k (EUR), which in Europe is (afaik) really-really good. I've also seen Clojure job offers for 150-200k (EUR) here in Europe.
That sidesteps the difficulty of counting absolutely how many openings there are, and how many there ought to be
The drawback though is that the job market is so small that you have to be prepared to move overseas to have more than a few companies to choose from.
I myself am a full-stack dev and as of this month I help build AI patent search over at https://iprally.com.
What about Erlang?
Haskell offers something unique in that is a much more academically-modeled functional language. Personally, I like the OTP model better, which then lets you take your pick of a BEAM-compatible language.