[HN Gopher] Ask HN: What is the job market like for niche langua...
       ___________________________________________________________________
        
       Ask HN: What is the job market like for niche languages (Nim,
       Crystal)?
        
       Elixir, Nim, Crystal, Elm...  Currently I am a JS dev, and not
       enjoying it at all. I looked at Elixir and Crystal, like both. But
       I am open to learning anything that is unlike JS at this point. How
       is the job market like?
        
       Author : akudha
       Score  : 117 points
       Date   : 2022-07-23 12:46 UTC (10 hours ago)
        
       | ydnaclementine wrote:
       | PG has a really old (2004) blog about how python programmers are
       | smarter than other programmers. Basically it comes down to the
       | python programmers being ahead of the curve by learning a less
       | popular language (at the time), and they must be using python
       | because they believe helps build better software or whatever.
       | Meaning they're less likely to simply be 9-5 programmers just
       | doing it for the money, but will have opinions on language X or
       | design pattern Y.
       | 
       | I would imagine the python programmers had programmed in java
       | prior, and were able to see the downsides to java versus python,
       | so they had the full experience of why the old tool didn't work
       | and how the new one solves some of those pain points.
       | 
       | PG blog because he says it much, much better:
       | http://paulgraham.com/pypar.html
        
         | [deleted]
        
       | msh wrote:
       | As others have said very small, especially for someone not an
       | expert in those languages.
       | 
       | It should be done more for interest and generally broadening your
       | skills to make you a better developer.
       | 
       | If you want to learn a new language to get a different kind of
       | job start by considering what kind of job you want and then learn
       | the most used languages in that bracket.
       | 
       | Like c/c++ for game dev jobs, Objective C/Swift for iPhone
       | development, java/kotlin for android and so on. For more generic
       | dev jobs the answer would be that Java or C# would be a good
       | place to start.
        
       | jasfi wrote:
       | It's not good for Nim, unfortunately. The language is great, but
       | the community isn't that big.
       | 
       | If you're looking for a web framework with an ORM for Nim, check
       | out Nexus: https://github.com/jfilby/nexus
        
         | Stevvo wrote:
         | I've heard good things from guys working with Nim at
         | Nimbus/Status; precisely because the community isn't that big
         | they have great communication with the language maintainers and
         | can even influence future language features/development.
         | 
         | But that is predicated on you finding a job first!
        
       | japhib wrote:
       | I've been working at a job that uses exclusively Elixir for
       | backend work, for 100+ engineers. I've gotten multiple messages
       | on LinkedIn from recruiters from other companies that also use
       | Elixir. So I can't speak about those other languages, but the
       | Elixir job market is strong.
       | 
       | Seems like there's a lot of listings if you just Google "elixir
       | jobs." There are also a few dedicated sites such as
       | https://elixirjobs.net/
        
         | lawik wrote:
         | As an active community participant and freelance Elixir dev
         | I've been dipping my toe in helping companies recruit Elixir
         | devs and helping devs find good Elixir jobs. There is more of
         | both parties than I could possibly address and exhaust. All the
         | elixir devs I know with experience are thriving.
         | 
         | It is a niche and I find it a healthy one, significant and
         | growing. If anyone wants to get into Elixir I'm happy to give
         | it a whirl. My site has my contact info.
        
       | pjmlp wrote:
       | Unless you're at a startup using them, hardly noticeable.
       | 
       | It is better to pick languages based on platforms than the other
       | way around.
        
       | neilv wrote:
       | This question is dear to my heart, having been a pre-popularity
       | adopter of a few language ecosystems that did and didn't become
       | popular (including C++, Java, and Scheme/Racket).
       | 
       | You can search job listings on LinkedIn, Angel.co, etc.
       | 
       | But if it's only a small number of search hits, also consider the
       | possibility that even some of those might not be genuine
       | opportunities, so you have to look at each one. Examples of why:
       | 
       | * A hiring manager/lead is an enthusiast of the fringe tech., and
       | the kinds of people it attracts, but not actually using it. Or
       | not an enthusiast, but has heard it's a way to get the attention
       | of some of the best developers. (I have done this, and been clear
       | about it.)
       | 
       | * Startup (maybe more likely to choose fringe tech because the
       | tech cofounder happens to know/like it) that is trying to look
       | like they're doing well enough to be in a position to hire, when
       | they're not yet.
       | 
       | * Recruiters trying to keep the funnel full, so candidates ready
       | as soon as openings available.
       | 
       | * Mandated postings, when the org already knows it wants to hire
       | or promote a particular person, so that person's resume gets
       | turned into an overly-specific job post.
       | 
       | * (I've not confirmed this one in the wild, but it's similar to
       | other growth hacking, and you could see how it might appeal in a
       | market heavy with resume-driven development.) Promoting some tool
       | or platform by faking job posts for it.
       | 
       | Note that this doesn't mean the fringe platform is without merit,
       | and sometimes the merit is self-defeating. The norm in one fringe
       | ecosystem I was involved with, on the rare occasion an
       | established company used it, was for one super-productive person
       | to quietly do a team's worth of work, and... the org never really
       | needed to hire more. (And if that established company got
       | refocused on faster growth, then an MBA is probably going to
       | think they need to switch to a more popular platform, so that
       | they can hire a large number of people "who can hit the ground
       | running", fast.)
       | 
       | Maybe also relevant: consider the risks of investing career in a
       | fringe ecosystem, which was the topic of my first Ask HN post
       | (from an engineering lead ethical perspective):
       | https://news.ycombinator.com/item?id=23655604
        
       | a6chris wrote:
       | I wondered similar, though for Elixir not for Crystal.
       | 
       | For the UK jobs market:
       | 
       | https://highestpayingjobs.co.uk/it/elixir
       | 
       | https://highestpayingjobs.co.uk/it/nim
       | 
       | Fair warning, it's my site - was an experiment in learning NextJS
       | so fairly rough around the edges. I will add Crystal when back
       | home.
        
         | dom96 wrote:
         | where are you getting the jobs data from? I'm surprised there
         | are this many Nim jobs tbh
        
           | a6chris wrote:
           | yeah... tbh it's looking like a bodge on my part :(
           | 
           | It's scraped data from four UK jobs boards, de-duped where
           | possible but as above it's rough.
           | 
           | Having just searched the jobs boards manually, I can see
           | "nim" comes back with "National Intelligence Model (NIM)", so
           | for sure that will be a false positive.
           | 
           | Sorry :(
        
             | jasfi wrote:
             | There's also IBM's Network Installation Management (NIM).
        
       | biztos wrote:
       | If you just want something "unlike JS" it should be pretty easy
       | to figure out which languages are in demand and pick the one (or
       | two) that most appeal to you.
       | 
       | If you're particularly into obscure languages, I suggest getting
       | involved with the language community (meetups, open-source
       | projects, etc) because for the less-popular languages the
       | community and the employers have a _lot_ of overlap.
        
       | 542458 wrote:
       | I work for an established medium sized company that is always
       | looking for Delphi Pascal programmers for a realtime directX
       | graphics application. Not surprisingly, this skillset can be hard
       | to find in 2022.
        
       | eckza wrote:
       | I just got my first job as a full-time Elm (and Haskell)
       | developer a few months ago... and it's been an incredible
       | experience.
       | 
       | Those of us who love this language and want to see it succeed are
       | highly invested in creating more Elm jobs.
       | 
       | Jobs pop up in the #jobs channel pretty often in the Elm Slack. I
       | interviewed for several before finding the perfect fit.
       | 
       | http://elmlang.herokuapp.com/
        
       | shaftoe444 wrote:
       | I program backend Java Spring CRUD stuff. I love learning (and
       | building) niche languages in my own time but I would always be
       | suspicious of using these in real production. Need a really
       | compelling case not to use something boring that just works when
       | your job is on the line.
        
       | blocked_again wrote:
       | Best strategy for becoming a high paying/good software engineer
       | would be to think of yourselves as problem solver and language as
       | just one of the tool for problem solving.
       | 
       | Thinking of yourselves as someone who is a writer of a certain
       | programming language is self constarining and missing the point.
        
         | ldjkfkdsjnv wrote:
         | No the best strategy is to memorize leetcode problems. All the
         | highest paying jobs (>400k) require dictionary like recall of
         | computer science algorithm fundamentals.
        
           | biztos wrote:
           | Well certainly not _all_ but that strategy, if you can pull
           | it off, will probably get you a very high-paying job and
           | maybe you won 't have to work so hard.
           | 
           | But that's not at all what the OP asked for. Maybe they're
           | already making >400K slinging JS at Facebook or Google. Lots
           | of people do!
        
         | thr0wawayf00 wrote:
         | I used to think this way and wound up completely exhausted in
         | my career. Coming from web dev, I used to volunteer to dive
         | into a Objective C repo to fix some random bug in a mobile app
         | and then a week later my boss would ask me to build a big
         | feature in that app. I'd spend a few weeks getting up to speed
         | on the language and build the feature, and then I would never
         | use what I learned again. My boss would ask me to dive into
         | another tool I don't really know and the cycle would repeat ad
         | nauseum. In hindsight, I've wasted so much time digging into
         | tools that I've never used again.
         | 
         | I definitely learned some good lessons and recognized some
         | patterns along the way, but I think the "just pick it up and
         | learn it" attitude contributes to poor code quality in a
         | commercial context since jobs usually time-box things. I'm a
         | fan of picking something up that I can get expert feedback
         | from, which there again, requires expertise.
        
           | Aperocky wrote:
           | > contributes to poor code quality
           | 
           | I have another perspective, I think code quality are pretty
           | uniform across languages, either all of ones code quality is
           | poor or it will be fine across all language one writes.
           | 
           | Most of the code quality stems from logically dividing the
           | building blocks and making it readable. Hence it should be
           | logically traceable and uses the basics whenever possible.
           | This is good, readable code.
           | 
           | Obviously some languages demands greater knowledge (e.g. C,
           | Haskell) to master and use appropriately but they are a
           | minority.
        
             | wutbrodo wrote:
             | I strongly disagree. It's very visible when someone is
             | trying to write (eg) Python in C++ or vice versa, in a way
             | that can substantially harm readability.
        
           | zerr wrote:
           | Sounds like a dream job! No joke.
        
           | kevinmchugh wrote:
           | There are organizations that generate forgotten apps that are
           | basically used but unmaintained. These are tarpits for
           | developers. You don't want to be the person they fling at
           | every forgotten codebase. They tend to be sideshows - if they
           | really brought in the money, or the users, the business would
           | invest in them and have people who know the language.
           | 
           | There's value in being able to go in, fix a little problem,
           | and make things better for your customers. But you have to
           | balance that against becoming the guy who works on the
           | unimportant projects. That's real bad. If there's growth
           | potential for the forgotten app, you have to get buy-in from
           | the business and not just sideline yourself away from the
           | things people care about.
           | 
           | Often these tarpits were contractually mandated. One customer
           | wants a particular integration, so a developer builds it, and
           | it works for the customer and everything is fine until
           | another customer comes along wanting a similar integration
           | and now the original dev is gone.
        
             | edgyquant wrote:
             | Refactoring old codebases into something nice to work on is
             | comfy though. It's basically what I do in the startup world
             | I just use less niche languages.
             | 
             | Although I'd suspect there isn't a lot of refactoring going
             | on in some of those code bases you describe.
        
             | sdoering wrote:
             | I know from quite a few traditional corporations,
             | especially banks that have very central old systems that
             | they pay people enormous day rates to maintain.
             | 
             | But the question would be if one wants to be the go to guy
             | for keeping old cobol things running.
        
               | HPsquared wrote:
               | You could call the general skill "software archaeology".
        
               | szundi wrote:
               | The value of any other stuff you learn other than solving
               | problems has half life. If you can be paid extra for
               | Cobol stuff for a decade or two, then why not use this
               | opportunity and get up to speed in 2-3 years after that.
               | 
               | If you have just a bit of bad luck, you may have a
               | carreer with no real deep involvement with anything, not
               | even talking about the fact that the language is just one
               | aspect of your productivity.
        
           | rco8786 wrote:
           | > I've wasted so much time digging into tools that I've never
           | used again.
           | 
           | Don't think of it this way. Learning new tools is almost
           | never a waste of time, you just don't know when you'll need
           | the lessons learned next. But you will.
        
             | rolisz wrote:
             | It depends. Maybe the alternative is to get better at a
             | tool you already know. Maybe you can be a jack of all
             | trades, master of none, or you can go really deep into only
             | 2-3 things. It depends a lot on your personality I think.
        
             | weatherlite wrote:
             | What lessons do I learn from learning webpack? Or whatever
             | the new way of bundling things in FE is called now?
             | 
             | Compare that to understanding C or UNIX. There are skills
             | that decay much slower than others.
        
               | biztos wrote:
               | Maybe it's counterintuitive, but I think the "jack of all
               | trades" role should be given to someone who's very
               | senior, but isn't focused on career advancement.
               | 
               | It sounds like you got stuck learning more trivial things
               | before you had a good foundation in something more
               | substantial (like C or UNIX).
               | 
               | If it weren't for the rampant ageism in the industry,
               | that job might be a perfect fit for someone in their 60s
               | who has already written a few million lines of C and is
               | happy to help less experienced people just get unblocked.
               | 
               | Instead it often falls to the "junior senior" because the
               | "senior seniors" are all pushing 30 and need to work on
               | portable skills.
               | 
               | (Just my observation of the industry, maybe your own case
               | was different.)
        
               | LAC-Tech wrote:
               | As a fellow webpack victim, the new way of bundling
               | things in FE is esbuild and it's better in every way -
               | faster, simpler to configure, easier to understand... and
               | did I mention faster? my god it's so much faster.
               | 
               | Your point about wasting your finite life dealing with
               | webpack still stands, but just want everyone to know that
               | there is a ray of light in frontend.
        
               | goodpoint wrote:
               | > Compare that to understanding C or UNIX. There are
               | skills that decay much slower than others.
               | 
               | Correct! Knowledge around C, Linux, CPUs and optimization
               | last many decades.
               | 
               | Knowledge of tools and libraries in high-churn languages
               | last years at best.
        
               | EddySchauHai wrote:
               | I've found a lot more career happiness with focusing on a
               | long-term domain (networking), long-term expertise
               | (testing), and a stable tech stack (python, c, etc). Got
               | pretty close to burnout chasing the latest libraries in
               | the latest languages a few years ago but now I'm very
               | happy making sure the product is cutting edge but the
               | tech stack is stable.
        
               | weatherlite wrote:
               | This is what I'm trying to do as well now (move from full
               | stack web dev to something more in the lines of what
               | you're describing). Any tips you can remember on how to
               | make the move?
        
               | EddySchauHai wrote:
               | I spent a bit of time practicing these tech stacks in my
               | own time and fitting them into prior jobs where I could,
               | but honestly it's worth just getting out there and
               | applying.
        
             | mmartinson wrote:
             | It's valuable to consider the opportunity cost of this
             | compared to a deepened knowledge of an already productive
             | tool
        
           | sys_64738 wrote:
           | > My boss would ask me to dive into another tool I don't
           | really know and the cycle would repeat ad nauseum.
           | 
           | There is power in saying No.
        
             | unnouinceput wrote:
             | There is power in saying "Yes, for this price" too. Explain
             | the problem and the damage to your mental health if you do
             | that, hence the price.
        
               | afarrell wrote:
               | Your first sentence is correct. Your second sentence
               | would be better revised to "Explain the problem and the
               | fact that the client will be signing on for a long
               | timeline and high level of schedule-risk. Then work at a
               | pace which does not damage your mental health."
        
           | zinodaur wrote:
           | an edit I would make to
           | 
           | > think of yourself as a problem solver, rather than a
           | programmer of a specific language
           | 
           | would be to
           | 
           | > steer away from problems that are boring to you
           | 
           | E.g., there are very cool programs being written in Objective
           | C, so I wouldn't write off a job just because it was in
           | Objective C
        
           | winternett wrote:
           | I can't tell you how often a huge and expensive Oracle DB app
           | design project turned into just emailing spreadsheets
           | instead... That would get me fired.. -Senior Developers
           | Everwhere. :P
        
           | rtlfe wrote:
           | That's pretty excessive. I've switched languages whenever I
           | get a new job, every 2-5 years. I think this is more what OP
           | had in mind.
        
             | ipaddr wrote:
             | How do you switch languages during a job search? Are you
             | avoiding companies with language requirements (four years
             | Ruby)? Do you run into language/framework tests and/or
             | homework assignments in languages you are unfamiliar with?
        
               | lmarcos wrote:
               | It's easy to trick recruiters about tech stack ("We
               | require someone with 5 years of experience in Django".
               | Me: "Sure, I'm qualified"... While in reality I have over
               | 6 years of experience in RoR and I have probably used
               | Django in one side project). The moment you pass the
               | screening part, then it comes the part when you judge
               | your future/potential team: do they care about good
               | engineers or good django engineers? Usually, it's the
               | former.
        
               | jrockway wrote:
               | Does anyone still have language requirements? I did my
               | Google interviews in Perl and wrote mostly Java and Go
               | there. At my current job, our codebase is all Go (expect
               | frontend) and pretty much nobody we hire has prior Go
               | experience.
               | 
               | Prior experience is almost a curse these days. I learned
               | Go by having the Go team review every one of my CLs for a
               | year. Now I do Go code reviews and think "that simply
               | isn't done, I would never have been allowed to check that
               | in", but often have a hard time supporting my arguments.
               | (When Effective Go, Code Review Comments, and Test
               | Comments fail me, I usually resort to snippets from the
               | standard library. "This pattern appears 0 times in the
               | standard library, I don't think we should use it." It's a
               | lot of work, but I will say that a few things I thought
               | were simply never done are actually done. And that's my
               | standard; I hate it, but Go itself did it to implement
               | Go, so you can too.)
               | 
               | Side rant: I guess the Go team stopped doing this. Read
               | Kubernetes for the current state of Go at Google. Wow.
        
               | azemetre wrote:
               | Is the wow bad or good?
        
               | rtlfe wrote:
               | I've interviewed at probably 15+ companies over the last
               | decade, and none of them had language requirements or
               | tests. Honestly I see those things as red flags. If you
               | can find somebody with good problem solving skills and
               | proficiency in any language, they'll be able to pick up
               | your language no problem.
        
               | wizofaus wrote:
               | I'm guessing that's not typical for most devs and most
               | job openings. Recruiters in particular seem to assume
               | they need to find devs experienced with particular
               | stacks, and for companies who need to quickly re-fill
               | roles after losing staff, a good dev with experience in
               | the stack/ecosystem you've been working with is always
               | going to get up to speed faster than one without that
               | experience. I'd also say convincing hiring managers that
               | specific libraries/ platforms/languages/tools that you've
               | been using shouldn't be listed as "must have"'s in a JD
               | is hard.
        
               | rtlfe wrote:
               | > most devs and most job openings
               | 
               | I'm not sure. I'd guess very few companies that hire more
               | than 20 devs a year would have any language requirements.
               | But I don't know what % of jobs are at companies of that
               | size.
        
               | wizofaus wrote:
               | In my own city I'm not sure there are any such companies.
               | But I was involved in helping out with a hiring round for
               | Thales recently that were looking for 15 devs. They had
               | very strong language requirements.
        
               | hutzlibu wrote:
               | "they'll be able to pick up your language no problem."
               | 
               | That still takes time. If someone is already experienced
               | in an (complex) ecosystem, he or she will be way more
               | effective in it, than someone who has just general
               | skills. I guess I am a very good problem solver. But if I
               | suddenly would have to do a C++ project with all its
               | footguns, I am not aware of (last time I coded in C++ was
               | in university)? I would suck in it for quite a while.
               | This would not be effective at all, unless I would want
               | to change my skillset to the C++ ecosystem.
        
               | rtlfe wrote:
               | > That still takes time.
               | 
               | Yes. I want to work somewhere that shows they're
               | committed to the long term, not somewhere that's focused
               | on how much I'll get done in my first week.
        
               | fab13n wrote:
               | I prefer companies which are open about the technologies
               | and languages I'm experienced with. That's a huge green
               | flag, that they consider their software engineers as
               | smart people solving hard problems while continuously
               | learning new skills. It also means they listen to their
               | senior technical staff, which consider that learning new
               | bits of stacks is hardly the most complicated thing they
               | expect you to do.
               | 
               | As opposed to companies which consider them as glorified
               | factory workers, who are insufferably hard to manage and
               | monitor.
               | 
               | I'm currently working with RoR, which I'd never used
               | before, and what matters is that I know algorithms, SQL
               | beyond ORM, how to write code which won't be a nightmare
               | to maintain in a couple of years, etc. All those skills
               | are the same in Rails, in Django, in C++.
        
           | jjice wrote:
           | > Coming from web dev, I used to volunteer to dive into a
           | Objective C repo to fix some random bug in a mobile app
           | 
           | The thing about this is that this isn't just a language
           | change, this is an ecosystem change. It's one thing to go
           | from writing Python based web apps to Ruby based ones,
           | because web dev has a lot of concepts that will apply no
           | matter the language. Objective C might be something you can
           | pick up no problem, but having the learn all about mobile
           | development and that ecosystem is a much larger task, and I
           | could absolutely see that getting exhausting if you're
           | hopping from web, to mobile, to desktop, to embedded, etc.
           | 
           | Ecosystem switching requires a lot more of a knowledge shift
           | than just a language does, IMO.
        
             | wizofaus wrote:
             | I'd agree with that. I even think the difference between
             | frontend JS development and backend JS development is
             | bigger than, say, backend Java and JS development. But
             | managers, even ones with tech backgrounds, tend to assume
             | the language is the key skill. A good developer should be
             | able to master a couple of different ecosystems given
             | enough time but expecting them to constantly jump between
             | them is never going to lead to great results.
        
           | BryanBeshore wrote:
           | Having done the merry go round of different languages, it
           | also feels great gaining expertise in an individual language
           | and to utilize new (release) capabilities of that the
           | language.
        
             | thr0wawayf00 wrote:
             | Absolutely. Conversely, it's frustrating to deal with a
             | build and release system that's subpar compared to what
             | you're used to working with, but I recognize some folks
             | probably feel that way about my preferred tools. That's
             | just where I've chosen to invest my time I guess.
             | 
             | I was shocked at how hellish compiling and releasing a
             | large iOS app was compared to deploying a web service, not
             | to mention setting up the development environment and
             | installing dependencies.
        
               | wizofaus wrote:
               | Yep, if I never have to deal with an automated CI/CD
               | pipeline for iOS again (especially trying to reliably run
               | unit tests - the simulator is flaky as hell) I'll be very
               | happy. I don't even mind the MacOS-only requirement so
               | much (though it does suck), but Apple's tendency to
               | constantly force breaking changes on you is just an
               | endless source of pain (by force I mean, release to App
               | Store not permitted unless you build with version X of
               | Xcode, which requires version Y of MacOS which is
               | incompatible with version just-about-anything-else or
               | everything else you're using.)
        
           | Taylor_OD wrote:
           | Yeah I agree. I know growing and learning is the job. But how
           | much am I going to use X in the future? I did one project in
           | PHP. Just enough to learn I don't really like working in PHP.
           | Is a few months of PHP experience useful in later job
           | searches?
        
         | checkyoursudo wrote:
         | tl:dr What do I do if I just want a job that I enjoy and do not
         | care much about the money?
         | 
         | I do not need a high paying job for various reasons, but I
         | still want(/need?) to do something fulfilling and wouldn't mind
         | getting paid for it.
         | 
         | I like research. I have been doing academic research for the
         | past few years, so I am still considering a PhD. I definitely
         | do not have to worry about a high salary there! But I also like
         | plain old solving problems with programming, so I am
         | considering going out and getting a job as a programmer
         | (again).
         | 
         | Since I don't care much about high pay, and I do care about
         | enjoyment and self-fulfillment, it seems that I should be picky
         | if I am going to look for jobs. I do not find fulfillment in
         | high compensation, though I understand that others might. I
         | would rather do something fun, interesting, or unusual, while
         | avoiding features I already know I dislike.
         | 
         | For example, I learned OOP a bit in college during my first-
         | ever programming course (Java). It didn't stick and all I
         | learned was that I don't like OOP. Surely this suggests I
         | should avoid jobs/languages that require an OOP paradigm?
         | 
         | Like, sometimes I think I should just go back and hardcore
         | brush up on my C programming and go get a job writing C
         | somewhere. Or see if I can translate my academic R/Python
         | skills somewhere. Or go learn some functional language and see
         | if I can get a job doing that.
         | 
         | > Thinking of yourselves as someone who is a writer of a
         | certain programming language is self constarining and missing
         | the point.
         | 
         | I totally get where you are coming from. For example, many
         | people do jobs they dislike or don't care about knowing that it
         | enables activities/experiences/purchases they do like or care
         | about. But really, does this not fully depend on what each
         | person subjectively thinks "the point" is?
         | 
         | The point for me is that I would like to enjoy all of my life,
         | not hate my work time and only enjoy my leisure time.
         | 
         | Maybe I'll figure it out someday.
        
         | mistrial9 wrote:
         | yeah disagree - as a high-skill consultant coming in as a
         | problem solver, I mostly got dirty jobs that no one wanted to
         | touch. "Pay someone to do it!" you can hear the cries. The
         | interesting and low-touch projects got grabbed quickly by
         | insiders. Super-problem-solver was not a good strategy in
         | practice. This profession has a long way to go in some
         | respects.
        
         | winternett wrote:
         | Agreed, there are definitely some langs that go out of their
         | way to be overly complex, obscured, obtuse, and proprietary in
         | nature that I totally avoid.
         | 
         | They can lead to what I call "rabbit hole" jobs, which make it
         | very hard to change disciplines thereafter.
         | 
         | Now most recruiters, and even hiring managers, rarely have an
         | idea of the nuances of development during the interviews I
         | attend... Because usually their a buddy of executives within
         | the company more often than being there for their capabilities
         | or educational background. When the technical component comes,
         | I also often get paired by another dev within the company, or a
         | person with a technical grasp that's totally outside of what
         | they know, so keeping my knowledge diverse, and being able to
         | adapt to what I don't know is key in order to be worth a good
         | salary.
         | 
         | Adapt and improvise, manage their expectations of you, but most
         | importantly, know how problems get solved correctly. The tools
         | used don't matter if the house built is well done.
        
         | barankilic wrote:
         | Good luck with listing "problem solver" as a skill in your
         | resume. I don't think anybody will care about it.
         | 
         | As an experiment, one can create two resumes with different
         | identities where the first one is listing Nim as a skill and
         | the other one is listing Java and Spring as skills, and apply
         | to the same jobs. I wonder what the ratio of replies will be.
        
           | Strom wrote:
           | If you're an actual problem solver, you don't even need a CV.
           | Your clients will be so happy that they will recommend your
           | services to their buddies.
        
         | itsEtai wrote:
         | This attitude is a great starting point, but take caution to
         | curate a future for yourself that you find interesting.
         | 
         | Whatever work you do, you will forever be the person who has
         | done that work. Next time something needs to change in that
         | domain or language, you might find yourself talked about as a
         | specialist!
         | 
         | The moral is to choose and pick your projects carefully.
         | Vocalizing your experiences with your manager goes a long way
         | for shaping your future: like "I liked working in X and I want
         | to do that more" and "I am glad I got to try Y, but I really
         | didn't enjoy it."
        
         | ParetoOptimal wrote:
         | > Best strategy for becoming a high paying/good software
         | engineer would be to think of yourselves as problem solver and
         | language as just one of the tool for problem solving.
         | 
         | Some languages contort and constrain your thinking in bad or
         | silly ways.
         | 
         | > Thinking of yourselves as someone who is a writer of a
         | certain programming language is self constarining and missing
         | the point.
         | 
         | I find this view tends to lead to only using popular languages
         | anyway because you don't seek out any specific language, so the
         | effect of this belief itself is self-constraining.
        
         | nickjj wrote:
         | This is very true but there's still is a very big difference
         | between knowing languages like JS, Python, Ruby or Go but then
         | jumping into a place that uses Elixir or a niche language
         | that's different than a lot of other popular languages.
         | 
         | For example I took a position to do mostly infrastructure work.
         | Most of their services are written in PHP which I haven't used
         | since the early 2000s. I wouldn't classify myself as a PHP
         | developer. Sometimes I find myself diving into the code to
         | self-solve issues I have that are infrastructure related. My
         | thought process is if I can solve a problem and it's within my
         | scope of things to do I'd much rather just do it than add extra
         | work to another developer on the team. In the worst case
         | scenario someone with actual PHP experience who does the code
         | review will offer suggestions to make the code better.
         | 
         | I don't really know PHP but I can look around and navigate the
         | code without issues. There's nothing that looks too foreign and
         | the code is easy to grep to find stuff. It's also not too bad
         | to trace code in a large app and understand the logic. There's
         | also a massive amount of Google results for almost any problem
         | you can think of. It really means for a lot of cases you can
         | combine previous experience and be productive in a similar
         | language without really knowing it. Enough to contribute real
         | code that gets shipped to production.
         | 
         | I ended up doing this yesterday where I added an IP whitelist
         | address exempt config option to one of our apps. I wanted to at
         | least toy with the idea of doing IP range detection within a
         | CIDR block.
         | 
         | In Python this is really easy, the standard library has
         | functions to do this with 1 line of code. Ruby's implementation
         | is even easier and built into the language. For PHP I had to
         | Google around but found a pretty small custom function to use
         | in less than 2 minutes. For Elixir? Well you have to use a 4
         | year old+ third party dependency or dive down into Erlang and
         | understand pattern matching and write a bunch of code to
         | manually do the comparisons. Maybe there's a good Elixir
         | solution but it wasn't on the first 3 pages of Google when
         | searching for similar terms as I did for Python, Ruby and PHP.
         | Weirdly enough if you search for "elixir check if ip address is
         | in cidr block range" most of the top results are StackOverflow
         | posts for other languages. There's no contest in comparing the
         | amount of effort it took to get a solution.
         | 
         | I know this is 1 just example but I also know when I tried
         | learning Elixir (and did end up writing about 10k lines of code
         | of it) I kept running into situations that took half a day or
         | longer to figure out while actively trying hard to learn and
         | use the language. These problem could be fully solved in a
         | production ready way in 5-10 minutes with Python or Ruby (and I
         | guess PHP too) either by knowing how to solve it in an
         | imperative way or finding nearly a perfect solution when
         | Googling that's digestible enough to where you can fully
         | understand it and apply it back to your problem.
        
           | throwawaymaths wrote:
           | Did you try asking on the forums?
           | 
           | https://hexdocs.pm/net_address/IP.Subnet.html
        
           | StrayM wrote:
        
         | spyremeown wrote:
         | I don't think that strategy works best. Most of people I know
         | that get paid very good amounts are specialists in a given
         | framework or language, like knowing the ins and outs of PHP for
         | example.
         | 
         | I rather say "be a generalist on the long term and a specialist
         | on the short term".
         | 
         | This is all my opinion and comes from my personal experience,
         | though. Take it with a grain of salt.
        
         | zerr wrote:
         | Industry gatekeepers do not agree, unfortunately.
        
         | Nextgrid wrote:
         | While the basic syntax is relatively easy, knowledge of APIs
         | (whether standard or third-party libraries), design patterns
         | and conventions takes time (and practice) to master regardless
         | of skill level.
         | 
         | Being an expert at a single general-purpose language will often
         | make you more productive as you can focus on the business
         | problem at hand rather than spreading yourself thin across
         | different languages where you'll perform worse until you become
         | an expert at them (which is unlikely for anything more than a
         | handful of languages and even that requires working with them
         | regularly).
        
           | jghn wrote:
           | Deep expertise isn't as useful day to day as we often
           | portray. With a little elbow grease one can get to a place of
           | being more than baseline productive in relatively short
           | order. Depending on the language I expect a reasonably good
           | dev to be able to be "fluent" in the range of a few weeks to
           | a few months. And it's not like they'd be useless the entire
           | time before that happens.
           | 
           | To me, that's a reasonable investment to make.
           | 
           | Edit: This does require a certain persona in the space of
           | "reasonably good dev". People who have spent their entire
           | life focusing on a single language or paradigm are a lot less
           | likely to be able to shift gears. People who have broad
           | exposure to different concepts are more able to say "How do I
           | do X in Y?" and stop fighting their new language.
        
             | JamesBarney wrote:
             | I've seen huge differences in productivity between people
             | who've been working with a given stack with for years vs
             | months.
             | 
             | The quality just isn't even close. Recently I outsourced a
             | project to two groups of people. A jr dev who had 2 years
             | of experience but all of that experience was with the tech
             | stack, and 2 sr devs (10 yrs experience) who had < 6 months
             | experience with the tech stack. And the jr dev (who was an
             | inferior dev in general) blew them out of the water because
             | of the tech stack experience.
             | 
             | And honestly in terms of raw talent I think the sr devs
             | were better, but it just didn't make up for the lack of
             | tech stack experience.
        
               | fonix wrote:
               | In your example it the answer may be "none", but I'd be
               | curious of the amount of tech debt that may have been
               | introduced by the jr vs the sr's; whether or not sr's had
               | better intuition.
        
           | brundolf wrote:
           | Also nuances about performance, easy-to-make mistakes,
           | historical accidents, workarounds for common issues, etc
        
         | yieldcrv wrote:
         | Although true for the job, this is a bit disingenuous for
         | _getting_ the job market because recruiters are absolutely not
         | thinking of you as a problem solver with language being just
         | one of the tools.
        
         | nly wrote:
         | It's a cute theory, but the reality is most employers want you
         | to be relatively efficient from day dot.
         | 
         | I work in a team with a codebase split 50/50 between C# and
         | C++, and if you're not proficient in one of those then the
         | chances of you getting hired, even if you're an incredible
         | programmer, are slim.
        
           | Shorel wrote:
           | The reality is that today's job market is not ten-years-ago
           | market.
           | 
           | Employers and companies can't find enough developers to
           | satisfy the demand.
           | 
           | They should provide a bit of wiggle room and train internally
           | as well. Three months getting into a new language/framework
           | is not that much compared with the cost of hiring.
        
           | dnissley wrote:
           | This is a trait of an employer that I consider a red flag. If
           | they don't understand that most programming languages are
           | pretty similar, and can be picked up quickly by any willing
           | person, they probably don't understand a lot of other things
           | in regards to tech
        
             | hardware2win wrote:
             | Quickly=?
        
               | wizofaus wrote:
               | "Any willing person"=?
        
             | julianeon wrote:
             | That's not fair. The whole point of "footguns" is that they
             | are _not_ obvious and that the reason more experienced
             | people don 't set them off, is because they've directly
             | experienced their results before.
             | 
             | Our industry went to the trouble of inventing a whole new
             | language (Rust), which is now being championed by major
             | industry players, _because_ those footguns are so non-
             | obvious.  "Trusting" smart people to "just not make
             | mistakes with pointers" was clearly the wrong choice.
             | 
             | If you haven't used C and C++ before, it's reasonable to
             | think you're going to make those first-time mistakes with
             | your code inside their codebase. That's a good argument for
             | not hiring you and only hiring experienced C/C++
             | programmers.
             | 
             | In practice, that's exactly what those companies do.
        
           | whimsicalism wrote:
           | Having a C# codebase and being unwilling to hire Java
           | developers seems like unnecessarily constraining yourself.
        
             | metaltyphoon wrote:
             | Depends a lot on what type of software is b ing written.
             | The people that keep beating the drums that Java = C# have
             | not worked with the language extensively enough. So many
             | things outside of basic languages constructs are different.
             | Tooling is also a big hurdle to change too.
        
         | dom96 wrote:
         | Precisely. Any good company won't care what programming
         | language you are specifically proficient in. They care about
         | how proficient you are in learning new things.
         | 
         | I have created a lot of Nim projects and implemented much of
         | its stdlib. My full-time job isn't using Nim, but the
         | experience I gained through my work in Nim has helped my career
         | significantly.
        
           | akudha wrote:
           | _Any good company_
           | 
           | The keyword here is _good_. Even then, this isn't largely
           | true. It is quite hard to convince companies to hire for a
           | skill that you already don't have experience in. In most
           | cases, there are gatekeepers - those lovely recruiters who
           | don't know the difference between a computer and a washing
           | machine.
        
             | dom96 wrote:
             | if you're optimising for those then you might as well learn
             | whatever's most in-demand and popular, probably Python.
             | There are plenty of companies that are good enough though,
             | for most you won't even need to talk to a recruiter.
        
           | nimmer wrote:
           | > Any good company won't care what programming language you
           | are specifically proficient in
           | 
           | True, but most companies care more about using popular
           | language rather than an innovative one. You might get hired
           | but you won't be using Nim at work.
        
           | icedchai wrote:
           | Given two good candidates, they are going to prefer
           | candidates who are already proficient in their tech stack. It
           | saves time.
        
         | bigyikes wrote:
         | Yes. Lately I've found this to be true at my job, with the
         | whole frontend/backend distinction.
         | 
         | Job specialization is good. I mostly write TypeScript, and I
         | can usually contribute the most value to the company by writing
         | TypeScript and sticking to frontend things. Sometimes though,
         | the fastest way to solve a problem is for me to dive into the
         | backend, and I have no qualms with doing so.
         | 
         | Some people on my team treat the "other side" as totally
         | foreign, however. This leads to willful ignorance and glaring
         | inefficiencies. For example, someone asked my senior frontend
         | teammate a question, and the answer could be found trivially by
         | someone with an inkling of backend knowledge. Yet, this person
         | threw up their hands and dragged a backender into the
         | conversation because they couldn't be bothered to learn a
         | single thing about the backend in the 5 years they've been with
         | the company.
         | 
         | Please just be a problem solver. Don't be just a "backender",
         | and _definitely_ don't be just a "Nim developer".
        
         | [deleted]
        
         | skeeter2020 wrote:
         | This feels good intuitively but is not born out by my
         | experiences and observations. The notion that "high paying/good
         | software engineer" are two aspects of the same outcome is
         | wrong. To the OP, the answer is "pays beter with less demand
         | and more risk". Example: we're struggling to find Elixir
         | developers and thus paying a premium for good (not great)
         | talent; we're also looking to switch to Node which will reduce
         | our demand for Elixir devs.
        
           | throwawaymaths wrote:
           | Seriously, pay the premium. You'll waste the delta endlessly
           | searching through the chaff of node developers, and then pay
           | another cost when your node architecture needs to be de-
           | spaghettified or your node developer decides to create
           | another layer of tech debt by switch to using next.js from
           | redux, or starting to use aws lambdas, etc. Etc etc.
        
           | 71a54xd wrote:
           | I'm currently looking for an elixir contract gig! Feel free
           | to email at hydratedchia@gmail.com :)
        
         | SeriousM wrote:
         | That's a horrible advice.
         | 
         | Knowing a language is helping you read/write the code in a good
         | quality. Knowing the ecosystem and solutions in this language
         | is your sellingpoint. Take any language and tell me one can be
         | productive in no time without knowing the ecosystem around it.
        
           | Aperocky wrote:
           | This is good advice.
           | 
           | Within our team we use 5 different mainstream languages to
           | accomplish different goals within our system.
           | 
           | We handle a single service, but we manage the full stack
           | using many different languages and frameworks.
           | 
           | We don't have to be expert in the frameworks, we just need to
           | be experts at what we are building. And we learn each
           | framework to the point where we can accomplish that.
           | 
           | The "selling point" that we value is to be able to deliver.
        
         | baby wrote:
         | I have a different approach, I have a blacklist of languages I
         | refuse to work with (for example, Java)
        
         | namelosw wrote:
         | I agree in general, but that might not be the whole truth.
         | Otherwise there wouldn't be such a thing called "Perlis
         | Language"[0].
         | 
         | [0] "A language that doesn't affect the way you think about
         | programming is not worth knowing." -- Alan Perlis
        
         | [deleted]
        
         | mmartinson wrote:
         | > Best strategy for becoming a high paying/good software
         | engineer would be to think of yourselves as problem solver and
         | language as just one of the tool for problem solving.
         | 
         | I'm not sure becoming a high paying/good software engineer are
         | necessarily relevant to the stated goals of the OP's question.
         | There can be inherent reward in working with a set of less
         | popular, well crafted tools. Yes you might grow faster as a
         | professional by working with a group of industry best JS
         | programmers, but working with a small team building in Elixir
         | and moving fast without ever hitting a NaN can be a pretty
         | rewarding experience.
        
         | LAC-Tech wrote:
         | I read this advice so much as a younger programmer, but now I
         | am in a position to say - this doesn't work.
         | 
         | Sure think of yourself as multi-lingual and able to learn
         | anything (which you probably are). But don't market yourself
         | that way, especially if you're a contractor. People want
         | someone who knows their tech stack and they want you to be
         | productive yesterday.
        
         | pharmakom wrote:
         | I think this is true, but writing code in certain languages
         | (e.g. Java 8) drives me a bit crazy. It's like running a race
         | with your arms tied to your sides.
         | 
         | I put certain languages in a general negatives bucket along
         | with noisy offices, stack ranking, heavy process, etc.
        
           | listenallyall wrote:
           | > Java 8 drives me a bit crazy
           | 
           | (whisper voice) _kotlin_
        
             | pharmakom wrote:
             | Kotlin is nicer for sure, but...
             | 
             | 1. Not every shop will let you use it
             | 
             | 2. Kotlin has a bunch of the same limitations.
        
           | 62951413 wrote:
           | The latest LTS version is JDK17 (e.g. records and switch
           | expressions) and has been for long enough to be production
           | ready. I reckon half of the people on this forum didn't even
           | work in software when JDK8 was released.
           | 
           | Yes, Kotlin/Scala would stop driving you crazy. No, I don't
           | see nearly enough Bay Area companies deprecating Java in
           | their favor for new services :( They are probably betting on
           | the next LTS to come soon enough (with pattern matching and
           | hopefully Loom).
        
         | ld_bic wrote:
         | I write COBOL I work 24hrs/week I make $15k/week
         | 
         | I also can't center a div on a web page or do much of anything
         | other then what I do.
         | 
         | Specialization IMO is key to highest job satisfaction and
         | highest salary in this industry
        
           | greatpostman wrote:
           | Interesting, always thought high paying cobol jobs were a
           | myth
        
             | ld_bic wrote:
             | IMO the only way in this industry (without having your own
             | company or something like that) to high-paying gigs is to
             | become more valuable to a company than company is to you.
             | and that you can accomplish only through DEEP
             | specialization
        
               | varjag wrote:
               | The downside to this of course is the breadth of your
               | next job search (should it come to that) suffers.
        
               | ld_bic wrote:
               | This on the surface sounds solid but I persobally think
               | most job searches are narrow unless you are doing "career
               | changing" moves. How many good UI/UX colleagues do you
               | have that are good at anything else? How many compiler
               | developers can center a div on the page? I think this "I
               | know a lot of things" is just something we say - terms
               | like "full stack" developer etc...
               | 
               | I mostly develop on a computer which isn't connected to
               | the internet (so no Google, Stackoverflow etc...) and I
               | often think how miniscule fraction of "full stack"
               | developers could perform even the most menial task in any
               | of these "stacks" they apparently know
        
           | unsupp0rted wrote:
           | Interesting- this is contrary to what many people responded
           | when I AskHN'd recently:
           | 
           | > Ask HN: How do I learn real-world COBOL?
           | https://news.ycombinator.com/item?id=31906829
           | 
           | How does one learn to do what you do (write COBOL in the real
           | world to make a great living)?
        
             | bitwize wrote:
             | Those people wrote that because they're making $15k/week
             | and don't want to tank their market value.
        
         | jollybean wrote:
         | This doesn't answer the question.
         | 
         | More specifically, it's probably not useful advice.
         | 
         | I'm a generalist in a few languages, and I'm painfully aware of
         | my lack of 'depth' of insight into the languages I use when I'm
         | not 'knees deep'.
         | 
         | For some niche languages, you can't just 'read a book' and
         | 'check stack exchange'.
         | 
         | I think we should all be 'multilingual' but it really helps to
         | have depth of expertise.
        
       | GuB-42 wrote:
       | Does language really matter? Any experienced programmers should
       | be able to pick up any language in a matter of days if he knows
       | the underlying concepts. Similarly, the language is not what
       | makes a job interesting.
       | 
       | I mean, what don't you like about JS? Is it the syntax or is it
       | the environment? The code base? The framework? Maybe web dev is
       | not for you? Maybe you are asked to do thing you personally
       | disagree with (ex: ads). Language rarely was the main thing that
       | defined the project, though there are correlations: if you are
       | doing JS, you are probably doing web dev, with a higher chance of
       | front-end work. But chances are that a NodeJS back-end and one
       | written in, say, Elixir, won't feel much different after the
       | honeymoon is passed.
       | 
       | If you want something different to JS, why not try good old C
       | instead of niche languages? It has a significant job market, you
       | will learn about memory management, and get your foot into
       | embedded, high performance, and system programming, far from the
       | world of JS. These skills will translate into the other (niche or
       | not) languages you may use next. Even in high level languages,
       | having an idea of how that works on a lower level is a good
       | thing.
        
         | pyb wrote:
         | Yes, but the problem is non-technical recruiters. They want to
         | be looking for a "Java programmer" or an "Elixir programmer".
         | If you tell them that a good programmer is a good programmer in
         | any language, and that they need to look at what the person has
         | actually achieved, they won't be interested. Keyword-matching
         | on Linkedin is a lot easier.
        
         | mmartinson wrote:
         | > But chances are that a NodeJS back-end and one written in,
         | say, Elixir, won't feel much different after the honeymoon is
         | passed.
         | 
         | This is very, very far from my experience, having worked
         | extensively with both of these particular examples.
         | 
         | At my current job I deep dive into a lot of years old, kinda
         | sketchy Elixir code, and it's almost always less effort to
         | learn/fix something than I've found in other languages,
         | especially other dynamic languages. Except when macros are
         | overused.
        
         | lkschubert8 wrote:
         | I think "any experienced programmers should be able to pick up
         | a language in a few days" is true for a lot of surface level
         | things, but expertise is entirely different. A language isn't
         | just the syntax and runtine, but the idioms, patterns, package
         | ecosystem, and tooling that surround it, which you will likely
         | not learn in a few days.
        
         | jtwebman wrote:
         | Thinking like this is how you get factory objects in JavaScript
         | or Elixir processes as objects. They are very different
         | technologies that need to be written differently at the core.
        
       | auslegung wrote:
       | I've had 4 engineering jobs in 5.5 years. Two have been
       | Elm/Haskell jobs. It took a couple of months of light searching
       | to find my current Elm/Haskell job.
       | 
       | Setup alerts on job sites, join appropriate subreddits, Slack
       | teams, Discord servers, language-specific job sites, etc. You
       | will find a lot more jobs than you might expect.
        
       | 2c2c2c wrote:
       | Elixir is at a different level than the other languages you've
       | listed. I learned and built stuff for fun using Elixir around 6
       | years ago while in college, and dropped it on my resume in the
       | pile of technologies I know around then. In the past 2 years, as
       | my yoe hit 5 years, I now get the hoard of specialized Elixir
       | recruiters who filter by 'elixir' and '5 yoe'. These amount to
       | 75%+ of the people who contact me about jobs.
       | 
       | A lot of startups fully bought into elixir+phoenix over the
       | years. Most of these companies would have probably been better
       | off using node or something, but they do exist.
        
         | yomkippur wrote:
         | Curious what your TC was and # of employees. Were they all
         | startups or were there any established companies hiring
         | Elixir/Phoenix ?
         | 
         | The technology is very interesting but I find that it has the
         | same issues as clojure: limited talent pool, questionable
         | cost/productivity gains.
         | 
         | LiveWire is very interesting but its now emulated to a large
         | degree in other more popular languages enough that I could put
         | off learning Phoenix and opt for a more modular solution with
         | popular languages.
        
           | 2c2c2c wrote:
           | I've never taken any of the offers and have never used Elixir
           | in a professional context. Most of these are small startups
           | and can range from 100-200k + equity, and the only decision
           | behind using elixir was probably the novelty, not beam or the
           | success stories behind discord and whatsapp suggesting its
           | utility for at scale throughput
        
       | sterlind wrote:
       | There's a lot of niche languages for niche specialties. Like
       | Ada/Spark for aviation/defense/safety-critical systems, Coq and
       | Isabelle for formal verification, FORTRAN and Julia for
       | scientific computing, Mathematica for pure/applied math, Prolog
       | for logic programming/planning/expert systems, R for stats,
       | MiniZinc and TLA+ for modeling, Racket for compiler work, etc.
       | 
       | Ideas in these fields come through clearer/more cleanly in these
       | languages. Learning the language is easy, the field is harder,
       | but ideas of the field are reflected in the language.
        
         | EddySchauHai wrote:
         | I'd _love_ to work with Ada some time. The language I find most
         | interesting.
        
       | gorgoiler wrote:
       | If you get a kick out of neat technology then you should be able
       | to build your own _cool stuff_ -- libraries, tools, and the like
       | -- without needing to reach for a particular language.
       | 
       | I work on a large and boring Python codebase and I don't need
       | niche technologies to scratch my CS / hacker itches -- healing
       | technical debt with carefully considered redesigns that delete
       | thousands of lines of code and produce v2 of something with 10x
       | the usefulness is what gets me excited about work.
       | 
       | Do you like cooking, and have you heard of Keith Floyd? He was
       | famous in the 1980s for pioneering the travel cooking TV show,
       | getting out of the studio and cooking on location in borrowed
       | kitchens of French farmers, fisherman's galleys, firesides in the
       | outdoors as well as whichever corner of a professional kitchen he
       | could beg or borrow. He brought French cuisine to life, on screen
       | in situ, by working with what he had available to him and making
       | of it what he could, all with good humour and excellent results.
       | 
       | It's a nice metaphor for producing business results no matter
       | what kind of facilities you have available:
       | 
       | https://m.youtube.com/watch?v=1NzR9vgCIkU
        
       | tikhonj wrote:
       | My experience has been that roles in less popular languages are
       | rare but they also substantially help match up candidates and
       | interesting opportunities. I've been interested in functional
       | programming and Haskell since college and it's specifically
       | helped me get roles I would not have gotten otherwise:
       | 
       | * I got an internship at Jane Street thanks to my Haskell and
       | OCaml experience--I doubt I would have been considered at a
       | similar company like Two Sigma
       | 
       | * I got onto a cool operations research/AI team at Target thanks
       | to my Haskell experience--I wouldn't have considered them and
       | they wouldn't have considered me without it
       | 
       | * at Target, I saw first-hand how using a non-standard language
       | _massively_ helped with recruiting highly skilled engineers
        
       | bdhcuidbebe wrote:
       | There are more jobs in non-niche languages. Have you checked out
       | anything else. C#, Java, Python, PHP, Golang, Typescript are all
       | better than js.
        
         | pharmakom wrote:
         | Better on what dimensions? Quite the sweeping claim. Is C#
         | better than JS for writing a web front end? It's possible but
         | it's hardly better.
        
         | throwaway94439 wrote:
         | Let me demonstrate how subjective this is with my next
         | statement.
         | 
         | They're all bad as none of them have algebraic data types.
        
       | compumike wrote:
       | I'm only guessing, but the best path for Crystal might be to find
       | a Ruby job (which are relatively plentiful!) and, if/when a
       | situation arises where you need an especially high-performance
       | microservice/component, you might be able to suggest bringing in
       | Crystal to the team.
        
       | mongol wrote:
       | I think you have a better chance lobbying for using those at a
       | workplace, than you being hired for those skills explicitly.
        
       | phtrivier wrote:
       | The market is obeying the law of supply and demand. Hardly anyone
       | knows those languages, and there is no big player backing them,
       | so you have to dig inside each community to know which shop is
       | active. For elm, you can try noredink. For f# and closure there
       | are a bunch of Fintech.
       | 
       | For elixir, well, if you're willing to relocate for south west
       | France, DM me ;)
        
         | rrdharan wrote:
         | I often see people saying "DM me" or "PM me" on Hacker News but
         | they have no contact information in their profile and HN
         | doesn't offer a direct messaging feature.
         | 
         | Is this just because people forget which platform they're on?
         | Is it because they don't remember what's in their profile? Or
         | is there some other way to DM people that I don't know about?
        
           | shocks wrote:
           | Litmus test I guess.
           | 
           | Parent is fairly trivial to contact if you can use Google.
        
             | rrdharan wrote:
             | They're quite trivial to identify; they are not "fairly"
             | trivial to contact unless GitHub or Stack Exchange has some
             | DM capability I'm also unaware of.
             | 
             | Poster's Web site has no official contact info. Yes, I'm
             | sure I could keep digging and find a way but I don't
             | consider that "fairly trivial".
        
               | klohto wrote:
               | Well, there is LinkedIn, as well as his company email
               | format. It's really not that hard.
        
           | [deleted]
        
         | greggyb wrote:
         | Funny you mention F# and Clojure, as these were the only
         | contenders for a product I am building with a partner. We went
         | with F# and are quite happy thus far.
        
           | pharmakom wrote:
           | F# has the backing of Microsoft and the big ecosystems of
           | .NET and JS (via Fable). This makes it the best supported
           | niche language and a great pick.
        
           | phtrivier wrote:
           | What's the cross platform / native story for F# (for real) ?
           | Can you build a relatively efficient binary that just runs
           | and does not take an hour to open a gui window ?
        
             | greggyb wrote:
             | Our work is incredibly i/o-bound, so we would probably not
             | see much of a performance difference no matter what
             | language we chose. Additionally, our presentation layer is
             | served directly from an in-memory, columnstore database and
             | is divorced from our back-end by a batch ETL process.
             | 
             | To give a high-level overview of what we are doing, we call
             | a series of APIs which can provide current-state metadata
             | about a SaaS platform. We poll those APIs on a schedule and
             | diff the results over time, providing to our customers a
             | view of this change over time. So our work is to schedule
             | these API calls, wait for the results, persist the results
             | to storage, and then identify the deltas. Once this is
             | done, we load into our presentation layer for customers to
             | interact with.
             | 
             | We run an independent process per customer and use OS
             | permissions to isolate these from one another, and plan to
             | containerize these processes for further isolation.
             | Customers each get a local ZFS dataset and a separate blob
             | storage container. Isolation is a big deal for us, as the
             | permissions we require to call these APIs for our customers
             | end up being a de-facto global admin (this is a limitation
             | of the SaaS vendor, not us). The dataset-per-customer model
             | allows us to lose a single (and backed up, so not really
             | _single_ ) encryption keyfile to forget everything
             | sensitive from that customer.
             | 
             | This last paragraph only emphasizes that the language is
             | not the most significant consideration for our work. We
             | could probably orchestrate the API calls as effectively in
             | shell pipelines. The diffing process is a bit hairier, and
             | my current focus.
        
             | banashark wrote:
             | I've been developing F# things on linux for close to a
             | decade now (though my last official position doing so was
             | ~7 years ago, it's just my default hobby language that I
             | know best).
             | 
             | I have zero trouble developing on linux.
             | 
             | Building GUI or non-GUI software works fine. I use Rider
             | and work on web systems, a handful of scrapers that feed
             | some data I collect, as well as various small GUI systems.
             | 
             | I think F# might have _the highest number of viable ways_
             | to build a GUI application if that's what you're looking
             | for.
             | 
             | You can go the fable (F# -> JS transpiler) route and use
             | any of the js tools (electron, nodegui, etc). The popular
             | one's (react, preact, svelte, etc) have type definitions
             | that folks have already written.
             | 
             | F# works with most of the dotnet gui libraries just fine,
             | though I don't know for sure the story about winui, but
             | from people I know working on production systems using it,
             | they recommend to avoid it. So you've still got WPF, etc.
             | 
             | For the newer cross-plat stuff, there is Avalonia, Uno
             | Platform, Xamarin (with the natives) or the newer version
             | MAUI.
             | 
             | ---
             | 
             | The thing here is that there aren't really limitations to
             | almost all of the things I've listed above. Transpilation
             | targets work fine, as do the dotnet targets. Almost every
             | one of these also has "Elmish" frameworks (Functional
             | Reactive Programming state management) suited for the
             | purpose:
             | 
             | * React -> Elmish + Feliz * Avalonia -> Avalonia.FuncUI *
             | MAUI -> Fabulous etc
             | 
             | ---
             | 
             | I've never felt constrained building GUIs in F#, other than
             | some of the dumpster fire that was Xamarin.Forms and the
             | Xamarin build tools (native targets never gave me any
             | problems that I can remember).
             | 
             | I took a partial Fabulous 1.0 (Xamarin Forms) application
             | that I had only worked a couple days on, and out of anger
             | with Xamarin build tools lifted and shifted to a react-
             | native application. Almost my entire elmish (view-logic
             | layer) was preserved, and I just had to change the view
             | elements out from Xamarin.Forms elements to React Native
             | elements.
             | 
             | ---
             | 
             | I don't work with F# too much in an official capacity these
             | days, but it's a decent tool to have as a default.
        
             | throwaway94439 wrote:
             | I had severe performance problems with F# async, but this
             | may be fixed in F# 6.0
        
               | greggyb wrote:
               | I would be curious to hear more about this. My response
               | to a sibling explains how we do not have huge performance
               | considerations right now (and our i/o-bound nature). Due
               | to the primary work of our product, we are utilizing
               | async workflows extensively. We are on 6.0, and
               | evaluating if we want to chase the 7 series release or
               | just hop to the next LTS.
        
               | mdm12 wrote:
               | F# 6.0 added the 'task' computation expression, which is
               | much more performant than the F# 'async' methods. It also
               | makes interop with C# projects and libraries simpler, as
               | is uses the same mechanism that C#'s async/await does. I
               | have used it in production workflows without major
               | performance issues FWIW.
        
         | yomkippur wrote:
         | > relocate for south west France
         | 
         | that itself is a huge turn off for many developers who don't
         | speak French. You will face discrimination even if you speak
         | fairly fluent level. Not to mention the insane income/corporate
         | tax brackets.
         | 
         | Unless you operate directly with the French market, there is
         | little to not reason to move there to do a startup or start a
         | career there.
         | 
         | Many young French citizens have left it and they are not coming
         | back. Brain drain is very real there.
        
       | hestefisk wrote:
       | I can tell you the next big thing is Perl ... that's where the
       | money is...
        
       | eschneider wrote:
       | There are definitely positions out there, but they're not always
       | obvious. I picked up an new embedded/backend job at the beginning
       | of the year and they mentioned "Oh, we're doing a lot of new
       | development in Elixir, you cool with that?" towards the end of
       | the interviewing process. Wasn't ever in the job description
       | before I was hired... And yes, most of the new development has
       | been in Elixir, when it makes sense. :)
        
       | nhgiang wrote:
       | There is a significant Erlang/Elixir job market in Europe and UK.
        
         | japhib wrote:
         | The Elixir job market is getting better in the US as well. I'm
         | currently employed at a company that uses Eixir exclusively for
         | backend, and we've got 100+ engineers. I've had multiple
         | recruiters from other Elixir-using companies reach out to me on
         | LinkedIn as well.
        
         | yrgulation wrote:
         | No, there is not. Multiple sites report < 10 jobs in the uk for
         | any of the two, while c#, java, node, python are in the
         | thousands each.
        
           | japhib wrote:
           | <10 jobs is still significant.
        
             | icedchai wrote:
             | How's that? 10 jobs is basically a rounding error for any
             | other category. There are orders of magnitude more Java
             | jobs.
        
               | japhib wrote:
               | But there are jobs, and people work in them. I, for
               | instance, use Elixir in my day job, and so do 100+ other
               | engineers at my company alone. I've also been approached
               | by recruiters on LinkedIn for other Elixir jobs. So yes,
               | there is a significant amount of jobs in Elixir
        
       | jstx1 wrote:
       | Non-existent to a close approximation (maybe more Elixir stuff
       | out there than the others you listed but still very rare). Learn
       | those languages if you're interested and curious but if the goal
       | is to get a job with a new to you language, stay as far away as
       | possible from them. Not only are there very few jobs but also the
       | niche languages will distract you from learning stuff that's in
       | demand.
        
         | bees_buzz wrote:
         | If you go looking for elixir stuff it's there, and it seems
         | like its usage in industry is expanding at a steady pace. IMO
         | this is because it's a reasonably approachable language
         | designed to solve a common difficult problem (high concurrency,
         | fault tolerance at scale)
        
           | lord-squirrel wrote:
           | +1, elixir is being used in a lot of cool places and only
           | growing. For example at discord, their chat infrastructure is
           | built with elixir. https://elixir-
           | lang.org/blog/2020/10/08/real-time-communicat...
        
         | AlchemistCamp wrote:
         | It really amazes me how often I see this fallacy.
         | 
         | The total amount of supply doesn't matter much. What matters
         | (both for the employer and the job-seeker) is the ratio of
         | supply to demand.
         | 
         | E.g., let's say JavaScript has the most demand of any language
         | and there are 2 zillion job openings. This sounds great for job
         | seekers initially, but what if there are 5 zillion JS devs
         | seeking jobs? In that case job hunting might be very difficult.
         | Similarly if there are 100 remote positions open in Pony, but
         | only 10 Pony devs available to fill them, job hunting might not
         | be so difficult.
         | 
         | There are some liquidity advantages in absolute scale, but for
         | the most part it's the ratio of supply to demand that matters
         | and not the raw numbers.
        
           | jstx1 wrote:
           | Niche language means fewer companies to pick from. If I don't
           | like any of them, what do I care how desperate they are?
        
             | goodpoint wrote:
             | Explained twice and yet still missing the point.
        
               | [deleted]
        
           | girishso wrote:
           | This. This is how I choose my tech stack these days.
        
           | Kwpolska wrote:
           | What if I don't want to work remotely? What if I'm not in the
           | US, or what if I'm in Colorado? What if all the jobs are in
           | an industry I would prefer not to work in or am morally
           | opposed to? If there are 2 zillion positions available,
           | there's a much larger chance to find something in my area and
           | meeting all my requirements/wishes. But if there are just 100
           | jobs, I might end up without a job, or with a job I'm not
           | very happy about.
        
             | AlchemistCamp wrote:
             | Again, this is missing the importance of the ratio of
             | supply to demand.
             | 
             | > If there are 2 zillion positions available, there's a
             | much larger chance to find something in my area and meeting
             | all my requirements/wishes. But if there are just 100 jobs,
             | I might end up without a job, or with a job I'm not very
             | happy about.
             | 
             | If there are 5 zillion candidates seeking those 2 zillion
             | positions, it's a much smaller chance you'll get one you
             | want. You might end up without a job, or with a job you're
             | not very happy about.
             | 
             | BTW, If you're in Colorado, go to Elixir Conf in a month!
             | https://2022.elixirconf.com/registration
        
       | AnthonBerg wrote:
       | For what it's worth, I had a job writing ReasonML / ReScript. It
       | was a good job!
        
       | ptttr wrote:
       | I do definitely recommend Clojure - I've switched to it in 2019
       | coming from Rails and JS and never looked back.
       | 
       | Clojure's job market is great, there's no shortage of offers,
       | even for newcomers and it has been the top paying lang in
       | stackoverflow surveys for years
       | https://survey.stackoverflow.co/2022/#section-salary-salary-...
       | 
       | However, the most important part is that Clojure is a very
       | powerful piece of technology that made me reevaluate what
       | software engineering really is. You can efficiently use Clojure
       | for both backend and frontend with easy access to libraries from
       | JVM and npm so you will never run into the problem, common in
       | other niche langs, of too few libraries. Nevertheless, Clojure's
       | own ecosystem is filled with many great, cutting-edge ideas that
       | you wouldn't find working so well elsewhere. The community is
       | very welcoming, growing and diverse with people coming from all
       | different programming backgrounds - all sharing the
       | disillusionment with other programming languages and
       | determination to find and build a better way.
       | 
       | https://jobs-blog.braveclojure.com/2022/03/24/long-term-cloj...
        
         | patrickthebold wrote:
         | I love clojure, and would love a clojure job, BUT my hesitation
         | comes from the companies choosing clojure or any niche
         | language. Choosing a niche language seems like a very risky
         | move, to me. My fear is that that its a small company and
         | someone senior and technical (CTO?) just wants to have fun in a
         | new cool language because they are bored.
         | 
         | Don't get me wrong, I _also_ want to have fun in a new cool
         | language because I 'm bored, but that's not a good decision for
         | a company to pick that as a tool.
         | 
         | Anyway, I'm worried that the culture is not entirely practical
         | in their technical decisions, and that's my hesitation.
        
           | shocks wrote:
           | Ask them during the interview stage.
           | 
           | Sometimes a strange/obscure language is the correct choice
           | for a very good (and fun/interesting!) reason.
        
           | ptttr wrote:
           | I understand your worry, but I've had a quite opposite take
           | on this.
           | 
           | I think we can agree that it's not that hard to find ANY job
           | as an experienced developer. However it's much more difficult
           | to find a great, satisfying job. For that you need to
           | navigate around a lot of corpo-bullshit type of projects, and
           | Clojure has served me well as a useful filter in doing that.
           | My reasoning is that Clojure is niche enough that when
           | company is using it, you can assume that it's due to a
           | deliberate technical choice, and not just because of its
           | popularity. That tells me two things that are symptomatic, in
           | my opinion, of a healthy tech company culture: - tech
           | decisions are made by engineers, not by top-level executives,
           | - their conclusions and bets align with mine because we all
           | see and agree on Clojure's edge over more popular solutions.
           | 
           | Admittedly, there's always a risk that someone just followed
           | the hype and got out of their depth but I think this risk is
           | relatively small, because Clojure's no longer a new kid on a
           | block and choosing a tech stack is a major decision and
           | usually done by senior tech leadership, hopefully less hype
           | driven.
           | 
           | Of course, Clojure is no silver bullet and it's just a tool
           | that gives you enough rope to hang yourself. Messy codebases
           | are just as possible as in other languages, especially when
           | the team is new to lisps that are very different from
           | mainstream languages, but that's a nature of software
           | development - you learn with the experience. I do cringe when
           | I look at the Clojure code I wrote when I was just starting
           | and wasn't fully grasping Clojure's way of thinking, but the
           | more I use it, the more I come to appreciate how powerful it
           | is.
           | 
           | Great intro that made it click for me:
           | https://www.youtube.com/watch?v=vK1DazRK_a0 (Solving Problems
           | the Clojure Way - Rafal Dittwald, 2019)
           | 
           | Having said that, no software project is ever complete and so
           | isn't Clojure as an ecosystem. The tooling is constantly
           | evolving and new patterns are emerging. What's great about
           | Clojure open-source community is that everyone seems to share
           | the desire to harness complexity and Rich Hickey has
           | convinced each one of us at some point that the way to do it
           | is through simplicity
           | https://www.infoq.com/presentations/Simple-Made-Easy/
           | 
           | Even within Clojure's community there's a diversity of
           | approaches, and I think it's necessary to improve and evolve.
           | The more recent trend, I've noticed is that the community is
           | converging at Data Oriented Programming that's applicable in
           | other languages as well, but has always been at the core of
           | Clojure's mindset that is especially well suited for it.
           | 
           | Dropping some links relevant about DOP:
           | https://youtu.be/8Kc55qOgGps?t=4175 (Rafal Dittwald, "Data
           | Oriented Programming" 2022) - whole talk is valuable, but
           | long so I'm linking to the most juicy snippets)
           | https://blog.klipse.tech/dop/2022/06/22/principles-of-
           | dop.ht...
           | 
           | Moreover, Clojure has already grown past the threshold of
           | being just a niche toy and has sufficiently big market that
           | it won't die off anytime soon. When you study history of
           | programming languages, you'll notice that it's enormously
           | difficult thing to do for an emerging player, especially
           | without big corporate backing. And Clojure is as grassroot as
           | it gets: https://clojure.org/about/history
        
           | wtetzner wrote:
           | You may be right about many companies' decisions, but I will
           | say that Clojure is a very practical language. I think you'd
           | just need to ask them why they chose it, and decide for
           | yourself if you think it was a wise decision.
        
         | throwaway1777 wrote:
         | These salary numbers in the survey are so low it seems like a
         | joke.
        
           | mattyb678 wrote:
           | My guess is that the salaries of developers outside of the
           | US, and western countries, pull down the averages
        
             | bowsamic wrote:
             | Almost any other western country other than the US and
             | Switzerland will massively pull down the average.
             | Especially in the US salaries are extremely inflated. I
             | know academics in physics who are effectively chained to
             | the US because they are so used to the huge amount of
             | money. In Germany for example you cannot expect to make
             | more than 70k euro max, probably more like 50-55k euro a
             | year even as a senior software engineer. I don't think a
             | lot of americans appreciate how vastly inflated american
             | wages are
        
               | wiseowise wrote:
               | > Especially in the US salaries are extremely inflated.
               | 
               | Funny way to spell "fairly compensated".
        
               | bowsamic wrote:
               | I didn't spell it wrong, you are suggesting a different
               | idea. Own up to it rather than using a lame linguistic
               | deflection tactic.
               | 
               | It is beyond fair compensation, because the standard of
               | living is fine in Europe, even though I know a lot of
               | americans think we live in squalor. The pay in the US is
               | beyond what can possibly be expected in other developed
               | countries.
        
               | throwaway675309 wrote:
               | You'd be singing a different tune if you were a US
               | citizen with our complete lack of socialized safety net,
               | inadequate health care system, etc etc.
               | 
               | I'm sorry as a non-US citizen that you're so poorly
               | compensated, but clearly the market and corporations
               | _can_ afford to pay much better than they do in Europe.
        
               | housingisaright wrote:
               | Salaries in the eu is most def. Lower than us, but
               | earning 100k with a couple years experience is pretty
               | common in London/Berlin/Scandinavia etc.
               | 
               | Biggest difference is that not a lot of people are
               | earning 200k+ salaries in eu.
        
               | bowsamic wrote:
               | 100k in Berlin is pretty extreme, Scandinavia and London
               | I can see it more. I live in Hamburg and 100k is
               | basically unheard of.
        
               | badpun wrote:
               | In Europe, good money is in contracting. For senior devs,
               | salaried jobs are for people who for some reason won't
               | switch to contracts (e.g. they're immigrants and need a
               | full time job for visa purposes)
        
           | eulers_secret wrote:
           | As the other poster said, it's due to other countries
           | confounding the data. Check this for example:
           | https://survey.stackoverflow.co/2022/#section-salary-
           | salary-...
           | 
           | You can specify the location - the salaries are more inline
           | with what you'd expect if you select the USA. Also note that
           | 8,540 of 37,546 respondents are from the US - so MOST of this
           | data is not relevant to the USA.
        
         | casion wrote:
         | I can second this. I've worked in the industry in academia,
         | enterprise and industrial. Switching to Clojure not only has me
         | at my highest salary ever, but I'm consistently working with
         | some of the best people I've met in my entire career. The
         | community is incredible, the job market is open and the people
         | who seem to be attracted to the ecosystem are fantastic
         | engineers and generally great people.
         | 
         | 30 years as a professional dev, and I've never been happier.
        
         | thebigspacefuck wrote:
         | The SO chart shows Erlang is actually highest at $120K salary.
         | Also note the median years of experience is 13. Making $110K
         | after 13 years is not all that great. The chart would be more
         | useful if it showed a trajectory over time for each language.
         | Overall I don't think this chart should influence anyone's
         | decision to pick a programming language.
         | 
         | I worked with a few teams using Clojure and there was nothing
         | magical about it. One of the Clojure teams' API was very
         | thoughtfully done and reliable. Another Clojure team s' API was
         | a mess and caused loads of issues. I suspect the first team
         | chose Clojure organically and the second team picked it due the
         | SO salary.
        
           | yomkippur wrote:
           | The problem is that learning a niche language like Clojure
           | _should_ demand a higher salary but it doesn 't. Companies
           | realize they can get an existing experienced developer to
           | learn it. It's also not wise to jump ship to a niche language
           | like this unless you really have the funding for it and even
           | then, the talent pool is much smaller and you find yourself
           | its not an employers market in that niche.
           | 
           | So as a business owner by choosing clojure:
           | 
           | - I can't afford to lose experienced clojure devs but my
           | budget is fixed
           | 
           | - I am going to be constantly requiring onboarding, training
           | existing non-clojure devs
           | 
           | - I simply cannot reverse this decision.
           | 
           | To me the third point is the biggest risk but back to your
           | point, it can become unmanageable unless you have the best
           | and the brightest.
           | 
           | In any other language, you could still operate the business
           | with middle of the pack but with these niche languages the
           | risks are just much higher. It would require a Product
           | Manager or even a CTO with extensive clojure background and
           | those would be even harder to find _and keep_.
           | 
           | Like the SO survey shows, not everybody is willing to pay top
           | dollars for a clojure dev and this should make anyone pause
           | before jumping into it.
           | 
           | I personally liked clojure but the tooling was still painful
           | like working with Java. Readability wise its a nightmare and
           | if your entire team quits, there is a very good chance your
           | business will fail, as it is that much harder to scale up
           | your team or find experienced talent who now feel they are
           | owed a much higher wages (which they should).
           | 
           | Nim on the other hand is more promising. It doesn't have any
           | radical shifts, it still reads like Python and its very fast.
           | But it doesn't even show up in the SO survey which makes me
           | think its far too early.
        
             | diordiderot wrote:
             | I've heard the argument that using niche tech is a good way
             | to retain good engineers who you'd pay a lot anyways
        
       | Areading314 wrote:
       | poor
        
       | enraged_camel wrote:
       | We write Elixir at my current job.
        
         | akudha wrote:
         | Could you share some more details? What kind of project is it?
         | Did/do you hire your team who already knew Elixir, or did they
         | learn on the job?
        
           | japhib wrote:
           | At my current company we've got 100+ engineers writing
           | Elixir. Fintech in the US. Almost none of them know Elixir
           | when hired.
        
             | Shorel wrote:
             | This is the right approach.
        
       | emerongi wrote:
       | I was looking for Elixir jobs a few months ago. For me the number
       | of opportunities was good enough, since the nature of the jobs
       | was also more unique and interesting to me. Obviously nowhere
       | near what you see with Java/JS/etc, but with those you also have
       | to do a lot of work to figure out if the job would even be
       | interesting to you, making the job search more stressful.
       | 
       | I didn't need to do hundreds of interviews (like I've seen others
       | do) and instead just picked between a few cool companies. It was
       | quick and easy and I found a place that I so far love.
        
       | oneplane wrote:
       | In my experience the job market just revolves around business
       | needs combined with transferrable skills for an affordable price.
       | 
       | Most business needs are a cheap version of CRUD+Business Rules.
       | 
       | As a result, the biggest languages (keep in mind that most
       | businesses have large amounts of existing code) are also
       | relatively old (except Go, C# and Swift which are relatively
       | young).
       | 
       | Languages I see with my current clients and have seen with former
       | clients and employers (medium to large organisations):
       | - Java (Including Scala, Kotlin and Groovy)       - C and C++
       | (usually both are found at the same company)       - Python
       | - JavaScript (including TypeScript)       - Web stuff like HTML
       | and CSS (but that's mostly generated now)       - Go       -
       | Swift (and Objective-C, mostly iOS development, some tvOS and
       | macOS)       - C# be it modern or some classic ASP.NET       - A
       | bunch of application-specific languages, Apex/PL-SQL/TSQL/X++
       | 
       | Besides "we already have it" there is the hiring pool problem. If
       | you need to find someone for one of the above languages, the
       | pools are generally big and available enough to find a suitable
       | candidate in a month or two. And as such, if someone leaves you
       | know you'll be able to replace hem.
       | 
       | If a platform or application demands a specific language, that's
       | used, but otherwise it's all just availability of people and
       | institutional knowledge.
       | 
       | For your specific languages you might be able to find work at
       | niche sectors like telecom appliance manufacturers, defense or
       | academic institutions.
       | 
       | Edit: and Rust, which like Go, is young (but even younger) yet
       | gaining quite some traction. Also forgot Python for a second
       | there.
        
         | CoastalCoder wrote:
         | I agree with your overall point.
         | 
         | I think the outlier might be Rust. Somehow it's managing to
         | gain traction despite the headwinds you mention.
        
           | frogulis wrote:
           | I guess it fills a niche that companies really need filled
        
             | ghaff wrote:
             | A lot of it's legacy but there's a _lot_ of C /C++ out
             | there. So something that can be used as a system-level
             | language and that also (for the most part) has memory
             | safety is going to be of interest to quite a few people
             | even if they have to learn a new language.
        
           | oneplane wrote:
           | Oh, that's right, I knew I forgot one! It's even gaining
           | traction in ML for some reason, we've been using it in an
           | image processing pipeline because performance and safety-wise
           | it simply had the best results.
           | 
           | Edit: I even forgot to list Python. Maybe I should just look
           | up some language popularity list and use that instead.
        
             | ghaff wrote:
             | This is a pretty widely-quoted list.
             | https://redmonk.com/sogrady/2022/03/28/language-
             | rankings-1-2...
        
             | czbond wrote:
             | For Rust and ML, are the tooling libraries available to any
             | quantity in Rust that are present in Python? I was under
             | the impression Python has such an advance runaway any other
             | languages will be hard to catchup (eg: Go has been trying,
             | R <ugh>, etc)
        
               | danieldk wrote:
               | There are obviously fewer ML libraries than for Python
               | (sometimes worse quality, sometimes better), but if you
               | are willing to invest time, it's definitely doable. E.g.
               | I made a multi-task transformer-based syntax annotator in
               | Rust using the _tch_ Torch binding:
               | 
               | https://github.com/tensordot/syntaxdot
               | 
               | In my current job I do NLP with Python, Cython, and some
               | C++. I don't think implementing ML stuff in Rust was much
               | more work. Once you are beyond the stage of implementing
               | a small research project or toy model, most systems are
               | going to contain a lot of custom, specialized code. You
               | will have to do that work in any language.
        
         | jtwebman wrote:
         | I wouldn't call C# a young language anymore.
        
           | oaiey wrote:
           | Yes. But the inhouse pile is very location specific (C# is
           | not popular in every country and every business)
        
         | ravenstine wrote:
         | > Web stuff like HTML and CSS (but that's mostly generated now)
         | 
         | Explain? I've yet to work somewhere that just generates HTML
         | and CSS. Is it really becoming common to spit those things out
         | from something like Figma?
        
           | oneplane wrote:
           | Generated as in, templated once and then just spit out via
           | classic MVC and beyond (like API on the server, JS on the
           | client which uses some MVVM construction for component
           | rendering).
        
             | ravenstine wrote:
             | Oh! I'm not sure why I thought you might have been implying
             | something else.
        
       | blablabla123 wrote:
       | The jobs where niche language are used (not necessarily
       | exclusively) seem to me more interesting but might bring other
       | downsides like very small teams. Also if you used such languages
       | previously, chances are the next place you start turns out to
       | also use a niche language somewhere or be open to it. The most
       | uncommon tech is usually not even listed in the job ad and will
       | only be seen a few months into the job...
        
         | egberts1 wrote:
         | Ive found that Nim has an interesting way of doing string
         | handling, as if it is some kind of Polish notational aspect.
         | 
         | Take part of a CSV parser, for example:                   if @[
         | ',' ].split(my_string)
        
           | Tiberium wrote:
           | I think you just found someone's bad code, because first of
           | all, an efficient CSV parser would not use `split` with `if`
           | because then the program will have to split the whole string
           | and store all split'd string in a sequence temporarily, but
           | second of all, Nim has method call syntax (so-called UFCS in
           | some other languages) - https://nim-
           | lang.org/docs/manual.html#procedures-method-call..., so the
           | code you wrote can just be                 if
           | my_string.split(@[','])
           | 
           | or even (because we only split by 1 char, we don't need a
           | sequence):                 if my_string.split(',')
           | 
           | That said, you didn't paste the whole string of code as this
           | expression is non-sensical - Nim doesn't have the same
           | "truthiness" as Python, so if you wanted to check if there's
           | at least two strings as a result of a split, you'd write it
           | as                 if my_string.split(',').len > 1:         #
           | do stuff
        
       | pselbert wrote:
       | There are ample Elixir jobs out there, and lots of companies
       | hiring.
       | 
       | For a quick check of relative popularity, open the past couple
       | monthly "Who's Hiring" here and search for "Elixir." The
       | community is thriving and growing.
        
       | BaculumMeumEst wrote:
       | the fact that you used the word "niche" suggests that you're
       | already know the answer to your question
        
       | 999900000999 wrote:
       | I'll echo much of what others have said, once you become a decent
       | software engineer, the language shouldn't be a deal-breaker.
       | Deal-breaker
       | 
       | It does make onboarding much easier though, for example, if I
       | join a shop that uses NodeJS I'm not going to have to ask for
       | help getting set up. If I join a C++ shop...
        
       | kshahkshah wrote:
       | No one seems to have mentioned this at the top level...
       | TypeScript can make a large JavaScript codebase a lot more
       | manageable and fun in my opinion.
       | 
       | I second Clojure if you're specifically looking for niche.
       | 
       | If you goal though is to be highly employable I'd suggest Python
        
       | joe8756438 wrote:
       | What is it about js you dont like? is it really about the
       | language?
       | 
       | a lot of the complaints i hear about js have more to do with "the
       | community", "the team", "the application".
       | 
       | here's the thing: there is _so much_ built in js. i think theres
       | a better chance you find what you want in a mainstream language
       | (js or otherwise), but you first have to identify what your
       | values are.
        
         | egberts1 wrote:
         | The biggest detractor of JavaScript isn't so much about its
         | language's:
         | 
         | - lack of strong typing (unlike Ada),
         | 
         | - lack of a standard framework (VueJS, NodeJS, Angular, React,
         | Ember, Mithril, Aurelia, Backbone, Polymer)
         | 
         | - lack of consistent control of packaging (embedded or
         | HTTP[S]),
         | 
         | - lack of consistent naming convention (wild west of competing
         | function names, unlike libc library to name one language),
         | 
         | - lack of unit testing (JS? nah),
         | 
         | - lack of correctness for thread procedure theorem (unlike Nim,
         | Ada),
         | 
         | - lack of memory access security (unlike Rust),
         | 
         | - lack of JMP/goto at lower intermediate representation (LIR)
         | level (unlike many programming languages) thus making direct
         | LLVM more difficult and the least portable.
         | 
         | - lack of robust error handling (unlike many)
         | 
         | JavaScript is a runaway language with not much forethoughts
         | being put into server-side security that continues to must have
         | 
         | - a wider access to local filesystems,
         | 
         | - a large, shareable memory block capability set that allows
         | for JIT switching between executable and writing, heap-spraying
         | for kernel addresses, SPECTRE-like capabilitiies (that will
         | continue to be fileless malwares' favorite haunting ground for
         | decades to come).
         | 
         | JS did however introduce a "stack-less" just-in-time compiler
         | that is small enough to get embedded into so many things (my
         | pet peeve is JS of LG smart-TV that is still borked to this
         | day) that no one single anti-virus company can ever hope to
         | cover all those bases.
         | 
         | But it's common, and wide-spread, thus got its adoption rate
         | going for it (much like BASIC variants did during multiple
         | decades) but it sure ain't going to be healthy.
         | 
         | Of course, just flapping off my mouth here toward the incoming
         | tsunami of flotsam against my hardcore cybersecurity values.
        
           | fendy3002 wrote:
           | I don't get most of your complains related with embedded
           | capability or security as you've said. I'm not undermining
           | the importance of security, but javascript is not the good
           | language to use when you have good security in mind / to be
           | embedded. It's like using PHP for machine learning. Sure it
           | can works but you'll find that the language is bad (or at
           | least is not the best if compared to some language) at it.
           | 
           | Certainly the vast adaptation of it is an issue (like
           | electron), but it's more on the companies side than the
           | language itself. Hopefully there will be other javascript or
           | typescript engine that's more suitable for backend /
           | embedded.
        
           | icedchai wrote:
           | JavaScript was originally intended for form validation and
           | preloading images. Everything else was an accident.
        
         | FractalHQ wrote:
         | I loathe JavaScript but I adore Typescript. Anyone unhappy with
         | JS (or anyone writing JS period) should stop and adopt TS.
        
       ___________________________________________________________________
       (page generated 2022-07-23 23:01 UTC)