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?
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...
30 years as a professional dev, and I've never been happier.
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.
Sometimes a strange/obscure language is the correct choice for a very good (and fun/interesting!) reason.
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
Biggest difference is that not a lot of people are earning 200k+ salaries in eu.
Funny way to spell "fairly compensated".
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.
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.
The US spends a larger share of its GDP on its social safety net than Canada does.
What you're confused about is the difference between what a nation spends and what it gets for that spending. The US doesn't lack a social safety net, it has exceptionally incompetent government systems at the state and federal level while simultaneously spending a very large sum on its mediocre social safety net. US Government systems spend like European welfare states and the US doesn't get the same results from that spending.
If the poorest 1/4 of the population being covered by wildly expensive (for the taxpayer), free healthcare isn't part of a social safety net, then what qualifies exactly?
EBT (free food for the poor, aka food stamps) and Housing First are two other prominent social safety net programs. The US spends an enormous amount of money on EBT ($111b just at the federal level for 2021). The US housing first program was so successful it brought the US homelessness rate down to approximately where France and Canada are at.
Social Security and Medicare are social safety net programs, and the two largest by cost in world history. Neither program pays for itself properly, it's subsidized by taxpayers (and more so by the day).
The US also spends a lot on its military, which is part of the social safety net. Europe ignored military for other expenses and is now paying heavily for it.
That being said, the US does not make good use of its resources. But it's a much harder problem that you'd expect.
2. Social safety net isn’t required for a tech worker who makes such huge amounts, and their cost of living is not greater enough to make up the difference
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.
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.
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.
You can't get paid the big bucks if you get forced out of a job for poor performance, and in this economy, expect that to be a real risk.
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++
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.
I think the outlier might be Rust. Somehow it's managing to gain traction despite the headwinds you mention.
Edit: I even forgot to list Python. Maybe I should just look up some language popularity list and use that instead.
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.
Rust has a weird mix at the moment, and not one that's likely to significantly change within the next 12 months, at least. Certain tools are genuinely best-in-class, especially around simple operations on insane amounts of data. Rust kills it in that space due to its native speed and focus on concurrency.
There's also growing projects like Linfa [1]. that while not at the level of scikit-learn, have significantly increased their coverage on common data science/classical ML problems in the past couple years, along with improved tooling. The space does have a few pure-Rust projects coming down the pipeline around autodifferentiation, GPU compute, etc. that are likely to yield some really valuable results in deep learning, but that aren't quite available and will take some time to pick up some traction even once they're released. At the same time, areas like data visualization are unlikely to reach parity with something like matplotlib/pyplot in the near future.
Python is the de-facto standard, and will be for some time, but Rust's ability to build accessible high-level APIs on top of performant, language-native libraries is attracting some attention and I wouldn't be surprised to start seeing ingress in the certain areas over the next few years, where instead of the Python/C++ combination, it's just Rust all the way down.
You may not like R (and I do totally understand that), but it's probably ahead of Python in specialised statistical (i.e. non unstructured ML) tools and packages.
Python is definitely better if you want to interact with a GPU and/or do "modern ML" (i.e. neural nets).
I guess it's what you learn first that shapes your mind the most.
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?
Maybe take “REST” requests for reads or POST instead of dropping on another queue/topic.
Legacy code is C/C++ and PL/SQL. Java since 1.6 or so. JS/TypeScript now for frontends.
And a ton of RPC being called a REST API.
Python is exploding for all the ML/analytics being introduced. But that’s really it’s own thing. Doesn’t read like Python in any other domain. Just a wrapper around math libraries.
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/
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.
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:
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.
> 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
Restaurant A has 10 seats and 5 customers who just bought a meal and want to dine there.
Restaurant B has 20 seats and 50 customers who just bought a meal and want to dine there.
Which will be easier for you to get a seat in? The answer is Restaurant A, even though it has a smaller supply of seats. This is because supply and demand both matter!
Yup, there's a better chance that ten of those 2 zillion positions will be in Colorado. But there's also an equal chance that 25 of those 5 zillion other candidates will.
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.
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
• 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
For elixir, well, if you're willing to relocate for south west France, DM me ;)
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.
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.
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?
Parent is fairly trivial to contact if you can use Google.
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”.
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.
Are you speaking from personal experience? Just curious because I am aware of this reputation but haven’t experienced it directly myself.
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.
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.
If you're looking for a web framework with an ORM for Nim, check out Nexus: https://github.com/jfilby/nexus
But that is predicated on you finding a job first!
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.
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.
- 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.
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.
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.
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
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.
As an Elixir dev, I will add that it being a niche language is also beneficial from a cultural standpoint. I want to work at a place where devs are encouraged to tinker and explore cutting-edge technologies. Not to mention a generally more forward-thinking culture, at least on the dev side.
“Established” technologies like Java make me think traditional, top-down, “butts-in-seats” kinds of companies. Of course, this can’t be generalized, but I think there is at least some correlation. Besides, using enterprise Java is, at least for me, soul-crushing in and of itself.
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.
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.
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.
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.
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 :(
Take part of a CSV parser, for example:
if @[ ‘,’ ].split(my_string) if my_string.split(@[','])
if my_string.split(',')
if my_string.split(',').len > 1:
# do stuffIt is better to pick languages based on platforms than the other way around.
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...
I second Clojure if you're specifically looking for niche.
If you goal though is to be highly employable I'd suggest Python
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.
I've been using Javascript for 20 years and I'm still learning new things (though it helps that the language keeps changing)
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.
personally i enjoy working with plain javascript. but i also liked coffeescript and i ended up choosing that for our codebase because job applicants were of higher quality (including those that had never used coffeescript before)
Thinking of yourselves as someone who is a writer of a certain programming language is self constarining and missing the point.
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.
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.
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.
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”.
I put certain languages in a general negatives bucket along with noisy offices, stack ranking, heavy process, etc.
(whisper voice) kotlin
1. Not every shop will let you use it
2. Kotlin has a bunch of the same limitations.
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).
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.
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.
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.
Compare that to understanding C or UNIX. There are skills that decay much slower than others.
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.)
Correct! Knowledge around C, Linux, CPUs and optimization last many decades.
Knowledge of tools and libraries in high-churn languages last years at best.
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.
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.
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.
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.
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.
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++.
There is power in saying No.
> 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
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.
But the question would be if one wants to be the go to guy for keeping old cobol things running.
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.
Although I’d suspect there isn’t a lot of refactoring going on in some of those code bases you describe.
You just don't want to be the person tasked with work that's only done because some contact got signed. Identifying the difference is hard.
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.
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.
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).
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.
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.
So the Sr devs wrote a bunch of really funky react code and the jr dev just wrote normal looking react code.
Original poster used the term fluent for someone with a few weeks to months of experience which both Sr devs had.
[0] "A language that doesn't affect the way you think about programming is not worth knowing." -- Alan Perlis
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.
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!
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.
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.
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.
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.
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.
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
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
Accounting for taxes and moderate expenses, at the end you should be sitting on close to 2m USD. That's more money than the vast majority of people make in their lifetime (after taxes). If you don't plan to live to a hundred you'll be fine even if you don't do any higher-risky investing, slowly spending it.
> 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)?
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.
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.
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.
Can we please stop using “4 year old+” as a generally applicable rule to reject libraries?
I know “4 year old” seems like forever ago in Ruby or Node (I can’t talk about Python or PHP), but other ecosystems such as Go and Elixir take compatibility seriously and “4 year old” libraries most often just mean they are done: they work for their intended purposes and there are no breaking changes in the language or tooling forcing frivolous updates.
I have used 8 year old Erlang libraries in the past with no issues whatsoever.
Nope, I only looked up the Elixir solution for the sake of my reply here. I haven't worked with Elixir in like 9 months.
Based on the docs it says IP.Subnet.is_in only supports IPv4. The Python and Ruby solutions transparently support both. That kind of sums up my Elixir experience (ie. something might partially exist but to really use it will require a lot of extra work). It's also impressive at how infrequently the Elixir docs come up in Google searches. It's strange considering how many words are there and it's the official source of information for the language.
Honestly my experience with python has been "the solution you're looking for probably exists, but using it will require a lot of effort, and heaven help you if you need to debug someone else's code", but I have mostly dealt with Django which is a nightmare of hidden code and tensorflow. Maybe it's just I've worked with shitty python devs and on the other project Google's notoriously bad engineering practices in some of their public facing OS projects (angular, tf)
Does that mean you can do something to make it transparently support IPv4 and IPv6 even though the docs mentions it only supports IPv4? Will it be more than 1 line of code?
> Honestly my experience with python has been "the solution you're looking for probably exists, but using it will require a lot of effort..."
I found it to be the opposite approach. The last time I wanted to increment a counter outside of a nested loop in Elixir it sprawled into a multi-week conversation with the author of Elixir, a git repo with 100+ programming language examples to solve the same problem[0] and a proposal on potentially altering Elixir itself to make this process a bit easier. The Python solution was about 2 minutes typing into my code editor and moving on with life.
Elixir solution: https://github.com/nickjj/nested-data-structure-traversal/bl...
Python solution: https://github.com/nickjj/nested-data-structure-traversal/bl...
I'm not saying either language is better than the other but there's certain things that can done a lot easier in Python and on the flip side I'm sure there's things you can do a lot easier in Elixir.
I found in practice for me personally when building typical web apps I kept running into roadblocks left and right with Elixir where as I never had these issues with Python or Ruby. That's why I stopped using Elixir.
> I have mostly dealt with Django which is a nightmare of hidden code
I think that'll happen with any big framework, especially if you haven't contributed a ton of code to it. The Rails code base can be intimidating too and Phoenix's code isn't any more approachable to someone who isn't already at the high end of expert with the language.
[0]: https://github.com/nickjj/nested-data-structure-traversal
I don't think the data structure was that crazy or rare. It boiled down to looping over 2 lists and wanting to keep an independent count of each one.
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.”
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.
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.
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.
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.
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.
They're all bad as none of them have algebraic data types.