This is one of the things I love about OCaml. Since answers are not a stackoverflow search away, it forces me to actually understand what I'm trying to do. Everything takes longer at first but I end up building a deeper understanding than if I was using JS or Python. It's something I could force myself to do in those two languages, but it's hard. Artificial limitations like not having that possibility in the first place can sound silly at first, but it's something that people use all the time. It's the idea of using a system instead of relying on willpower to force yourself to do the right thing and set yourself up for success.
You might be talking about solutions to popular problems are you? I can't imagine having to figure out the language's syntax or what the interface of packages/libraries is without searchable documentation.
It actually does sound silly to me. I just don't understand what you mean. Not in general, but in this particular case. If I'm searching for "reverse a list in python" — rest assured, I do know how to reverse a list, most likely in Python too, I'm just looking for most idiomatic way to do that (so, standard library function or syntax construct) and it just so happens that the answer on StackOverflow is usually more straightforward and easier found (by search engine, at least) than in the docs (and in Python it would be a syntax construct indeed, which usually complicates finding what you need in the docs even for the languages with much better docs than Python). So why would I care if I wasn't forced to invent my own way to reverse a list? I'm glad I was able to google it!
If it's actually something relatively high-level or language agnostic — which is when I would have to "understand what I'm trying to do" — chances are indeed higher that I'll find a solution in Python, than that I'd find a solution in OCaml, but the thing is, I don't really care what language I'll find it in, as long as I am able to read it. I just have to get the idea, then I'll write it in any language I can write.
One might respond that "well, not being able to copy-paste it is the all difference it makes", but, seriously, there might have been like 2 cases in my entire life (that's 15+ years of programming) when I just copy-pasted something from stackoverflow (I think I actually remember those cases — these were indeed very specific situations, some stupid language quirks, and workarounds for them really should've been implemented in the standard library; and TBH, I didn't even really care how they work, as long, as they work — these were not your typical programming problems). Otherwise, I just don't find it very applicable: there's always some difference between stackoverflow solution and what/how you want to do. So you read the code to get the idea, then you go and write it yourself.
Ok, there are also CSS problems, I copied styles plenty of times. But that's different. And I have to change colors and stuff in the end anyways.
It is silly, I agree with that. When I find a solution with stackoverflow or a forum or whatever, I tend to not remember well the next time I have this problem. On the other hand, if I'm forced to understand what's happening and what should I do, I will remember it and learn something. I don't know if it's a character flaw or a memory issue, but that's how I work. You don't seem to work the same way and that's fine, it's just how things are.
I think it's getting harder and harder to justify using anything but the most popular languages and frameworks.
You need a VERY good reason to use anything except TypeScript/C#/Java/Golang/Python/React/Vue/Postgres/MySQL/SQL server/Oracle. Perhaps Rust. These technologies are good enough to get almost anything done these days. There's exceptions of course for example games tend to written in C++ and embedded is often C.
Apart from anything, you should be using these most popular technologies if only for the sake of recruiting.
Using less popular technologies like Erlang/Dart/Kotlin/Ruby/Elixir/OCaml/F# or whatever weird new JavaScript React alternative thing got you interested lately is a bad idea not just for recruiting but for support and community and documentation.
If you are the person deciding which technologies to use, you should probably be using the most mainstream thing you can, not the coolest newest thing that you read on Hacker News. There's any number of companies saddled with their main systems being built in the weird assed framework that the fourth-to-last CTO decided was a good idea, and those companies are now stuck with the problem.
I should note of course that my comments refer to company/organisation development. For personal projects or fun or whatever you should do whatever the heck you enjoy.
There are also companies saddled with tech that was mainstream but is no longer. Adobes Flex was a great option until it was killed. Perl was everywhere now it's almost esoteric to find a greenfield project in Perl.
I was back on the job market not too long ago and I was stunned to discover how many startups are still using Rails. It's well off the hype peak now but there's a lot more life in it than I supposed.
Not dead just yet but things are not looking promising. eg Ruby is 20th on TIOBE vs 13th last year. Other measures are showing a similar downward trend.
Not impossible to reverse but very hard, especially since Ruby only has once niche and has not been doing well there.
I have a friend that swears up and down that his startup on Erlang was able to deliver incredible speed of development and stability specifically because of language choice.
WhatsApp, Facebook Chat used Erlang, and Discord is still using Elixir… make of that what you will, I suppose.
And Ruby / Rails + your frontend of choice is still a ridiculously productive stack to bring up an app, and probably run it at any scale you’re likely to realistically hit (poster child being Shopify)… if you ever get to stage of “scaling problems”, you are at a stage where you’d be rearchitecting parts of your stack regardless of what your original implementation was in.
So in sum, choosing a particular language because of popularity, I think, is not particularly useful framing. I’d say, choose one because it either gives you joy to write in and maps to your thought process well, or because it has a particularly strong ecosystem for the subject matter. Life is too short to program every day in a language that you dislike just because you think it’s the “safe choice” :)
That's an interesting point. Do you think your friend was able to deliver at such speed because of the familiarity with Erlang? Or was it so, that even with a lack of familiarity, the other advantages of the language were overwhelming? Also, may I ask what kind of application was being developed?
I also wonder how we can define popularity better. Does that mean industry acceptance, number of GitHub repositories, number of StackOverflow questions, number of libraries, developer satisfaction surveys, etc. If you choose different metrics here, different languages and frameworks will appear popular. Svelte for example seems to be on top of some developer satisfaction surveys, but React is still one of the number one choices for frontends. C is the industry standard for embedded, but developers often do not enjoy programming in it.
I’m not sure how much Erlang he had done before he started the project… it was something in the professional group chat space, but Slack ate the world.
Yeah, there is always a balance to strike and a multitude of factors that might lean the decision this way or that…
And even in something like embedded it seems like there is movement, I have seen some posts about people using Zig or Rust or Nim for embedded programming for example.
I find it very odd that PHP wasn’t even in the list of languages. It’s one of the most popular web languages (and that’s not just Wordpress).
Additionally the standard request model of PHP (like with PHP-FPM) is a fast, efficient, and easy to learn model of request for new developers. Easily scalable new processes that are cleared at the end of the request. It seems like this is something people try to emulate with the “server less” model but PHP was built for this and is quite efficient at it.
It is indeed a good and efficient tool, and popular too, but I'm kinda glad it wasn't on the list, because it basically is the point of my tongue-in-cheek comment: choosing the "universal list of tools to solve any problem" is a PERSONAL achievement. It's just basic reality that both Python and PHP are good enough to make things. Some people have one on the list, some another, some may have both.
And it's not even true that Haskell cannot be on that list for any sane human. Admittedly, it's not on MY list, but that's just me. Popularity isn't the end of things, nor is it set in stone. Agda or TLA+ aren't very common, but neither are problems they are meant to solve. Neither is Verilog, but it's not even an alternative to anything popular. And Ruby wasn't popular before Rails. Then it was, then it wasn't again. I thought that I was done with Java, but then Android became a thing. I guess you get the point.
…I think I'd like if there was only 1 language for everything, but I don't think it's even remotely possible, because then there would be different dialects of that EsperantoPL, different frameworks or ways to use it, and people would never agree on 1 thing anyway.
I'm not doing embedded systems in PHP. I'm not doing high-performance computing. I'm not doing operating systems. I'm not doing an enterprise database. I'm not writing the JVM in PHP. I'm probably not even doing a desktop app in PHP.
I agree. For most CRUD applications, developers should mostly integrating off-the-shelf components, and not constantly be reinventing the wheel. The reason for that being, that customer value (and satisfaction) can be attained by delivering a usable product, and that is what pays the bills at the end of the day. Whether that product is implemented in Python or Elixir is often not visible.
On the other hand, if the task at hand requires a novel approach and using tools that are less frequently used, then that will also be justifiable. Are you developing something that only makes sense to run on the BEAM virtual machine? Go ahead and work with Erlang or Elixir.
Now a third category is programming for enjoyment. In that case you don't work with the constraints of profitability, and you can just have fun. And don't worry too much about Beating the Averages (http://www.paulgraham.com/avg.html)
Enjoyment is much more important than many managers think. Attrition is real, especially nowadays. Enjoying the work, which includes the programming language among other things, plays a big part in hiring and attrition.
I hear you, the last thing I want to feel is dread when implementing something. But recently my priorities have shifted a lot with regards to using the fancy, the new and the shiny. Sometimes I just want to end the day with getting something done and going home with the feeling of satisfaction and having achieved something tangible. Again, context matters with these things.
And with regards to employee retention, I would rather bet big on benefits (paid time off, parental leave, etc.), reasonable working hours (4 days per week), achievable goals, great communication, democracy and good team cohesion. I have a feeling this works for a lot of people. If a language is the only thing that makes you stay, by all means find a place that truly makes you happy in that regard. All I am saying is that there are a lot more variables to worker satisfaction.
> I would rather bet big on benefits (paid time off, parental leave, etc.), reasonable working hours (4 days per week), achievable goals, great communication, democracy and good team cohesion
Those are important factors also. But I would prefer to work 5 days per week and enjoy my work rather than working 4 days and not enjoying it because the PL sucks. Just my 2 cents.
You make an assumption that using “weird” language is new and shiny when those are generally older than “established” languages of today. You can end the day with getting something done in “weird” language too, again generally faster than in some obtuse Java or Go codebase.
How did you miss PHP in that list of languages? It’s the most popular web development language. It has 2 very popular web frameworks (Laravel and Symfony, although Laravel seems to have the bigger developer community) and the language has been evolving in a pretty good direction.
Did you actually read the article you posted? It states that 79% of sites are using PHP. WordPress is 40%, Joomla 2%, Drupal 1%. So no, they don't combine to ~90% of PHP sites, far from it!
The article even concludes with:
"PHP is far from dead, no matter what any disgruntled developer may tell you. After all, 79.2% of all websites in the world can’t all be wrong, and most importantly, PHP’s market share has remained relatively steady throughout the last five years (oscillating between 78–80%). Few programming languages command that type of staying power."
PHP powers a lot of legacy code bases, yes. But there are also a lot of job opportunities in Laravel and Symfony which are both very good frameworks.
For web development you need a very, very good reason to use anything but Rails or Laravel. It got to the point where now I only work with companies who use Rails. I don’t even really like Ruby, but I eventually got fed up with wasting time reinventing the wheel over and over, using frameworks that provide only a fraction of what Rails does.
Sadly this is shifting; at least in my country most companies are moving away from Rails/Django/Laravel towards Typescript and NodeJS for the sake of "scalability" and sharing language with the frontend.
Meanwhile I will take "weird" languages almost any day... Icon (Unicon), Snobol4, Pike, Awk, Pascal. In a perfect fantasy world I'd also hire these people first.
As the article indicates, there's no SO or Google to find solutions easily... You need to read the docs or find some dark corner of the web for help you require. It highlights passion and genuine interest in understanding what you're doing and figuring things out yourself. Whereas your languages are financially job driven... Not curiousity driven; and my issue with that is if you can learn the esoteric languages, the mainstream languages are laughably easy.
I also love weird (/old) languages as the community that exists, however small, are asking 400-level questions amongst each other and not CS-101 topics. There's a nice serenity in not having polluted search results of utter basics.
Snobol4! I keep a couple of books like Snobol4 programming and my C64 Reference Guide around to remind the kids that the history of computing was old even when I started. It's surprising reading through those older texts and languages how little things have changed other than the speed of computation and connectivity of computer networks.
Ignoring unusual languages doesn't guarantee you are financially driven, sometimes it just means you're more interested in the actual use case than the tech.
My favorite programming language is an amazon link. If I can say "I could build this, but it already exists here", I'm happy because I know I've given them something truly professional in a week that would have taken way longer and cost way more to build, plus any random person can work on it and parts will be available on eBay.
Using common languages is just an extension of that.
If someone uses unusual languages, I expect they'll have unusual problems that will become my problem if I'm working with them.
I agree with you 100%, especially on the first paragraph. Definitely I'm interested in use cases and knowing best tool for job. I only mentioned the finance part as the poster mentioned recruiting a couple times... Thereby a job, and money.
While I've seen many projects out there use Oracle DB without that many issues, I'm inclined to say that MySQL/MariaDB and PostgreSQL are both easier to work with due to how easy it is to setup new instances (either on a server, or in containers for testing/development) and how they're generally just simpler to use and more carefree products (though perhaps that's because of sane defaults, e.g. no problems with tablespaces that don't autoextend), even when something like Oracle XE exists.
Some smaller companies have found that choosing “weird” languages gives them a much more focused pool of candidates from which to choose. Advertise for a Java position and you’re going to be overwhelmed with résumés.
And you’re doing a grave disservice to Elixir at the least. I prefer Erlang myself, but Elixir has established itself as a robust choice.
Yeah, I definitely don't care what backend language experience someone has before hiring them.
I haven't had the same luck with frontend. There's so much magic, config file hell, and other rough edges that you need someone who knows the framework. In the JS world, actually writing code is maybe 50% of the work, and managing the ecosystem (config, build, packages, etc.) is the rest.
> You need a VERY good reason to use anything except TypeScript/C#/Java/Golang/Python/React/Vue/Postgres/MySQL/SQL server/Oracle. Perhaps Rust. These technologies are good enough to get almost anything done these days. There's exceptions of course for example games tend to written in C++ and embedded is often C.
I'm not sure what you're suggesting.
Are we expected to rewrite everything every decade when a new flavor of language comes out?
It seems like, with the exception of Rust, you've named a lot of "lowest common denominator" languages. These languages, while productive, tend to lack expressiveness. It is my opinion that expressiveness is seen as a bad thing in the "professional" community because it takes significant cerebral evolution over the course of a career to learn which tool in the toolbox to use. In other words since the explosion of programming as a career there are more idiots in the proverbial gene pool, and so more companies prefer more idiot-proof languages because the average developer can't help but hurt themselves. This doesn't mean we should prefer "new safe technologies", it means our recruiting should far more stringent and our education far more formal (as in an actual useful programming degree).
I for one would quit if I could program, for example, common lisp and make even 3/4 of my current salary.
Here's, in my opinion, a better and less controversial hot take. Use what works. If you have a team of erlang developers do it in erlang (or whatever). Who cares about the market. If it means spending even more time (and money) learning to write another more popular language correctly it may not be worth the investment. If you build it, they will come. You will have no problem finding an endless stream of developers you can build from the ground up.
As a side note: Kotlin, Ruby, and F# are extremely popular. TIOBE is not a real measure.
> If you have a team of erlang developers do it in erlang (or whatever). Who cares about the market
As an IC, I care about the market. I go to work exclusively to exchange my labor for money to support my addiction to food and shelter. When it was time to change jobs as your bog standard enterprise dev, it was much easier to throw my resume in the air and get a job offer by being an experienced C# developer than it would have been if I had spent three years writing software in Erlang.
And most job interviews outside of tech companies where most developers work are not going to be language agnostic nor are they going to have you reversing binary trees on the whiteboard while juggling bowling balls and riding a unicycle on a tightrope.
As a reformed former dev lead, why would I hire an Erlang developer when I could throw a rock and hit a good enough C#/Java JavaScript/React developer to push out some CRUD SaaS app or line of business app?
Because the average Erlang developer is probably a better developer than the average in those languages and still quite capable of writing in any of those languages, at least with a little study and practice.
Are we really to believe that the average Javascript developer is going to be able to be dropped in an Erlang shop (or any of the other "weird" languages) and be productive any time soon?
The “language” is the easy part. Every language has an ecosystem around it and foot guns and best practices and frameworks. Take C# for instance, sure the language is decently easy. But, the first and third party frameworks around it are huge.
I’m sure I could (re)learn Java that I haven’t touched since shortly after it was first introduced in the 90s in a few weeks. That doesn’t mean I would be a competent Android developer.
The average JavaScript developer would be an idiot to ever step foot in Erlang shop if he knew what was good for his career.
My resume was sacrosanct when I was in the enterprise dev world until mid 2020. Why would I reduce my optionality by not using the most marketable technologies?
And I assure you that someone who needs an Android app written wouldn’t care about your distinction or are you claiming that a Java developer who never wrote an application for Android would be just as effective as one who had?
Who would you rather lead the development of your Android app? Someone with no experience with Android or someone with previous experience.
That depends on the team leader and how well they can take suggestions. It's a team, not everyone will have the same background and, probably, nor would it be best that they did.
So if the team lead that I’m hiring to be the subject matter expert can’t be the go to person for technical solutions based on relevant experience in the domain, who should it be?
a) the most experienced amongst the team in any particular language
b) the most experienced amongst the team in any particular domain
c) the go-to person for any particular problem
The whole point of a team is to cover several different sets of knowledge and experience because no one person can know it all or do it all. A leader does their best to enable this collective to produce the best it can.
It seems like a case of different incentives for different people.
If the incentive is to ship product then choosing the language you already have a team for makes the most sense.
If you are choosing based on hiring a new team, then the current flavors work. 20 years ago that was Java. Today it's C#. 20 years from now it'll be something else.
If you are a developer looking to grow a resume for the next job, then it's a double-edged sword. Sure it's easier to get a C# gig. But it pays less because you're in a bigger pool. It's harder to stand out. Conversely it's harder to get say a Cobol gig. But it's easier to build a profile in the Cobol community (simply by being under 80 years old) and there is a Lot of work around, and is very well paid.
Equally something that's marginally popular now will have a long tail and can be very lucrative. Erlang might be obscure, but there are plenty of shops who would love to pick up another experienced, capable, erlang developer. You're a bigger fish in a smaller pond.
So yeah, language is like most things, dependant on your point of view. That's why we gave so many of them.
20 years ago, Java was already becoming pretty big in the enterprise. Today there are plenty of Java jobs from your bog standard banks and insurance companies all the way up to the BigTech companies. The biggest ponds don’t have fish using Erlang.
BTW, what languages do you think all of those BigTech companies that pay well are using?
I just keep bringing up C# because that’s the language I have the most experience with. But substitute $any popular language.
Erlang might be slightly more obscure, but there are plenty of big household names using the language - Klarna, Bet365, and William Hill are all household names. And that's excluding the obvious cases of Ericsson or WhatsApp.
I don't think it's always easy. it's been quite a struggle becoming proficient in Haskell, just drinking from the firehose of type theory you need to get things done.
also note that Jane Street does everything in OCaml. I can't believe it's bad for their employees' careers. probably because they're not looking for the same jobs as the average JavaScript pleb.
The language is only easy if you have basically learned the language already. Java, C#, C++, Python, Go etc. all differ but fundamentally they are all the same language with different amounts of window dressing. So yeah if you know one of them it's easy to "learn" the others. But I wouldn't really call this learning a new language.
It's a fundamentally different ask to learn Haskell, datalog, SaC. You are actually learning a new language instead of just the flavour of the week imperative programming.
If the language is the hard part, something is wrong with it.
Usually. I've seen and user a whole slew of opinionated languages, and they almost always have a big chunk of problems they will be awkward to use for, or even almost insoluble.
Every succesful one supports multiple programming paradigms, better or worse, usually decently.
Now the real stuff that can cause problems is bad tooling and lack of support. You cannot code your things when you're trying to fix the compiler, build tools or the debugger.
The last time I had a job where I only had to learn “the language” to be effective was 1999 programming in C and FORTRAN on VAX and Stratus mainframes. By 2000, “knowing C or C++” didn’t do any good without knowing MFC, COM, etc.
What good is a language in 2022 without a complete ecosystem of frameworks for most jobs?
Haskell is not particularly esoteric, but heavily opinionated.
Libraries cannot change that basic fact - there are just problems it will be extremely unsuited for.
Java has some of the same problem by the way in reverse. (Package handling, forced garbage collection and unknown real time and memory usage characteristics.)
The difference being that Java's core has much less important opinions about algorithms, while Haskell tries to make everything functional or it is awkward.
So, while Haskell will be hard to use for problems best described in an imperative way (in addition to other issues say Java has), Java will only have serious problems where memory and runtime determinism are paramount.
It so happens that a lot of the programming is done in imperative way. Including the libraries.
Say I’m developing an application that needs to interact with cloud services.
The last time the third party Haskell SDK for AWS was updated was in 2014. I do see a third party GCP SDK. But if GCP and Azure works like AWS, as soon as a new API is released by a service team, all of the officially supported SDKs automatically get updated.
I am sure there are other service providers that have SDKs and code samples for popular languages.
I believe the list for GCP and Azure are about the same. What are the chances that your problem is such a special snowflake that it can’t be solved with one of those languages? What are the chances that any new developer could ramp up faster or already knows Boto3 (the AWS SDK for Python)? If they have an issue, they can go to StackOverflow or raise a ticket with their TAM.
Which would have more assurances are designed correctly, the one from the vendor or yours? I was able to take advantage of new APIS for one of AWS services the day it was introduced, no need to waste cycles on creating my own wrapper. Creating a wrapper around my cloud providers APIS, “doesn’t make the beer taste better”
AWS’s SDKs automatically take care of retries, exponential back offs, wrapping the APIs to be idiomatic including logical exceptions being thrown, any underlying changes, etc.
> How much more “productive” do you think they would be just by being able to import a module in any of the supported languages?
The same language? Maybe a few % considering a client is a small part of what you need to create. A different language? Depends on the comparison. I would be tens to hundreds % more efficient in Haskell then in Go or Python.
> I believe the list for GCP and Azure are about the same. What are the chances that your problem is such a special snowflake that it can’t be solved with one of those languages?
Of course it can be solved in those languages. I can also solve it in Assembly or brainfuck with enough elbow grease. What matters is speed of implementation and correctness. With the exception of Rust all these language have debilitating flaws.
> Which would have more assurances are designed correctly, the one from the vendor or yours? I was able to take advantage of new APIS for one of AWS services the day it was introduced, no need to waste cycles on creating my own wrapper. Creating a wrapper around my cloud providers APIS, “doesn’t make the beer taste better”
> AWS’s SDKs automatically take care of retries, exponential back offs, wrapping the APIs to be idiomatic including logical exceptions being thrown, any underlying changes, etc.
Did you ever try openapi generated clients? They can handle retries and exponential backoffs as well. There is no design to be done here. It just exposes the API as designed.
None of the cloud providers provide the internal specifications used to autogenerate the SDKs for the languages I listed. In the case of Boto3 (the Python AWS SDK), while there are one to one generated mappings from the spec, there are also higher level constructs for the most popular services like S3 and DynamoDB and also helper functions like Waiters for asynchronous operations where you need to poll for an operation to be complete and Pagers that handle get request where the requests are being polled. Sure you could do all of this yourself. But again, “does it make the beer taste better”?
This isn’t meant to be a rah rah AWS is the bees knees. It’s just the cloud provider I know the best (and the one I work for), I’m sure knowing MS, the developer experience is just as good as AWS. I just don’t have experience with it.
> Of course it can be solved in those languages. I can also solve it in Assembly or brainfuck with enough elbow grease. What matters is speed of implementation and correctness. With the exception of Rust all these language have debilitating flaws.
What’s the old saying about it’s a poor craftsman that blames his tools? If you can’t be productive in any of the nine languages that are popular enough to be supported by the major cloud providers, does that say more about the tools or the craftsmen?
I would be more likely to hire a JS dev if they have Elixir experience not less, but I am not in the enterprise world.
Work is not only about money for me. My best work environments have been a small team of skilled people tackling a big problem. For this we would use whatever is the best tool for the job, regardless of its outside popularity.
From my experience the shops using esoteric languages aren't recruting based on knowledge of a specific tool. They're hunting for very experienced candidates. It's assumed you'll learn the language. Knowledge of a specific language does not necessarily mean you're a good developer.
And why would an “experienced candidate” ever step foot in those shops when they could easily get a job using a more marketable language that probably paid just as much and would make it easier for them to get their next job?
I personally would be hesitant to hire someone who only listed popular technologies on their resume. I’d be worried they would suggest using technologies that improve their resume rather than ones that are good for my business.
Your business is probably not a special snowflake and probably would be served by using the most popular relevant technology. It would be much easier to recruit and to find help.
I personally hate the clusterfuck of the modern front end ecosystem and would avoid it like the plague. But, if I was responsible for choosing the framework to use, I would choose React any day just for recruitment reasons.
Because that "marketable language" is dull and frustrating?
If you want top talent then you've got to offer something they want; sure you can always pay more, but past a certain point that might not be enough, plus it gets expensive. Using better languages is one of the most effective ways to get noticed by the candidates you really want.
It’s more frustrating to want to leave a job and not be able to find one quickly because your experience is in some obscure language.
When I was in the Enterprise/Corp dev world until a couple of years ago, I could call a few recruiters and have 8 interviews and two or three offers within less than a month. It’s easy to pattern match when you use a popular technology.
Ehh maybe. Sure, if you use a bland corporate language then you can pick up a bland corporate job whenever you want. But what's bland corporate job B going to give you that bland corporate job A didn't?
Taking a dull job so that it's easier to change to a better paying dull job doesn't seem like a great tradeoff to me. Bullshit definitely happens but again, dealing with a crappy language's bullshit from day 1 so that it's easier for me to switch to another job that will definitely have at least that floor level of bullshit doesn't feel like a great option.
The biggest companies largely use dull languages, sure, although you sometimes find pockets within them that are doing something at least a little nicer (e.g. OCaml at Facebook). So much the worse for the big companies.
You saw my original spiel about going to work to exchange labor for money? I don’t go to work to find excitement. I go to work to provide food and shelter.
My excitement during the first decade of my career came from my working hobby as a fitness instructor and running with friends. In less than a month my “excitement” is going to come from my wife and I living out of two suitcases flying across the country staying in mid tier hotels for a few years.
I could spend my free time learning a new programming language. But I am finding it much more “exciting” learning Spanish so when we stay in Mexico for a few weeks, I can at least be able to communicate somewhat.
If you want a job you can easily switch for an equivalent job, which seemed to be your pitch for using a boring language, then that job is at best going to be a 9-5, which will take up something like half your waking life (at least for the decades when you're the most healthy). I'm a big believer in life and hobbies outside of work (and when I want to learn a new programming language, I look for a way to do it on the clock), but an engaging, interesting job that pays less is often a very worthwhile tradeoff.
I went the other direction. Took a job that paid half as much as my previous one, but it's interesting work, and I'm a lot happier. Grass is always greener I guess.
Because comp is similar and it's fun. Plus I fail to see how working in a less popular language hurts future job prospects. If anything my experience with less popular languages usually leads to a fairly lively, informal discussion during interviews.
Because when you throw your resume out there and a hiring manager is looking for a “full stack developer who knows (Java || C# || Python) && Typescript” why would he choose you over someone who could hit the ground running and add immediate value?
To be fair I have no idea about the full stack life. I, however, am also not convinced they add "immediate" value. Once you're beyond mid-level being a so-called generalist is not as useful. Most of my work at high senior, and now staff level requires actual deep knowledge of the preferred stack. I have yet to meet a reformed full stack developer in our ranks and there are tons we hire, and even more that come through the door.
I don’t touch the front end development. But I am very much a “generalist”.
- back end development in a few popular languages
- about an average “data architect” for lack of a better word. I’ve led implementations on every type of database imaginable including ETL type jobs and online systems.
- “DevOps” (at least if you give me an AWS account) including setting up networking infrastructure, logging, monitoring, CI/CD, etc.
I’ve led plenty of pre-sales meetings, writing SOWs, pretty PowerPoint slides and architecture diagrams etc.
The “generalist” is very useful when you need someone to lead projects and to understand how everything fits together. I’ve had to wear all of the above hats at startups. Now I wear those same hats at a cloud provider I’m sure you have heard of. I specifically targeted my current position because I wanted to be a generalist.
I’m no special snowflake. Many of my coworkers who came up the ranks in startups and have similar experience can do the same.
Probably because I'm competent and there is more to adding value than memorizing specific tech. I can't speak to your experience, but as far as mine goes I've never had a problem landing a job.
I'm zero worried about it as it's never been an issue.
I have “prior experience” in any many languages. But I know the ecosystem has changed to the point where someone who has recent experience would be more valuable. That would be like me (hypothetically) saying I had prior experience in JavaScript from a decade ago and I can write JQuery with the best of them.
An organization that prefers ecosystem knowledge to deep knowledge and ecosystem familiarity hints at poor planning and needing someone to "hit the ground running" to fix their mistakes.
I'd pass on such a position.
Also you talk about only having experience in a less popular language as a death sentence.
I've been only writing Haskell professionally for a decade, but I get endless amounts of interview invites for prior experience.
Out of curiosity I went through some of the better invitations interview process and had no issue getting offers either.
If anything mentioning my professional Haskell experience gets me an offer faster no matter the positions requirements.
If a company is looking for senior developers who are to serve as team leads and lead initiatives, why would they hire someone without previous experience in the technology? I’m sure you could eventually get up to speed. But the reason I haven’t had to do a coding interview in well over a decade of working at companies from your standard Corp dev jobs, to companies where they wanted a “tiger team” to lead green field initiatives, to a startup where the then new CTO was looking for someone to lead “cloud native projects” to my current job in the cloud consulting department at BigTech is because I knew the ecosystem well.
When I spoke to CxOs and directors, they wanted someone with a proven track record that could solve their problems. When I was being hired as a dev lead to lead junior C# developers he inherited, what would he look like hiring someone who knew Haskell?
How was i suppose to go from an empty git repo to a fully fleshed out MVP or later from an empty AWS account to infrastructure, CI/CD, to a fully fledged out MVP if I didn’t have prior experience?
If someone is looking to create a new iOS app. Who should they hire? Someone with iOS experience or someone with Erlang experience?
Conversely, if you spent 3 years writing Erlang, you are suddenly not one of a hundreds of thousands of candidates, but a part of a much smaller pool, and having an expertise in a semi-esoteric language along whatever mainstream languages you know is a strong signal that you’re not just an average bear.
It also means you’re competing in a much smaller market and people looking for strong Erlang developers will be suddenly very interested in you specifically, because it’s tough to find strong candidates with this expertise.
It also might mean (depending on your interests) that positions that are open are in a more intellectually interesting problem space, because boring problems tend to be solved in the lowest common denominator languages, and if an unusual language is chosen, it might be chosen because it’s a being used in a unique context.
Ok, but do you really think you’d have a hard time finding work with your xx years of experience, regardless of what language you have been most recently working in?
As in, reductio ad absurdum, “if only I had been working in Java, I’d be safe, but because I worked in Ruby, I am going have to go flip burgers, as no one will let me near their precious production code now?”
I mean, yeah, ok, there was the dotcom bust, and I suppose another could happen at any point, but somehow I get the impression that you’re arguing that using any language except the most mainstream option (whatever that might be for a given industry) is too risky? Or am I misreading?
Well, I wouldn’t have a hard time finding a job in my current speciality cloud architect/cloud dev because of where I work and what I do. No one would ignore my resume.
But in the boring enterprise dev world where I came from especially during the latter part where I was specifically being hired to lead initiatives, of course they wanted someone with relevant experience.
Idiot proof languages are popular. If you want assured money learn an idiot proof LCD language. In fact, everyone should have one in their tool belt to put food on the table.
However, if you're actually a talented engineer these languages will hamstring you and your art. You will probably eventually gravitate to something more heady (such as the less popular languages) and probably even leave your nice cushy gig to give a professional life in that stack a shot. This isn't, however, to say talented engineers don't exist in lowest common denominator language pools. It's just esoteric/less-used languages tends to cause the best quality of talent to come from them owing from many of their problems. If you can be proficient and productive in a language that you can't easily google a solution for, you're probably an excellent candidate for promotion into the higher echelons.
This is a similar phenomenon to editor choice. My anecdata in a little over 10 years of a career has given me the impression that I can tell what kind of developer someone is by their editor. People who use raw vim/emacs tend to better developers. Why? It's not the editor itself. It's that these editors pull no punches and require time and expertise. That dedication is not taught. The easier an editor is to use for a beginner, the more average a programmer tends to be. Again, there are a lot of very talented developers using VSCode or full blown IDEs. But with those editors your signal to noise ratio is quite low. It's anecdata but mixed with the information above you can gather a lot of "metadata" about a person without much effort.
It's like the equivalent of judging a carpenter for using power tools because he's just not dedicated and gritty enough to use a manual twist drill.
My anecdata, people who overly focus on language and tools tend to be the worse developers. It's the developers that effectively address the universal problems of writing software people want to use, like api usability, reliability, data consistency, maintainability that have the most props in my book. The best developers I've known weren't particularly attached to any editor, language, or framework.
> It's like the equivalent of judging a carpenter for using power tools because he's just not dedicated and gritty enough to use a manual twist drill.
Serious question: all else equal and without any additional information, between two carpenters who produced the same output in the same time, one with power tools the other without, is there any reason whatsoever to assume one of them is any better than the other?
My question was not answered. In that scenario you have access to the work both of them do, so it speaks for itself, and it is equivalent work done in equivalent time. Use or non-use of power tools is the only difference. Do you factor that in your judgement or you flip a coin when choosing an employee or supplier?
Okay, so this means it's not relevant to you which is... an interesting take. I guess you better operate your business in at-will employment legal landscape (and not feel bad for your employees' families after you fire them left and right this way).
For me I would definitely make use of this extra information before hiring. Hiring a carpenter who's able to work with power tools is likely better, unless I need to foresee a situation where they must work without electricity. Even if they are physically fit, power tools can enable a human to do something not possible at all with bare hands.
For a programmer it's the reverse, if we assume "power tool" is an "easy" language compared to something like OCaml, or maybe tools like VS Code and Copilot compared to vim. These tools don't help overcome a physical limitation, like the power tools of a carpenter, but a mental one. Being able to set up vim fully to be as productive and produce as few bugs as someone with VS Code, or being able to pick up Haskell without being able to immediately get a human answer your every question, exemplifies the type of higher-level skills and learning capability that is the primary value of a human employee compared to a robot.
In other words, in context of this discussion, the equivalent of carpenter's power tools might be much closer to Haskell + bespoke vim/tmux setup than JavaScript + VSC.
No, drilling holes doesn't make you a good carpenter, use the most convenient tool you have available. Designing a good chair that people want to sit in then producing it from idea to reality does.
I'd think manual carpenter is going to have to retire early due to repetitive strain injury.
Same but for a different reason. Being able to overcome the learning curve and become comfortable using power tools to achieve equivalent results makes you a valuable employee as a human, it raises you to a higher level of control and increases your capabilities beyond what you could do with bare hands. (The only benefit of being capable without power tools is if there's no electricity for example. IANAC)
The same with "easy"/mainstream languages: something like OCaml/Haskell/Nim/Nix/etc. is a power tool with a steeper learning curve compared to something like Python/JavaScript/shell scripting; you being able (and willing) to handle it without abundance of learning resources says something about your mental capacity and potential value as an employee.
This is like one (non tech) company that I was hired at as a dev lead where they were about to embark on writing an “address validation module”. I quickly put an end to the entire project and worked with a vendor to license CASS software.
Companies pay employees to add business value. Not to get into their own flights of fancy to do things the hard way. As you mature, you learn only to focus on things that “make the beer taste better”.
I have yet to see an argument by any of the proponents of “obscure” languages where their choice adds business value.
And the “hard problems” that are being solved by the large companies at a scale that has never been solved are doing so by using mainstream languages.
I’ve never seen a report of a job interview where they asked you to reverse a binary tree in Erlang.
The vast majority of problems that developers are being asked to solve are not that hard technically. They are business problems.
I mean more having learned to be productive in an obscure language as a positive marker regarding your mental capacity, intrinsic motivation, autonomy and initiative. If you then insist on using it for everything, business value be damned, that is a red flag. Choosing an obscure language to tickle your fancy would be negative value to me as a business owner since I need to hire and maintain a team of developers who are all comfortable and proficient in it. However, there are circumstances in which an obscure language might just be the right tool for the job (and overall architecture that can accommodate a small cohesive component written in a different language has its benefits).
You think it’s a red flag for a business to hire people who can add business value?
I’m motivated to get up everyday for the same reason most people are - money.
I bet you’re looking for people with “passion” and who are willing to consistently put in more than 40 hours a week aren’t you? Out of all the millions of things I can do and have done in my free time over my career (including a working hobby as a part time fitness instructor back in my younger days an avid runner and a weightlifter) spending more time sitting at a computer outside of work isn’t one of them.
And the obscure language would hardly ever outweigh the need to recruit developers easily.
> You think it’s a red flag for a business to hire people who can add business value?
Where have you seen that?
> I’m motivated to get up everyday for the same reason most people are - money.
You are quite mistaken. Once they have enough to exist comfortably, people tend to seek meaning not money. The emergence of OSS ecosystem is the best example -- a lot of it, including the most popular OS in the world, came about as hobby projects people did in their spare time. If you're a software engineer, I bet you use products of their passion a lot in your money-making activities.
> I bet you’re looking for people with “passion” and who are willing to consistently put in more than 40 hours a week aren’t you?
Again, all else equal, if I need to make a decision as to who would be a better, more capable employee in absence of other information, the one who managed to be productive in an obscure language would be higher on my list. Just that. Everything else, making people work overtime, etc., is your addition.
> It's like the equivalent of judging a carpenter for using power tools because he's just not dedicated and gritty enough to use a manual twist drill.
I think this is an apt analogy. Mostly because carpenters who use hand tools produce more beautiful, unique works of art. When everything you do is on rails (no pun intended) you don't have the flexibility or creativity to make works of art. It's like saying Ikea tables (the equivalent of an idiot proof language) are just as nice to look at and functional as a purpose-driven hand crafted table. I have my doubts, despite using Ikea when I "just need something done".
Nice one, being it elucidates the art being lost in other fields (and perhaps all over).
Your analogy doesn't make sense. There's nothing about the programming languages you consider "least common denominator" that lock you into a specific design, unlike your Ikea table. Actually those LCD programming languages are generally the least opinionated in how you use them.
> Idiot proof languages are popular. If you want assured money learn an idiot proof LCD language.
You saw that whole spiel about my desire to exchange my labor for money to support my addiction to food and shelter?
> However, if you're actually a talented engineer these languages will hamstring you and your art.
I have no desire to be a starving artist. I turn requirements into code so businesses with money will give me some of it by adding business value. I don’t program to create the next Picasso.
I stopped considering programming “fun” after doing it for 10 years across 4 assembly languages (65C02, 68K, PPC, x86) before I graduated from college in 1996.
> and probably even leave your nice cushy gig to give a professional life in that stack a shot
So tell me again why I would leave my “cushy gig” (and it is the cushiest gig you can imagine in any BigTech company)?
> you can be proficient and productive in a language that you can't easily google a solution for, you're probably an excellent candidate for promotion into the higher echelons.
Every single leveling guideline I have seen at any tech company doesn’t mention “ability to code in an esoteric language well”. It’s all about “scope”, “impact”, “managing ambiguity”, etc. “Coding ability” really only comes into play from junior to mid. After that it is about system design even at the interviews.
> I stopped considering programming “fun” after doing it for 10 years across 4 assembly languages (65C02, 68K, PPC, x86) before I graduated from college in 1996.
this makes me sad to hear. I fell in love with programming at age 7 and still love it at 32. I'm extremely fortunate to enjoy something that pays well, rather than languishing at a cushy job that leaves me empty.
> Every single leveling guideline I have seen at any tech company don’t mention “ability to code in an esoteric language well”. It’s all about “scope”, “impact”, “managing ambiguity”, etc. “Coding ability” really only comes into play from junior to mid. After that it is about system design even at the interviews.
if you're hiring plumbers, sure. it's not all plumbing, though. there's algorithm design, compiler engineering, formal verification, program synthesis, numerical methods, etc. etc.
the really effective people in those fields use (or make) weird languages. Isabelle's written in HOL, Coq in OCaml, Agda in Haskell. having a knack for weird languages is a plus for brainy jobs working on that kind of stuff.
> I'm extremely fortunate to enjoy something that pays well, rather than languishing at a cushy job that leaves me empty.
My job paying well allowed my wife to buy a vacation home/investment property for the winter and starting at the end of the month fly around the country and stay in mid tier hotels and do the whole “digital nomad thing”.
I spent the first fifteen years out of college having a great time outside of work as a part time fitness instructor (more of hobby) and training and running with friends.
It's very good and healthy to have a life outside of work, but you're still going to spend anywhere between 25 to 60 hours a week working.
Making sure that you actually enjoy those hours has a massive impact on your quality of life.
For an extreme example, what pay cut would you be willing to take if you were able to do fitness training full-time?
> My job paying well allowed my wife to buy a vacation home/investment property for the winter and starting at the end of the month fly around the country and stay in mid tier hotels and do the whole “digital nomad thing”.
This is somewhat off-topic and I don't know you or your wife personally, but I find it flabbergasting that a spouse would choose to do the "digital nomad thing" when their partner can't or won't follow them. Even more so when they're being bankrolled by said partner.
I feel this is true. If a person has a few esoteric languages under their belt it says a lot about their drive and passion. If anything if I wanted to find talented devs I would put some more esoteric languages on the requirements lists even if we wouldn't use those languages internally. It's a pretty effective filter.
So where do they gain that passion if not from developing off hours?
If you look at the leveling or hiring guidelines for any major tech company, what separates “senior developers” and up from mid level developers are system design, “handling ambiguity”, leadership, “scope”, “impact” and in the case of Google did you write a messaging app.
Even the largest tech companies realize “coding ability” only gets you so far and most developers who want to get ahead would be far better off focusing on the other aspects of software engineering.
System design, handling ambiguity, scope and impact are all things that are taught extremely well by just coding a lot. I'm not even sure why you are arguing. Someone who does something more and likes doing it in general will be better at it then someone who spends less time on it and doesn't like it.
So how do you learn “system design” - infrastructure, proper data storage for the problem domain, balancing the trade offs between costs, RPO and RTO, security, caching, sharding to handle scale, scaling, disaster recovery or the stereotypical “how would you design Twitter” System Design tech interview.
Coding has little to do with handling ambiguity.
While I have never been through a BigTech coding interview, I have been through (and passed) a BigTech system design interview, it has little to do with coding.
Designing (and redesigning) systems for large organizations is my $DayJob where I have to be able to explain those concepts.
> However, if you're actually a talented engineer these languages will hamstring you and your art.
Early in my career I thought of software as art. I was wrong.
The very last thing I want in any production software team is an artist looking to express themselves. I want the worlds most talented engineers who want to use consistent proven methods to create solid maintainable code with zero surprises.
Code as art has its place, granted, but that place is in the privacy of your own time in a repository with one single contributor. I occasionally still go back to writing lisp for fun, but it has no place in production.
Perhaps it's just a generalization, but I don't think there's such a clear separation between "code as art" and "code as engineering".
The very best engineers are like artists, in that they harness their creativity to solve problems efficiently and effectively, often in innovative and personal ways.
And artists who are respected in the field of software can use consistent methods to produce solid maintainable code. I wouldn't say "zero surprises" though, I'm often surprised by reading the code of an artist, how they achieve extraordinary results with mundane code that a child can understand.
The example that comes to mind is Fabrice Bellard. He's one of the most talented engineers - and I'm sure many of us would agree that his software is a work of art.
Well, as someone who has to manage a team, I completely agree that what's needed are engineers who can consistently produce predictable results. We don't want someone who chooses (or worse, creates!) an esoteric language to pursue their art. But I myself am of the latter persuasion, "writing lisp for fun". And having a team of only non-artistic engineers would be so boring. But then again, boring is what we need most of the time.
> The very best engineers are like artists, in that they harness their creativity to solve problems efficiently and effectively
As a reformed former dev lead, I wanted a consistent industry standard idiomatic method of writing code and I used a combination of static analysis tools and code reviews to establish a culture to do just that.
I don’t want my C# developers who came from Java writing an AbstractFactoryFacadeBeanProxyDecaratorSingleton.
“Fun” for me is doing anything except being in front of a computer after hours. Between time with my wife, exercise, learning Spanish and just vegging out, computers are the last thing on my mind. I don’t even have a personal computer anymore.
> Code as art has its place, granted, but that place is in the privacy of your own time in a repository with one single contributor. I occasionally still go back to writing lisp for fun, but it has no place in production.
> Every programmer occasionally, when nobody’s home, turns off the lights, pours a glass of scotch, puts on some light German electronica, and opens up a file on their computer. It’s a different file for every programmer. Sometimes they wrote it, sometimes they found it and knew they had to save it. They read over the lines, and weep at their beauty, then the tears turn bitter as they remember the rest of the files and the inevitable collapse of all that is good and true in the world.
> This file is Good Code. It has sensible and consistent names for functions and variables. It’s concise. It doesn’t do anything obviously stupid. It has never had to live in the wild, or answer to a sales team. It does exactly one, mundane, specific thing, and it does it well. It was written by a single person, and never touched by another. It reads like poetry written by someone over thirty.
> Every programmer starts out writing some perfect little snowflake like this. Then they’re told on Friday they need to have six hundred snowflakes written by Tuesday, so they cheat a bit here and there and maybe copy a few snowflakes and try to stick them together or they have to ask a coworker to work on one who melts it and then all the programmers’ snowflakes get dumped together in some inscrutable shape and somebody leans a Picasso on it because nobody wants to see the cat urine soaking into all your broken snowflakes melting in the light of day. Next week, everybody shovels more snow on it to keep the Picasso from falling over.
I would like to see any form of objective evidence for “if you're actually a talented engineer these languages will hamstring you and your art”.
Even in C that lacks any form of sane abstraction capabilities, people have come up with object systems and what not if they fit a problem domain better. While I think that the language optimum is well past C, there is no significant difference between modern managed languages in any way besides ecosystems — and that is the most important thing.
> C#/Java JavaScript/React developer to push out some CRUD SaaS app or line of business app?
Because of this: "The Python Paradox" [1].
Replace Python (which has become mainstream in the meantime) with any other "weird" language from the article and I think the point still stands.
If it matters I had started learning Python just about when this article was being written/published, and in my early to mid-career that advice of using a "weird" language (Python, at the time) was really good for me, got me into a couple of small companies where I really enjoyed working.
Granted, now I'm already over 40 years of age with a mortgage to pay, I'm a little more flexible when it comes to the technologies being used (even though I would cry myself to work in the early hours of morning were I to use Java, and I'm not kidding), but for people who are quite early in their careers letting them explore and use those "weird" languages will still do them a lot of good in terms of them enjoying their programming work, they might even land on a forum written in Arc.
People early in their career are the last ones that should do anything in obscure languages. Most of the time the biggest leap in salary comes in your first few years. Once you break the can’t get a job <-> don’t have experience cycle, you need to be able to jump ship.
When I first started in my career over two and a half decades ago, my focus was on being able to be aligned with the market and being able to support myself. I was young, single, had no responsibilities and just moved to a major city. The last thing I considered “fun” was programming.
Yes, you leave money on the table if you do that (I know I did, I have friends the same age as me who earn a lot more than I do because they went the non-obscure language path early in their career), but at the same time you also bring some purpose into your professional life, which cannot be entirely bought with money.
Or maybe I was the weak one when I didn't see myself programming in something like Java for a living for my entire career (30 to 40 years), again, that would have literally caused me to cry before going to work, in which case, yes, those persons that can surpass that type of feeling should definitely go for the "more money/less interesting programming stuff" route.
Well, I restarted my career in 2008 after staying at my second job for 9 years and becoming an “expert beginner” - I was doing VB6 (discontinued in 2001) and C++/MFC (Windows). After the struggle I had finding another job when I was ready to leave, I said never again. I completely concentrated on technologies that were marketable.
By 2016, I knew I didn’t want to be “just a developer”. I enjoyed working with customers, leading projects, mentoring and teaching. But I still wanted to stay hands on
I belatedly discovered “the cloud” and realized I wanted to specialize in true “Devops” bringing developers and operations together and working with companies to show their developers how to be “cloud native” (application modernization)
When $BigTech came calling about a pure software engineer position, I really wasn’t interested. I kept talking to the recruiter and she told me about a cloud consulting position where I would be able to be involved in the full life cycle from pre-sales, to delivering a finished product including infrastructure. I jumped at the chance.
> This doesn't mean we should prefer "new safe technologies", it means our recruiting should far more stringent and our education far more formal (as in an actual useful programming degree).
I think the ironic thing here is that these "approved" languages are both less safe and less expressive. Statically typed functional languages like Haskell and OCaml allow much more correct code and reject much more wrong code compared to something like Java or Go. I'd even go as far as to argue that in some ways, Haskell is more expressive than the mainstream dynamic languages (Ruby, Python, JS etc).
Now, if your developers are really "idiots" (which to me is a very condescending thing to assume, but that's a different story...), then maybe they won't even be able to get their code to type check in the first place and ship no code at all :)
> Statically typed functional languages like Haskell and OCaml allow much more correct code and reject much more wrong code
In functional code, sure. In a predominantly mutable algorithm, you fight the language more than what you gain, and sometimes, yes, the mutable approach is simpler and easier to reason about. Especially local mutability can be very readable/maintainable.
I'm surprised to see Kotlin in your list. Google has stated they are increasingly moving Android development to a Kotlin-first ideology. New official libraries produced by Google for Android are designed with Kotlin chiefly in mind, so it may provide significant benefits to support, community, and documentation.
Considering the popularity of the Android platform and Google's control over it, I don't think it is a bad idea to develop an Android app in Kotlin. According to Google, their Maps, Home, Play, Drive, and Messages apps are all built in Kotlin, and my personal experience is that Android developers like and prefer Kotlin.
Very well. Google deciding to back it for Android wasn't some bold, out there decision. Android developers could already use kotlin, because of its Java interop. Google was just responding to pre-existing demand that the community was already generating.
That's why I don't think it makes much sense to treat kotlin in the same category as the other languages. Sure, it's a programming language, but the way JetBrains executed on it with its easy upgrade path from java and really excellent design, not to mention the toolchain, mean that it's success and trajectory cannot easily be generalized to other "weird languages".
Also compiled languages have longer staying power because if you move on from the language, you can still make use of the binaries but simply never write it again. Look at all the Fortran libs that are still in use by other languages...
They don't distinguish between managed environments/multilingual platforms (JVM, .NET, wasm) and single pony shows. Which makes it harder to see how related Scala/Kotlin/Java are and how much they overlap ecosystem-wise.
> and my personal experience is that Android developers like and prefer Kotlin
That is because the other option is a deliberately crippled Java from a decade ago. Also, while apps are indeed mostly written in Kotlin for android, I am fairly sure most of Google’s listed apps have a Java shared library that does the core of the functionality that is shared between backend, android, web frontend (j2cl) and ios (j2objc).
Also, don’t forget that android development is a niche, on the web backend side Java is just an incomparable bigger player.
Absurd opinion for an absurd time. Local optimas and stagnation is not how we solve the systemic problems on the internet and in the world.
Sure if your value add is content then go ahead and use mature tools within the paradigm, but if you want to cause a so called "paradigm shift" then you'll need to understand where the progress is happening and what kinds of opportunities it creates.
Ocaml for example is looking more and more enticing. Standard meta language is used by academics and programming language theory is developed in it. Meaning that it has a good long term trajectory (along with lisps I suppose).
Of course we are about to grow out of syntax, soon it'll just be another config param in your editor.. but I don't think these "obvious choices" you list will all be as well positioned w.r.t. that change.
Right now it may be harder to agree with me than with you, but that makes me think of a hn thread I was reading recently where people didn't want to admit to being programmers (in public / to strangers) because the perception is starting to be that what we do is immoral. Sufficient mastery of programming will make it a boring thing that everyone knows how to do but lowering the bar to that point won't happen within the web paradigm we currently inhabit. We'll see if wasm brings us closer but I think it will take more than that.
Anyway, I'd say your advice is good but not great. A CTO should be able to assess which tools fit the problem they have for the timescales they're considering. If they're swayed by your comment (or mine for that matter) then they're not fit for the role. The person you are actually talking to is someone who is building a company that suffers tech while the core business is something else or a company that is meant to be sold to some giant.
> but if you want to cause a so called "paradigm shift" then you'll need to understand where the progress is happening and what kinds of opportunities it creates.
This is the most Hacker News thing I read all year. What are you talking about? Where did he say anything about wanting to cause a paradigm shift?
And I remember when Python, React, Node were all fringe. Until they disrupted the industry. But the important take away is to choose for a specific reason, and expecting a traction in the future. While OCaml might be good for a research project, it is unrealistic it gives you some future advantage. On the other hand, you can see how Rust can give you an advantage right now for some cases. Or even arguable rescript.
Typically, you should not attempt multiple paradigm shifts simultaneously. In fact, I would argue, the more innovative your end user product is, the more boring your tech stack should be.
Facebook was PHP.
Google was C++.
Bitcoin was C++.
Netflix was Java.
Spend your innovation points on your product, not on programming language.
Google is mostly Java and C++, Go has more use outside than on internal projects.
Nokia Networks customers were using a mix of C++ and Perl running on HP-UX back in 2004, and nowadays it is mostly C++ and Java running on Linux distributions. Not every telco is using Siemens Erlang based switches.
Apple created Clascal and Object Pascal, migrated to C++, got Objective C via NeXT acquisition, which previously licensed it from StepStone. They also created Mac Lisp, Hypercard, Dylan and Newtonscript.
Microsoft used BASIC for a looong time, dabbled with Pascal, had one of the best macro assemblers in the market, was the last MS-DOS vendor to actually add C++ support to their C compiler, focused on VB and C++ until .NET came to be.
I agree that the comment you replied to is most accurate for a business that doesn't have tech as a core product, but how many companies can realistically exist just to serve other tech companies? It's a simple fact that there are necessarily far more companies producing some specific product than companies making tools for companies making products
What systemic problems are there that have anything to do with the tech stack? Stuff is fast, featureful, and incredibly secure considering the attack surface is basically everything every person does. The content and applications are the main issues, the tech behind it all is pretty great and getting even better now that industry is finally learning to not tolerate unsafe languages and tools.
I've never in my life done anything that I feel standard languages aren't a good fit for.
I do think Dart deserves full best practices status, because the tooling and ecosystem around it is fantastic, and because it doesn't have a bunch of "Outside the paradigm" stuff, it's all things you can learn in a week coming from Py/JS/etc.
I've seen almost no horrific slowness aside from program switching on spinning disks recently. Stuff is pretty fast now, and that mostly useless premature optimization quote is out of fashion so it might even get faster.
I'm not exactly sure what the slowness people talk about is. Even the most bloated of websites are fast.
The one thing that still is an issue is Android load times. It gets a little excited about killing background apps on my phone and will take 10 seconds to open my notetaking app again.
a hn thread I was reading recently where people didn't want to admit to being programmers (in public / to strangers) because the perception is starting to be that what we do is immoral
any chance you could find and link to that thread?
I’d probably footnote out Kotlin as preferable for greenfield projects over Java. Maybe F# as well (and all CLI languages, by extension) since intermixing them as needed in a solution is largely effortless. Otherwise, I fully agree with your comment.
It's funny to see something like react on the list of frameworks to use.
When I started the main project I am still maintaining, react wasn't even around yet. It started only 9 years ago, which might seem like a long time to some younger folks, but feels like yesterday to me.
Are you suggesting that languages and frameworks are 'solved' now? That we won't get a new react that changes the ecosystem? How will a new language or framework that makes things easier ever come about if everyone follows your advice?
Frameworks aren't "solved", but React (for example) is big enough that pretty much all common problems have already been solved and can be easily found with a search engine.
Rails was the shit for the longest time, it was one of the first "magic" languages where you could just do stuff and MAGIC made it work.
It just somehow fell behind on the hype curve, mostly because Ruby itself wasn't used for anything else than Rails. Python took its spot in most general use cases.
Typescript, Golang, Rust are all relatively new. That means only a few years ago they were niche, no one used them. Rust still is niche. They could have died in popularity like the other languages you mentioned have, but they haven’t, it’s impossible to predict what will succeed and what will die.
If you only stay with what is popular nothing new becomes popular.l and you become mediocre.
Popular isn’t always the right choice. There’s the situation things are only popular because they are popular. React seems to fit that now, it’s the default as everyone else is using it even if there’s newer alternatives.
Innovation only happens by doing things different.
Choose what is appropriate, not what is popular or what is new.
Unless you want to leave an unmaintainable nugget of code for the future dev, you would use something that is actually in use and backed by someone relevant, not a shiny new thing.
The three you mentioned got over the hump by corporate backing. In particular Rust got in force thanks to Mozilla, golang to Google and TypeScript to Microsoft.
Big guys sometimes make an abject irrelevancy or failure (e.g. F# which didn't quite catch on, old stuff like Visual Basic) but usually at least the support and visibility is there.
All of the currently-popular technologies you mentioned were new and immature at one time. The reason we have better languages and tools now than we did 30 years ago is because people are willing to adopt them.
If the attitude you're encouraging were followed, these would all have been relegated to unsuccessful research projects and we'd all still be programming in assembly language.
I think that most of the useful work is done by the few, the proud, the nutjobs, who aren't going to listen to this advice anyway. You (for a given value of you) don't need to build a product in Elixir, they (for a given value of they) will, and if they stick with it for long enough everyone else can catch wind and begrudgingly add it to the pile. It's the circle of life!
I mean, I don't follow that advice at all, and if you don't want to you shouldn't either, but there's definitely a fair argument that it would be "better" for most cases to accomplish your goal with boring technology.
The field was changing a lot quicker thirty years ago than it does today and the technology was much less mature. It's natural to become more conservative with technology choices over time.
And what's interesting about most of the popular languages is that they additionally ignored the state of the art even at the time of their creation, much less throughout their development. It's crazy that things like ML and Scheme were around since the 70s and Erlang since the 80s and Smalltalk since the 80s but basically nothing that made these languages excel at building systems can be found in Java, Python, JavaScript, C++, etc.
It's weird to me that it's the stubborn languages that seem to make it through.
Java was originally planned as a “wolf in sheep clothes”, bringing the best ideas of lisp and smalltalk (GC, memory safety, dynamic linking), and selling it to C++ devs. While these were not new per se, they were new to “the average developer”. And I would even go as far to claim that GC is perhaps the biggest productivity/safety boost our industry has seen, single handedly.
And they continue to introduce new ML features in the form of pattern matching, ADT, etc.
I think sometimes these languages get unfairly evaluated.
It can be really, really frustrating to work with people and companies with this opinion. I have seen quite a few projects either fail or nearly fail or being slower or less reliable than they should because of the choice to use something like Python, where it was basically the wrong choice from nearly every perspective other than it being what people have heard of.
I'm perfectly happy letting other people work in the middle of the bell curve, but I cry a little inside when I see a super cool application be ruined by highly conservative software thinking. I have never been able to understand that, usually hardware-oriented, companies will be doing something super advanced and novel with physics, engineering, biology, and other "hardware" related things, but then will bury their heads in the sand unless the most common denominator programming language is used because they supposedly can't hire people otherwise. But yet they're perfectly willing to hire and train people on the novel hardware designs. It doesn't add up.
There is a very strange uncomfortability with software ideas that are new to people that I do not see when it comes to even the most novel and cutting-edge hardware-related topics. I have experienced this in internal talks, where hardware-related talks will generate a huge amount of buzz and questions, despite often being well beyond the audience, and the software-oriented talks seem to attract crickets. Honestly, I think it's a bit of hidden hubris, in that many scientists and engineers consider themselves to understand software, and in showing interest in new software-related things, they fear showcasing that they don't know something they fancy themselves as knowing. The other possible answer is that people are just afraid of software in some sense.
I found this in a recent interview where it seemed to be expected to solve a problem using objects and either interfaces or inheritance. I solved the problem with discriminated unions and pattern matching, and there seemed to be some uncomfortability with the solution because it wasn't what they were used to as being the "right answer", when in reality it was just another spot in the solution space of the expression problem.
> I have seen quite a few programs either fail or nearly fail because of the choice to use something like Python
I'm not surprised, it is very difficult to scale Python to larger teams and projects. I mean people have done it to some degree, but at what cost?
It's much better to stick with a static language like Java or C#. You mentioned pattern matching and discriminated unions at the end of your post, which Java has recently gained, and C# to an extent as well.
The projects I have in mind actually struggled even with small teams. Python is not good for anything besides scripting and small programs, what it was originally intended for.
Granted, I earn my money writing Python code among other things, but surely there have been a few successful Python projects in the past that were more than scripting and small programs.
This might also applies to code. I have always think that I write simple, readable code but I wonder how much of that is just familiarity to my code style. I typically don't have problem understanding code that I wrote months a go though
That’s a great paraphrase of a sentiment that I have also tried communicating to people. I have tried convincing people that just because something is lesser used doesn’t mean that it isn’t more simple.
In general, people are afraid of simplicity. When you show them a technique or programming language or method or perspective or whatever that is new to them but also simplified the problem, people are inherently bothered that it isn’t as complex as they’re used to, which convinces them that it isn’t a valid solution.
If the only thing that's familiar is Python, then yeah, this approach doesn't scale well.
But mainstream languages also include C++, C#, Go and many others. It's a good thing to have several different tools in your toolbox, but a few tools can cover pretty much any scenario outside of really extreme corner cases (where something like e.g. Prolog might be of use).
> There's any number of companies saddled with their main systems being built in the weird assed framework that the fourth-to-last CTO decided was a good idea, and those companies are now stuck with the problem.
I'm going with this as the problem statement, and it is a problem, but I submit that being saddled with a technology is a cultural problem, not a technical one. Related: Conway's Law Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure.
> If you are the person deciding which technologies to use, you should probably be using the most mainstream thing you can, not the coolest newest thing that you read on Hacker News.
This solution does not address the problem statement, and so will sometimes be a good answer, but only by accident, and makes the same mistake as choosing "the coolest new thing on Hacker News". Choosing a technology to address a specific challenge is not always easy or obvious, but takes thought, humility, consideration, familiarity with the options, probably even a team decision. A manager that just top-down decides for the engineers is doing it wrong, whatever they choose.
A very mature, non-weird (i.e. C-style syntax) and popular language can make it easier to recruit many developers but it is what will make that necessary in the first place.
A language of a somewhat more sophisticated design can make it harder to find developers but let you need much less.
E.g. Scala (which, contrary to the myth, has great learning curve and readability as long as you don't insist on making heavy use of the really weird parts - they are entirely optional) vs Java can easily boost productivity 10 times. Scala code usually is less verbose and works perfectly once built successfully - ~99% errors are detected at compile time. I know numerous Java devs who have switched to Scala to solo-dev efficiently, because they have no time to code and debug Java. Kotlin was designed based on the Scala experience to make it even better.
Okay, maybe 7x, that's subjective, imprecise and strongly dependent on how experienced you are in Java. For a skillful Java developer that may be as low as 3x.
You honestly believe that you would finish, let’s say a CLI time manage like timewarrior in Scala even 3 times as fast as someone remotely decent in Java?
While I share a similar opinion, the languages to be picked for a project should the official languages of a specific platform, meaning "Pick platform X", "X allows X, Y and Z languages on their official SDK/tooling", "X, Y and Z get the price of chosen languages for the project".
However I also think, that time should be spent in non-mainstream languages to learn new programming concepts, and eventually future version of "X, Y and Z" might even get those concepts and thus one is better prepared to apply them.
I wouldn't lump Kotlin in with some of the other less-popular there, if a place is already all-in on Java then Kotlin is a natural next step and can be adopted incrementally with 0 technical issues.
If it's an issue with existing devs refusing to skill up, they can just write their ancient antiquated Java until they retire, it'll still work just fine alongside the new Kotlin code. But in my experience it's rare that even the most institutuonalised Java dev doesn't appreciate the nullability support at least.
> Apart from anything, you should be using these most popular technologies if only for the sake of recruiting.
There's actually a tricky tradeoff here. Many startups working on hard problems can benefit from making one weird technology choice, if it offers them some kind of significant leverage on a previously difficult technical problem.
But when it comes to recruiting, it can actually be an advantage to be using a slightly obscure language. Often, these languages have communities of very skilled early adopters who wish they could use their favorite language at their day job. And especially if your company has a strong remote culture, this may make it possible to hire some extremely talented people.
I do agree that, on average, a company's overall tech choices should be mostly boring. But knowing when a lesser-known tool will offer a big advantage is an art, and it can pay off.
FFS if I read yet another article bringing up cats vs scalaz as relevant to Scala today, I'm gonna keep my cool and ignore it with prejudice, just like I did this one.
If you have so little awareness of the Scala ecosystem that you don't realize how laughable such a remark is in 2022, yet allow yourself to have such a strong opinion on the language, I have less than zero interest in the rest of your opinions about "weird languages".
I feel like you're the kind of commenter the author is advising against taking advice from. Someone learning Scala presumably cares much less about gaining "awareness of the Scala ecosystem" than writing their first Scala program.
I don't know Scala though, so perhaps your argument would make more sense to me if you explained why they were so wrong.
scalaz is irrelevant to scala in 2022, cats won almost everyone over a long time ago. The author is basically raising a giant "I haven't touched Scala in years (or ever)" flag by bringing up that choice. Then proceeds to summarily dismiss Scala as "a mess". Right.
I'm tired of people who never really used Scala or haven't used it in years casually shitting on it like it's a cool thing to do. Like "Scala is a mess" is something self-obvious that doesn't even need any explanation / justification.
And Scala aside, it's pretty amazing that a blog post that can be summarized as "be a normie, being weird is expensive" is at the top of Hacker News. Such hackers we are.
> I'm gonna keep my cool and ignore it with prejudice, just like I did this one.
Just gonna point out you didn't keep your cool and ignore it.
Keeping your cool: good!
Ignoring it: no way!
You obviously have a lot of passion for the topic, and may have rightly identified a flaw in the author's blog post. You can use that passion - and keeping your cool - to correct the record.
e.g. I dunno OP is wrong and Scala is not a mess, it is awesome! That culture war was resolved in favor of cats years ago, and here's why...
I'm about to embark on my master's thesis, in a domain[1] which could realllllly use the "attach to running process; re-evaluate code and have the system just keep going" aspect of Lisp languages.
I know Python best. But I have reached my breaking point with its syntax, and its lack of binding constructs, and lack of symbol datatype, quote, etc. I am intending to use Clojure ... but I have to ship this thing by May 2023 come hell or high water.
All else being equal, I will proooobably be able to go further with Python. But I'm concerned it will hamstring me from doing the crucial feature of "extending the design [ie code] of a game as it runs" since, AFAIK, it's difficult to get a Lisp-ish experience of total live reloadability in Python... jurigged[2] and reloading[3] not withstanding.
I know some common lisp so I'm not a total lisp noob. I've learned enough CLJ to be dangerous ... but I'm worried I'm backing myself into an endless hole by using a language I'm not yet master of. Yet, I think the features of the ecosystem (total live reloadability of a CLJ/CLJS app! with current state preserved even down to what a user has typed in the HTML UI!) are so tempting...
Just venting out loud. comment/contact if you have suggestios or are curious about the project; i'm soon to begin blogging as I develop it.
If you don't mind being stuck on Windows you could use Visual C# or Visual Basic, they have edit-and-continue too. https://learn.microsoft.com/en-us/visualstudio/debugger/edit... I've worked with the SuperTux C# level editor in the past. C# was actually pretty nice for GUI stuff.
There doesn't seem to be a good GUI framework for Clojure. There was Seesaw but it hasn't been updated since 2019 (no maintainer). There is a guy developing a new framework https://github.com/HumbleUI/HumbleUI/ but it's WIP. I guess you could sidestep this by making it a webapp and using figwheel + web framework of choice.
My project will definitely be a web app -- I'm most familiar with web dev, plus I'd much rather be able to point someone at a URL and say "here's the thing try it out" and have that happen in 5 seconds instead of dancing the installation mambo.
Thanks for the pointer to figwheel -- that looks like hot stuff and just what I need for end to end server/client interactive dev!
Lua shines at precisely two things. Being well embeddable and glueing libraries together thanks to that feature.
This makes it one of the languages of choice for auxiliary scripting a big system, like a game or an application. (The other common choice is Python, and nowadays also JavaScript.)
sounds really neat, i would try using a lisp that is closer to the metal though, something like microlisp or, my favorite: janet
coupling clojure with python sounds like a drag, even using graal i dont think this will be easy. but janet you could bind as a dll and eat your cake while having it as just recently FFI was added. if you are interested, i can probably help a little as im working on an integrated (game)development repl myself. not sure how to classify what im working on but i think its close to your domain as i want to change my hotloop during runtime from the repl and from inside the running game. i just wrote you an email.
EDIT:
ah, just now read that you want to make this a webapp, in that case being closer to the metal isnt really helping, so nevermind ^^
Also, for anyone interested, Casey Muratori implemented such a system (though very simple) on C for his Handmade Hero game. It works by reloading a dynamically linked module on every frame. It's a model that should be adaptable to any compiled language.
This all comes to something that only you can answer:
>but I have to ship this thing by May 2023 come hell or high water.
Do you feel that you have to start working today in order to meet the deadline, or you can put a couple of weeks aside to develop your skill in whichever other language you'd like would be more adequate.
I would urge you to go ahead and use Clojure here.
A big part of the value proposition is access to the entire JVM and JavaScript ecosystems. Bindings will be available for the more popular libraries, and if there aren't, well, Clojure is designed to make that easy.
It might not be pretty, it might not be idiomatic, but you're never going to hit a wall where "oh, if only I was using a popular language, I'd be able to do $obscure-thing". $obscure-thing is available for the JVM.
It taught me way more about sales and adoption than anything else.
As a former Erlang developer it never ceases to amaze me that an entire language, standard library, toolchain, and runtime that's entirely dedicated to and on-paper perfectly technically suited for the most pervasive "backend" development challenges of our time somehow managed to effectively blow a 20-year technological headstart and failed to leverage the notoriety that should have come from several super high-profile "trendy" commercial use cases in the 2006-2013'ish era. Such that it's still relegated to general obscurity and is seeing its core competencies taken over by a hodgepodge of other languages and technologies that started much later but became rapidly more popular while also still arguably doing a worse job at those things than Erlang did.
Erlang could be the literal silver bullet and people wouldn't use it because it's a funny looking language.
I showed it to all my developer friends back around 2008 (I found out about it because a competitor used it and open sourced some of their stuff) and the only comments I ever got was how weird it looked. No one gave a shit about anything else. The story it told me wasn't about sales, it was about how shallow most developers are.
Once nodejs came out it was the final nail in the coffin - callback hell solves all your problems, no funny looking language necessary!
As nice as the beam might be, erlang is just not a great language by the judgment of many people, including me. Elixir can't make up for it either. I refuse to use a dynamically typed language for anything bigger than a couple hundred lines.
On the JVM you have languages like Clojure and Scala, which both are top class in their domains imho. I wish there was the same for the beam.
There is the ever going war between dynamically vs statically typed. I can only conclude that this comes down to personal preference, but maybe also a bit experience (since I would prefer to work with Clojure over Java even for a big project any day).
I simply like to put in a lot of focus during certain times to make the compiler understand what I'm trying to do and then go to "autopilot" later and have the compiler tell me exactly all the places I have to change (and often how) when I implement something new or fix a bug.
I think it's mostly trading some problems for others. I work mostly with static typing but prefer dynamic typing, and I don't feel that static typing offers much benefit for most programs I work on.
I actually really enjoy the assertive style of Elixir/Erlang. I think that while they are dynamically typed languages, the assertive style rests somewhere between dynamic and static typing, and in fact offers some safety benefits over your average statically typed language: while you don't get it at compile time, this idiomatic code offers benefits at runtime that most people don't bother with in other languages.
> I don't feel that static typing offers much benefit for most programs I work on.
Maybe for example you have a good memory and I don't (I certainly don't). I forget things so quickly that it's always a huge hassle for me to be productive when I have to use e.g. python. That's just one example, there are surely other different traits of people that make them prefer one over the other.
Another one is that I really hate to write documentation and tests, except for very highlevel ones (UATs and high level documentation). The reason is that it gets outdated quickly and I don't like to keep it aligned. With types, they are automatically always aligned (the compiler forces me to) and it's easy to do so because there's lots of tooling for refactoring types.
Maybe other people actually like that part of the job and hence don't feel that a typesystem is helping them much.
Rust is not particularly funny. It is C and C++ with some SML syntax.
The one innovation in it is the borrow checker - making it somewhat dependent on the quality of the compiler and adding a bit of noise to syntax for exchange in predictability of the code - and the cargo packaging system, unusual for a statically typed fully compiled language.
Funny thing, Elm is one of my favourite languages. You get the compile-time guarantees of Haskell without the necessity to understand higher kinded types and other complicated things. Elm is a very simple and effortless language.
I've worked on a commercial project owing much success to Elm. And another commercial project in Elm with no problems. And completed and/or launched a few side projects in Elm. Elm is great for many people.
> I'm the last person on Earth to tell someone to be patient, but if you actually want to ship a company's production code in Gleam or Crystal, I highly suggest you put up 2-4 small projects first
As someone who has used Nim in-anger and production at a couple companies now (and am currently using it to build our firmware for our industrial IoT sensor platform), I can wholeheartedly agree with this.
The first couple things I built in it at previous positions were small internal tools. They went well, team members contributed to them as well, things were good. It was that, plus the unique constraints of this firmware project that allowed us to have the confidence that it would work well -- and it has.
Of course, Nim is sort of cheating, as it being able to be compiled-to-C-sources means we have an out at any point we want, both in terms of being able to easily bind and use driver code from vendors, to wrapping up a Nim object file with a nice C header to call from some C/C++ code if need be.
Now: our backend is Java, and our front-end is Typescript and React. Pick your battles! If we were swinging for the fences with some other niche server side, and Elm or something (as much as I enjoy playing with it) for the client-side, as well as trying to use something non-standard for the firmware itself, I'm sure we would've failed immediately.
But we have our devices out in the wild in rural Papua New Guinea where no one's going to be flashing our boards for us, and they're working fantastically :)
Heh, C++ -> Scheme being the first journey to a weird language, I guess it's all a matter of POV. "Dragons aren't flying out of my nose anymore, what is this?"
There seems to be a weird version of the Efficient Market Hypothesis going on in the comments:
If niche lang is so much better, then why is no one using it?
Well, quality doesn't necessarily lead to popularity. I would encourage talented solo devs to seek work in niche languages, at least once in their career. You can deliver more value, work with interesting people and solve more interesting problems.
And what are the credentials you have for backing up this claim? Because to me it seems like the majority of those who deliver value would beg to differ. And a vocal minority is shouting "Stop wasting your time on programming languages". There are so many other easy ways to improving software quality.
The xkcd linked in the article had me laugh out loud. I hadn't known that one, it's great, and what it says about languages rings true.
> There are so many other easy ways to improving software quality.
Well, yes, there are. But picking the right language for the task is one easy way to improve software quality, so why discard it?
Also, for some issues and metrics, software quality is in fact limited in practice by the language used. Getting guarantees of certain properties is trivial in garbage-collected languages, near impossible in languages with manual memory management. Similarly, the lack buffer overruns and underruns, XSS exploits, properly following protocol, etc. are going to be trivial to guarantee in some languages, near impossible in others.
Now, I fully understand that following the hype wagon (or listening to fanbois singing praise about the latest tech, whether it's a language or anything else) is annoying. But let's not confuse hype and using the right tool. The intersection between those is often rather small :)
> Well, yes, there are. But picking the right language for the task is one easy way to improve software quality, so why discard it?
The language isn't all that important. The main problem is functional decisions that transcend the implementation language. It's not hugely important if I write this comment in English or French to get my point across, and that's why I'm writing it in English.
Beyond the random internet post (or the rare one, like "Beating the Averages", which might well be exaggerated) I haven't seen any obvious competitive advantages from choosing a non-mainstream language. On the contrary, what you often see is that immature ecosystems are huge timesinks because a lot of stuff simply isn't "there" yet.
That's not to say there aren't incremental improvements happening with new languages over time. But if your goal is to complete a project as opposed to evolving a language ecosystem I'd say that it's unwise to pick a non-mainstream language. Heck, I'm still using C for almost all of my projects (chances are I'd be using Java or C# if I was working in other domains). I've tried to switch - I have smaller and larger investments in a dozen languages. But no other language has stuck for me. A big reason for this inertia is that I simply know C well and I feel productive with it. But there are more objective qualities, some of which are related to it being mainstream and having a mature ecosystem. My language of choice has flaws, but they are well-known, with well-known workarounds. That lets me focus on the problem instead of the tools.
Blog posts generally don't consider these qualities because they can't be discussed with toy examples that show you how you can neatly turn an isolated problem from 10 lines of C code into a 2-line fancy language solution. The problem with these examples is that they are not representative of longer-term and larger-scale software development.
Even with my typical C rants, I absolutely support the idea of a project going with C if that is what it makes sense on the market they operate on.
The additional effort to add tooling and workflows that most of the teams aren't comfortable with, extra effort implementing integration layers, might slow down delivery to the point of diminishing returns, thus withdrawing any advantage.
So while I personally might not like it, in some scenarios that is exactly the tool to use.
Same applies to other domains and whatever language might be the "to go option" there.
> The language isn't all that important. The main problem is functional decisions that transcend the implementation language. It's not hugely important if I write this comment in English or French to get my point across, and that's why I'm writing it in English.
I think this is the root of the disagreement. For my domain at least, I find it very hard to write robust software in some languages and fairly routine in others.
Unfortunately the data on this topic is very limited - typically groups of college students implement something in various languages to compare. Hardly a realistic test.
What I can point to are code constructs that I cannot make in certain languages where the work arounds are either more verbose or less precise.
As I said I'd likely use a different language if working in a different domain (but then again I'm not).
But you will be hard pressed to find a serious domain where there aren't solid mainstream tech choices.
> What I can point to are code constructs that I cannot make in certain languages
This is what I was alluding to, these examples are not very relevant. In a larger-scale codebase the important thing is the structure that you build, not the structure you get for free (or are being imposed) by the language.
If you cannot say certain things easily, then write a function to factor the common stuff in a layer that you can then build upon. This is the basics of programming, and from what I've seen this is already where it fails in most real-world codebases.
Functions and records (structs) are sufficient to cover you in almost all real world situations. I believe that the step up from assembly to higher-level languages is a very powerful step, because it frees you from doing a repetitive task again and again, that you can't even realistically do better than the compiler (because of time constraints), at least not on a large scale. Another reason that the step works is that what it automizes are quite local issues to solve. Barring extreme optimization requirements, we can simply come up with a function call ABI and have the compiler solve all register allocation for us. The tradeoffs and ramifications of this are quite clear - we can be confident by now that there are no unknown tradeoffs that will come haunt us later when the project has grown much bigger.
The same step up will be hard to repeat, since functions and structs are so expressive already, it's rare to find a problem that can't be elegantly solved using them. Garbage collection is another big help automating the repetitive in some domains, but it gets in the way in other domains.
> The same step up will be hard to repeat, since functions and structs are so expressive already, it's rare to find a problem that can't be elegantly solved using them
One thing that's hard to express with them is a data type that's TypeA OR TypeB OR TypeC. For that you need Sum Types, which a lot of the newer generation of languages (Rust, Swift, Kotlin) have, but the older generation (Java, C#, C++) historically haven't had at all and still have poor support for.
I find this to be a significant productivity boost over languages that don't support this.
That's a good point. ADTs (algebraic data types) are certainly nice for certain classes of mathsy problems, compilers, and similar. As I'm moving more and more towards distributed systems work (as well as in-process messaging, queuing, and event handling) I'm still figuring out if I want ADTs things built in, or if enums + simple code are good enough to cover my needs.
One thing I don't particularly about ADTs is that they remove opportunities to tweak the representation, and make you think less about smarter ways of avoiding certain complexities caused by choice (Sum Types) in the first place. But I have to admit that very often I'm simply doing the "struct with a tag member and a union member" thing manually, which one gets for free by using standardized ADT syntax.
Yes sure - if it becomes a pattern, it makes sense as a language feature. Conversely, if it is a language feature there is the danger of it becoming a pattern without need.
> If you cannot say certain things easily, then write a function to factor the common stuff in a layer that you can then build upon. This is the basics of programming, and from what I've seen this is already where it fails in most real-world codebases.
This presupposes that the language even has facilities to enable appropriate abstractions! You can't argue that languages don't matter without reckoning with these real world matters. Yes, sure, I can just "abstract it away", yes, sure, "all languages are Turing complete so equivalent".... but no, that's not the whole story at all.
> The same step up will be hard to repeat, since functions and structs are so expressive already, it's rare to find a problem that can't be elegantly solved using them.
Maybe, sometimes, ... - in practice, I've often seen them pave the path to madness. When types become "expressive" the problem is that now you have to deal with 2 languages. An ok one and a soul suckingly bad one.
Well, we seem to agree that some languages are better suited for some domains. So I'm not entirely certain what we're disagreeing upon.
My thesis is that you need to pick the right language for the task and that language evolution regularly produces languages that are an order of magnitude better at some tasks than previous languages. To pick an extreme example, I doubt that you're going to code your next relational storage with pure C. You'll most likely use some SQL (or a competitor) somewhere in the stack.
And of course, as I believe we agree, the ecosystem matters a lot. In many, but not all, cases, it matters more than the language.
I think the biggest differentiator is ecosystem. If you don’t count that, then there really is no evidence of any significant difference between any two managed languages. There may be a bit more in systems programming, but that itself is a niche.
Ecosystem is a huge differentiator. But then, again, there are things for which some languages are infinitely better than some others.
As everything in development, it's a tradeoff. I have written system code in JavaScript (calling directly into libc or kernel32.dll methods) and I don't want to ever do it again. I have written compiler code in C++ and the code was orders of magnitude worse than it would have been in a functional programming language. I have written database code (the actual dbms, not using a database) in both OCaml and Rust and I'd really prefer using SQL (or some layer on top of it), rather than reinventing it.
> "I haven't seen any obvious competitive advantages from choosing a non-mainstream language."
Just look at the market cap of YC companies started over its first 10 years and group by initial back-end language choices.
It wasn't dominated by companies using Java, .Net and PHP. On the contrary, those using Ruby account for over 50% of the valuation. Those using Python (a far less popular language then than now) accounted for another 17%. PHP, JS, Java and .Net combined were at under 5%.
You are free to plow your field whichever way you like, of course. Just step back once in a while and check whether you've done enough plowing last month - or spent all your time upgrading your plowing technology.
In the end you just have to plow, and it doesn't matter all that much how you do it (as long as you use my preferred brand of course). Plowing tech isn't all there is to growing crop and vegetables. There is an awful lot more that you have to understand and plan and take care of, and upgrading your plowing tech won't help you with any of that.
The most productive people may program in mainstream languages like Java, but their programming is informed by exposure to a broader variety of languages than just the mainstream ones.
To stick with Java as the example, Java was designed with a set of affordances for managing mutability, complex inheritance relationships, and objects with rich behavior, and the coding norms and "wisdom" surrounding Java in the early years was based on that. Appreciation for immutability, value objects, and transformation rather than mutation came from outside of Java. That's my experience and the experience of the people I've worked with: our understanding of the value of immutability and dumb data came from working in languages that demanded or at least strongly suggested it and had elegant affordances for it. If we worked exclusively in Java, we would have been much less likely to realize the value of an approach that seemed alien and awkward in our language of choice. (Eventually, due to popular demand, better language support was tacked onto Java, but I'm talking about 10+ years ago.)
Every programmer should at least dabble in other languages and try to absorb the good big ideas from them, even if they ultimately put these ideas to work in "mainstream" languages.
Recently I'm considering building an information system for the company I work for and I believe it would ultimately look like an expert system.
This has naturally led me to prolog, but this is a very scary proposition for me to try and sell to the company though they have been very supportive.
It's a powerful tool but just so esoteric and I worry it'll be a pain to build a production grade system that can be worked on by someone other than myself.
Clojure has a core library enabling Prolog-like programming. Other languages have similar libraries but usually those are third party and less developed.
Actually I'm considering having host languages for the system as I'd like to keep the informational core as pure as possible with the host taking care of any imperative actions. At least that's my thoughts so far.
Though trying to introduce clojure, as much as I enjoy it, would just be adding to my social woes :).
More and more I think this idea has merit. When I was still deep in the go kool-aid it was always shocking to me how difficult it was for some folks to use the language. "It's so simple!", I would scream internally, but it's only simple if you can check a lot of your previous experience at the door. Whether you're coming from a language with a more powerful type system (e.g. any other language with a static type system), or something completely dynamic, learning go will include a lot of friction. Despite it being a simple language on paper. I think that's part of the reason that python devs seem to have such success with it, because python and go tend to be focused on getting shit done over elegance.
I tend to be more pragmatic. I advise people to check the availability of jobs in their area for a given language (or framework), the relative pay of these jobs, and choose what to specialize in based on that. Passion fades, but you’ll always need a job. Chasing fulfillment through work isn’t sustainable for most. Find meaning and purpose outside of work. Just my .02.
It's ok for you to optimize for money and employability. I'm not sure whether it's ok to tell other people to do so.
> Passion fades, but you’ll always need a job.
No and no.
The original post was about having fun with weird languages. If it were a post about windsurfing, would you advise people to check the availability/pay of jobs for programming languages/frameworks instead of going windsurfing?
I feel that. I had a look at compiled languages to replace/complement my usage of python. I wanted something simple (no manual gestion of memory, thanks) and easy to my eyes, but efficient, and if possible fresh but with a thriving community.
I looked at D, Crystal, Nim, Go, Rust, Haxe, Swift and Zig (and C/C++, even Pascal). The language I liked the most (by far) is Nim, but unfortunately the niche community makes it a no-go for using it at my job, and the lack of hype like Rust makes me pessimist about its future.
The second most interesting languages where Rust (but the borrow checker and the amount of ', |, <, > intimidate me) and go (but for a weird reason I'm not hooked by its syntax).
My conclusion was that where I work (not a dev company), I can't use nothing but java, python and javascript if I want my code to be sustainable, and that I will keep Nim or maybe Rust/Go as a low level hobby
Edit: as a funny note, during my exploration i stumbled upon array languages programming languages like K, and I'm convinced there are mainly a scheme to guarantee jobs for people using them
Typescript meets your requirements I believe, althought probably you are considering together with javascript. If not, it might be interesting to try it.
If you want to compile to a binary for ease of distribution, then you can do it with both TypeScript and Python (you just get an interpreter embedded in the binary), although in both cases you'll need to use a 3rd party tool to achieve this. If you want it for the performance then neither are good options, although JS/TS is significantly faster than Python.
In a similar boat right now. Really enjoy Nim -- and have the freedom to use any language I want at work -- but can't in good conscious develop tools in Nim that have to live beyond my time at the company without at least one other Nim user on the team or a global consensus that we should use Nim.
I'm trying to think back to when we all started moving from Perl to Python and it's been so long I can't even remember what that looked like and if it was senior developers driving that or just a subconscious decision and happened "magically".
I'm actually quite interested by the scientific ecosystem of Julia, and have the project to explore it more. But when I looked at it, there was no way to create binaries (or it was something like 100MB)
sheesh, you're right. They're working on it, and it's, uh, no worse than Python, but yeah I don't think it quite counts as a compiled language yet. Thanks for the heads up.
I'd give Go a chance. The syntax grows on you IMO and I think it fits what you want (easy on the eyes is arguable). If you like Python because of how productive it is, but you need performance or a compiled binary, I think Go fills that gap well.
You didn't say why you want to replace/complement Python, but should you want to build web backends, Go is the obvious choice. Decent performance, relative ease of use, good GC, rich standard lib for the task, large third-party support and here to stay.
Go is simple, but still decent for networking services. I don't get the "hype" per se either, but it's not a bad language really, and what it does do, it does pretty well. Local maximum, if that makes sense.
If you have access to Java you have a good language at your disposal already, and chances are you'll get away with Kotlin too.
I came to Java as my 6th or so language (small amounts of Basic, VB, C, Assembly and Javascript before) and while I absolutely didn't like it in school, once someone told me how it was supposed to be used (rely an a real IDE) it became much easier.
I still continued to dabble in other languages (mostly php and python), but these days no way I would go back to Python.
Great post. I see weird language projects beyond solo/hobby stage go in two directions. The first is the “beating the averages” approach where they double down on the weird to attract higher level programmers attracted by the chance to play in a preferred niche. The second is a gradual shift towards conventional languages as the problem of maintaining a codebase at scale with an ever changing team becomes a dominant challenge. As someone with an irrational attraction to the weird langs my heart is with the first group but if I was actually running a business I’m sure the second would seem very compelling.
The article describes strategies to help when developing in weird languages. But they're helpful ideas for other contexts, too. When working with external systems or unfamiliar configuration formats, the same forces are at play.
For instance, TFA suggests sitting down with a pot of coffee to read the language docs sequentially (they were written by a hermit). This is also a great way to try to familiarize yourself with a mystery system.
The author recommends paying attention to building your workflow, since you'll be figuring things out as you go and the cost of forgetting details is high. I've found the same to be the case when working on integrating unfamiliar systems: early investments in automation and testing pays dividends.
I love writing in weird languages. Besides thinking about programming in a different context, being forced to read the technical documentation, source code, or just having to figure it out happens more often when I can’t just copy an answer from stack overflow. I find the latter just too tempting and easy when programming in a mainstream language
322 comments
[ 2.3 ms ] story [ 293 ms ] threadhttps://github.com/uhub/awesome-erlang
https://github.com/sindresorhus/awesome
If it's actually something relatively high-level or language agnostic — which is when I would have to "understand what I'm trying to do" — chances are indeed higher that I'll find a solution in Python, than that I'd find a solution in OCaml, but the thing is, I don't really care what language I'll find it in, as long as I am able to read it. I just have to get the idea, then I'll write it in any language I can write.
One might respond that "well, not being able to copy-paste it is the all difference it makes", but, seriously, there might have been like 2 cases in my entire life (that's 15+ years of programming) when I just copy-pasted something from stackoverflow (I think I actually remember those cases — these were indeed very specific situations, some stupid language quirks, and workarounds for them really should've been implemented in the standard library; and TBH, I didn't even really care how they work, as long, as they work — these were not your typical programming problems). Otherwise, I just don't find it very applicable: there's always some difference between stackoverflow solution and what/how you want to do. So you read the code to get the idea, then you go and write it yourself.
Ok, there are also CSS problems, I copied styles plenty of times. But that's different. And I have to change colors and stuff in the end anyways.
You need a VERY good reason to use anything except TypeScript/C#/Java/Golang/Python/React/Vue/Postgres/MySQL/SQL server/Oracle. Perhaps Rust. These technologies are good enough to get almost anything done these days. There's exceptions of course for example games tend to written in C++ and embedded is often C.
Apart from anything, you should be using these most popular technologies if only for the sake of recruiting.
Using less popular technologies like Erlang/Dart/Kotlin/Ruby/Elixir/OCaml/F# or whatever weird new JavaScript React alternative thing got you interested lately is a bad idea not just for recruiting but for support and community and documentation.
If you are the person deciding which technologies to use, you should probably be using the most mainstream thing you can, not the coolest newest thing that you read on Hacker News. There's any number of companies saddled with their main systems being built in the weird assed framework that the fourth-to-last CTO decided was a good idea, and those companies are now stuck with the problem.
I should note of course that my comments refer to company/organisation development. For personal projects or fun or whatever you should do whatever the heck you enjoy.
I haven't had a problem finding Ruby devs, but I haven't had to hire in a couple of years.
It still seems pretty relevant and useful.
Not impossible to reverse but very hard, especially since Ruby only has once niche and has not been doing well there.
WhatsApp, Facebook Chat used Erlang, and Discord is still using Elixir… make of that what you will, I suppose.
And Ruby / Rails + your frontend of choice is still a ridiculously productive stack to bring up an app, and probably run it at any scale you’re likely to realistically hit (poster child being Shopify)… if you ever get to stage of “scaling problems”, you are at a stage where you’d be rearchitecting parts of your stack regardless of what your original implementation was in.
So in sum, choosing a particular language because of popularity, I think, is not particularly useful framing. I’d say, choose one because it either gives you joy to write in and maps to your thought process well, or because it has a particularly strong ecosystem for the subject matter. Life is too short to program every day in a language that you dislike just because you think it’s the “safe choice” :)
I also wonder how we can define popularity better. Does that mean industry acceptance, number of GitHub repositories, number of StackOverflow questions, number of libraries, developer satisfaction surveys, etc. If you choose different metrics here, different languages and frameworks will appear popular. Svelte for example seems to be on top of some developer satisfaction surveys, but React is still one of the number one choices for frontends. C is the industry standard for embedded, but developers often do not enjoy programming in it.
Yeah, there is always a balance to strike and a multitude of factors that might lean the decision this way or that…
And even in something like embedded it seems like there is movement, I have seen some posts about people using Zig or Rust or Nim for embedded programming for example.
Additionally the standard request model of PHP (like with PHP-FPM) is a fast, efficient, and easy to learn model of request for new developers. Easily scalable new processes that are cleared at the end of the request. It seems like this is something people try to emulate with the “server less” model but PHP was built for this and is quite efficient at it.
And it's not even true that Haskell cannot be on that list for any sane human. Admittedly, it's not on MY list, but that's just me. Popularity isn't the end of things, nor is it set in stone. Agda or TLA+ aren't very common, but neither are problems they are meant to solve. Neither is Verilog, but it's not even an alternative to anything popular. And Ruby wasn't popular before Rails. Then it was, then it wasn't again. I thought that I was done with Java, but then Android became a thing. I guess you get the point.
…I think I'd like if there was only 1 language for everything, but I don't think it's even remotely possible, because then there would be different dialects of that EsperantoPL, different frameworks or ways to use it, and people would never agree on 1 thing anyway.
All the world is not a web app...
Yeah, like for instance: nobody knows or wants to know PHP.
On the other hand, if the task at hand requires a novel approach and using tools that are less frequently used, then that will also be justifiable. Are you developing something that only makes sense to run on the BEAM virtual machine? Go ahead and work with Erlang or Elixir.
Now a third category is programming for enjoyment. In that case you don't work with the constraints of profitability, and you can just have fun. And don't worry too much about Beating the Averages (http://www.paulgraham.com/avg.html)
And with regards to employee retention, I would rather bet big on benefits (paid time off, parental leave, etc.), reasonable working hours (4 days per week), achievable goals, great communication, democracy and good team cohesion. I have a feeling this works for a lot of people. If a language is the only thing that makes you stay, by all means find a place that truly makes you happy in that regard. All I am saying is that there are a lot more variables to worker satisfaction.
Those are important factors also. But I would prefer to work 5 days per week and enjoy my work rather than working 4 days and not enjoying it because the PL sucks. Just my 2 cents.
Yeah, I would like to see a source on that.
It's getting ever harder to find good PHP developers.
PHP will be around forever, but it's getting less popular.
I'd wager that most of the remaining PHP sites are wikis and legacy applications that are too painful to port.
1. https://kinsta.com/php-market-share/
How are you getting that number? From the link you referenced, the percentages are Wordpress: 40%, Joomla: 2.6%, Drupal: 1.7%
The article even concludes with: "PHP is far from dead, no matter what any disgruntled developer may tell you. After all, 79.2% of all websites in the world can’t all be wrong, and most importantly, PHP’s market share has remained relatively steady throughout the last five years (oscillating between 78–80%). Few programming languages command that type of staying power."
PHP powers a lot of legacy code bases, yes. But there are also a lot of job opportunities in Laravel and Symfony which are both very good frameworks.
As the article indicates, there's no SO or Google to find solutions easily... You need to read the docs or find some dark corner of the web for help you require. It highlights passion and genuine interest in understanding what you're doing and figuring things out yourself. Whereas your languages are financially job driven... Not curiousity driven; and my issue with that is if you can learn the esoteric languages, the mainstream languages are laughably easy.
I also love weird (/old) languages as the community that exists, however small, are asking 400-level questions amongst each other and not CS-101 topics. There's a nice serenity in not having polluted search results of utter basics.
My favorite programming language is an amazon link. If I can say "I could build this, but it already exists here", I'm happy because I know I've given them something truly professional in a week that would have taken way longer and cost way more to build, plus any random person can work on it and parts will be available on eBay.
Using common languages is just an extension of that.
If someone uses unusual languages, I expect they'll have unusual problems that will become my problem if I'm working with them.
I promise, Oracle (the company) is a good reason to use anything except Oracle.
On a more humorous/worrying note, there's also this: https://news.ycombinator.com/item?id=18442941
And you’re doing a grave disservice to Elixir at the least. I prefer Erlang myself, but Elixir has established itself as a robust choice.
I haven't had the same luck with frontend. There's so much magic, config file hell, and other rough edges that you need someone who knows the framework. In the JS world, actually writing code is maybe 50% of the work, and managing the ecosystem (config, build, packages, etc.) is the rest.
I'm not sure what you're suggesting.
Are we expected to rewrite everything every decade when a new flavor of language comes out?
It seems like, with the exception of Rust, you've named a lot of "lowest common denominator" languages. These languages, while productive, tend to lack expressiveness. It is my opinion that expressiveness is seen as a bad thing in the "professional" community because it takes significant cerebral evolution over the course of a career to learn which tool in the toolbox to use. In other words since the explosion of programming as a career there are more idiots in the proverbial gene pool, and so more companies prefer more idiot-proof languages because the average developer can't help but hurt themselves. This doesn't mean we should prefer "new safe technologies", it means our recruiting should far more stringent and our education far more formal (as in an actual useful programming degree).
I for one would quit if I could program, for example, common lisp and make even 3/4 of my current salary.
Here's, in my opinion, a better and less controversial hot take. Use what works. If you have a team of erlang developers do it in erlang (or whatever). Who cares about the market. If it means spending even more time (and money) learning to write another more popular language correctly it may not be worth the investment. If you build it, they will come. You will have no problem finding an endless stream of developers you can build from the ground up.
As a side note: Kotlin, Ruby, and F# are extremely popular. TIOBE is not a real measure.
As an IC, I care about the market. I go to work exclusively to exchange my labor for money to support my addiction to food and shelter. When it was time to change jobs as your bog standard enterprise dev, it was much easier to throw my resume in the air and get a job offer by being an experienced C# developer than it would have been if I had spent three years writing software in Erlang.
And most job interviews outside of tech companies where most developers work are not going to be language agnostic nor are they going to have you reversing binary trees on the whiteboard while juggling bowling balls and riding a unicycle on a tightrope.
As a reformed former dev lead, why would I hire an Erlang developer when I could throw a rock and hit a good enough C#/Java JavaScript/React developer to push out some CRUD SaaS app or line of business app?
Are we really to believe that the average Javascript developer is going to be able to be dropped in an Erlang shop (or any of the other "weird" languages) and be productive any time soon?
I’m sure I could (re)learn Java that I haven’t touched since shortly after it was first introduced in the 90s in a few weeks. That doesn’t mean I would be a competent Android developer.
The average JavaScript developer would be an idiot to ever step foot in Erlang shop if he knew what was good for his career.
My resume was sacrosanct when I was in the enterprise dev world until mid 2020. Why would I reduce my optionality by not using the most marketable technologies?
Sure you will. There’s no “Android developer”, there’s Java/Kotlin developer who uses Android SDK.
Who would you rather lead the development of your Android app? Someone with no experience with Android or someone with previous experience.
a) the most experienced amongst the team in any particular language
b) the most experienced amongst the team in any particular domain
c) the go-to person for any particular problem
The whole point of a team is to cover several different sets of knowledge and experience because no one person can know it all or do it all. A leader does their best to enable this collective to produce the best it can.
Leaders know this.
If the incentive is to ship product then choosing the language you already have a team for makes the most sense.
If you are choosing based on hiring a new team, then the current flavors work. 20 years ago that was Java. Today it's C#. 20 years from now it'll be something else.
If you are a developer looking to grow a resume for the next job, then it's a double-edged sword. Sure it's easier to get a C# gig. But it pays less because you're in a bigger pool. It's harder to stand out. Conversely it's harder to get say a Cobol gig. But it's easier to build a profile in the Cobol community (simply by being under 80 years old) and there is a Lot of work around, and is very well paid.
Equally something that's marginally popular now will have a long tail and can be very lucrative. Erlang might be obscure, but there are plenty of shops who would love to pick up another experienced, capable, erlang developer. You're a bigger fish in a smaller pond.
So yeah, language is like most things, dependant on your point of view. That's why we gave so many of them.
BTW, what languages do you think all of those BigTech companies that pay well are using?
I just keep bringing up C# because that’s the language I have the most experience with. But substitute $any popular language.
Even OCamls share would be bigger within big tech, thanks to Meta.
(and I say this as a big fan of OCaml)
also note that Jane Street does everything in OCaml. I can't believe it's bad for their employees' careers. probably because they're not looking for the same jobs as the average JavaScript pleb.
It's a fundamentally different ask to learn Haskell, datalog, SaC. You are actually learning a new language instead of just the flavour of the week imperative programming.
Now the real stuff that can cause problems is bad tooling and lack of support. You cannot code your things when you're trying to fix the compiler, build tools or the debugger.
What good is a language in 2022 without a complete ecosystem of frameworks for most jobs?
Libraries cannot change that basic fact - there are just problems it will be extremely unsuited for.
Java has some of the same problem by the way in reverse. (Package handling, forced garbage collection and unknown real time and memory usage characteristics.) The difference being that Java's core has much less important opinions about algorithms, while Haskell tries to make everything functional or it is awkward.
So, while Haskell will be hard to use for problems best described in an imperative way (in addition to other issues say Java has), Java will only have serious problems where memory and runtime determinism are paramount.
It so happens that a lot of the programming is done in imperative way. Including the libraries.
The last time the third party Haskell SDK for AWS was updated was in 2014. I do see a third party GCP SDK. But if GCP and Azure works like AWS, as soon as a new API is released by a service team, all of the officially supported SDKs automatically get updated.
I am sure there are other service providers that have SDKs and code samples for popular languages.
https://aws.amazon.com/developer/tools/
I believe the list for GCP and Azure are about the same. What are the chances that your problem is such a special snowflake that it can’t be solved with one of those languages? What are the chances that any new developer could ramp up faster or already knows Boto3 (the AWS SDK for Python)? If they have an issue, they can go to StackOverflow or raise a ticket with their TAM.
Which would have more assurances are designed correctly, the one from the vendor or yours? I was able to take advantage of new APIS for one of AWS services the day it was introduced, no need to waste cycles on creating my own wrapper. Creating a wrapper around my cloud providers APIS, “doesn’t make the beer taste better”
AWS’s SDKs automatically take care of retries, exponential back offs, wrapping the APIs to be idiomatic including logical exceptions being thrown, any underlying changes, etc.
The same language? Maybe a few % considering a client is a small part of what you need to create. A different language? Depends on the comparison. I would be tens to hundreds % more efficient in Haskell then in Go or Python.
> I believe the list for GCP and Azure are about the same. What are the chances that your problem is such a special snowflake that it can’t be solved with one of those languages?
Of course it can be solved in those languages. I can also solve it in Assembly or brainfuck with enough elbow grease. What matters is speed of implementation and correctness. With the exception of Rust all these language have debilitating flaws.
> Which would have more assurances are designed correctly, the one from the vendor or yours? I was able to take advantage of new APIS for one of AWS services the day it was introduced, no need to waste cycles on creating my own wrapper. Creating a wrapper around my cloud providers APIS, “doesn’t make the beer taste better”
> AWS’s SDKs automatically take care of retries, exponential back offs, wrapping the APIs to be idiomatic including logical exceptions being thrown, any underlying changes, etc.
Did you ever try openapi generated clients? They can handle retries and exponential backoffs as well. There is no design to be done here. It just exposes the API as designed.
This isn’t meant to be a rah rah AWS is the bees knees. It’s just the cloud provider I know the best (and the one I work for), I’m sure knowing MS, the developer experience is just as good as AWS. I just don’t have experience with it.
> Of course it can be solved in those languages. I can also solve it in Assembly or brainfuck with enough elbow grease. What matters is speed of implementation and correctness. With the exception of Rust all these language have debilitating flaws.
What’s the old saying about it’s a poor craftsman that blames his tools? If you can’t be productive in any of the nine languages that are popular enough to be supported by the major cloud providers, does that say more about the tools or the craftsmen?
https://github.com/brendanhay/amazonka
I use the package directly from GitHub in my project.
Work is not only about money for me. My best work environments have been a small team of skilled people tackling a big problem. For this we would use whatever is the best tool for the job, regardless of its outside popularity.
I personally hate the clusterfuck of the modern front end ecosystem and would avoid it like the plague. But, if I was responsible for choosing the framework to use, I would choose React any day just for recruitment reasons.
If you want top talent then you've got to offer something they want; sure you can always pay more, but past a certain point that might not be enough, plus it gets expensive. Using better languages is one of the most effective ways to get noticed by the candidates you really want.
When I was in the Enterprise/Corp dev world until a couple of years ago, I could call a few recruiters and have 8 interviews and two or three offers within less than a month. It’s easy to pattern match when you use a popular technology.
Or even the same amount of money when the pay/bullshit ratio starts going in the wrong direction.
You realize all of the BigTech companies use the same “boring languages” don’t you?
What kind of argument is that? Of course they do, you can’t get away from using JS for front, for example.
But they also use Ocaml, Haskell, Scala.
The biggest companies largely use dull languages, sure, although you sometimes find pockets within them that are doing something at least a little nicer (e.g. OCaml at Facebook). So much the worse for the big companies.
My excitement during the first decade of my career came from my working hobby as a fitness instructor and running with friends. In less than a month my “excitement” is going to come from my wife and I living out of two suitcases flying across the country staying in mid tier hotels for a few years.
I could spend my free time learning a new programming language. But I am finding it much more “exciting” learning Spanish so when we stay in Mexico for a few weeks, I can at least be able to communicate somewhat.
Not bragging, it’s about what a mid level developer makes at most of the large tech companies.
I definitely couldn’t have afforded my current adventure at my old job nor could I have afforded to retire my wife.
- back end development in a few popular languages
- about an average “data architect” for lack of a better word. I’ve led implementations on every type of database imaginable including ETL type jobs and online systems.
- “DevOps” (at least if you give me an AWS account) including setting up networking infrastructure, logging, monitoring, CI/CD, etc.
I’ve led plenty of pre-sales meetings, writing SOWs, pretty PowerPoint slides and architecture diagrams etc.
The “generalist” is very useful when you need someone to lead projects and to understand how everything fits together. I’ve had to wear all of the above hats at startups. Now I wear those same hats at a cloud provider I’m sure you have heard of. I specifically targeted my current position because I wanted to be a generalist.
I’m no special snowflake. Many of my coworkers who came up the ranks in startups and have similar experience can do the same.
I'm zero worried about it as it's never been an issue.
If you’re being hired to lead developers and projects, don’t you think you need to know the technology you’re leading?
I'd pass on such a position.
Also you talk about only having experience in a less popular language as a death sentence.
I've been only writing Haskell professionally for a decade, but I get endless amounts of interview invites for prior experience.
Out of curiosity I went through some of the better invitations interview process and had no issue getting offers either.
If anything mentioning my professional Haskell experience gets me an offer faster no matter the positions requirements.
When I spoke to CxOs and directors, they wanted someone with a proven track record that could solve their problems. When I was being hired as a dev lead to lead junior C# developers he inherited, what would he look like hiring someone who knew Haskell?
How was i suppose to go from an empty git repo to a fully fleshed out MVP or later from an empty AWS account to infrastructure, CI/CD, to a fully fledged out MVP if I didn’t have prior experience?
If someone is looking to create a new iOS app. Who should they hire? Someone with iOS experience or someone with Erlang experience?
It also means you’re competing in a much smaller market and people looking for strong Erlang developers will be suddenly very interested in you specifically, because it’s tough to find strong candidates with this expertise.
It also might mean (depending on your interests) that positions that are open are in a more intellectually interesting problem space, because boring problems tend to be solved in the lowest common denominator languages, and if an unusual language is chosen, it might be chosen because it’s a being used in a unique context.
As in, reductio ad absurdum, “if only I had been working in Java, I’d be safe, but because I worked in Ruby, I am going have to go flip burgers, as no one will let me near their precious production code now?”
I mean, yeah, ok, there was the dotcom bust, and I suppose another could happen at any point, but somehow I get the impression that you’re arguing that using any language except the most mainstream option (whatever that might be for a given industry) is too risky? Or am I misreading?
But in the boring enterprise dev world where I came from especially during the latter part where I was specifically being hired to lead initiatives, of course they wanted someone with relevant experience.
Idiot proof languages are popular. If you want assured money learn an idiot proof LCD language. In fact, everyone should have one in their tool belt to put food on the table.
However, if you're actually a talented engineer these languages will hamstring you and your art. You will probably eventually gravitate to something more heady (such as the less popular languages) and probably even leave your nice cushy gig to give a professional life in that stack a shot. This isn't, however, to say talented engineers don't exist in lowest common denominator language pools. It's just esoteric/less-used languages tends to cause the best quality of talent to come from them owing from many of their problems. If you can be proficient and productive in a language that you can't easily google a solution for, you're probably an excellent candidate for promotion into the higher echelons.
This is a similar phenomenon to editor choice. My anecdata in a little over 10 years of a career has given me the impression that I can tell what kind of developer someone is by their editor. People who use raw vim/emacs tend to better developers. Why? It's not the editor itself. It's that these editors pull no punches and require time and expertise. That dedication is not taught. The easier an editor is to use for a beginner, the more average a programmer tends to be. Again, there are a lot of very talented developers using VSCode or full blown IDEs. But with those editors your signal to noise ratio is quite low. It's anecdata but mixed with the information above you can gather a lot of "metadata" about a person without much effort.
My anecdata, people who overly focus on language and tools tend to be the worse developers. It's the developers that effectively address the universal problems of writing software people want to use, like api usability, reliability, data consistency, maintainability that have the most props in my book. The best developers I've known weren't particularly attached to any editor, language, or framework.
Serious question: all else equal and without any additional information, between two carpenters who produced the same output in the same time, one with power tools the other without, is there any reason whatsoever to assume one of them is any better than the other?
For me I would definitely make use of this extra information before hiring. Hiring a carpenter who's able to work with power tools is likely better, unless I need to foresee a situation where they must work without electricity. Even if they are physically fit, power tools can enable a human to do something not possible at all with bare hands.
For a programmer it's the reverse, if we assume "power tool" is an "easy" language compared to something like OCaml, or maybe tools like VS Code and Copilot compared to vim. These tools don't help overcome a physical limitation, like the power tools of a carpenter, but a mental one. Being able to set up vim fully to be as productive and produce as few bugs as someone with VS Code, or being able to pick up Haskell without being able to immediately get a human answer your every question, exemplifies the type of higher-level skills and learning capability that is the primary value of a human employee compared to a robot.
In other words, in context of this discussion, the equivalent of carpenter's power tools might be much closer to Haskell + bespoke vim/tmux setup than JavaScript + VSC.
I'd think manual carpenter is going to have to retire early due to repetitive strain injury.
The same with "easy"/mainstream languages: something like OCaml/Haskell/Nim/Nix/etc. is a power tool with a steeper learning curve compared to something like Python/JavaScript/shell scripting; you being able (and willing) to handle it without abundance of learning resources says something about your mental capacity and potential value as an employee.
Companies pay employees to add business value. Not to get into their own flights of fancy to do things the hard way. As you mature, you learn only to focus on things that “make the beer taste better”.
I have yet to see an argument by any of the proponents of “obscure” languages where their choice adds business value.
And the “hard problems” that are being solved by the large companies at a scale that has never been solved are doing so by using mainstream languages.
I’ve never seen a report of a job interview where they asked you to reverse a binary tree in Erlang.
The vast majority of problems that developers are being asked to solve are not that hard technically. They are business problems.
I’m motivated to get up everyday for the same reason most people are - money.
I bet you’re looking for people with “passion” and who are willing to consistently put in more than 40 hours a week aren’t you? Out of all the millions of things I can do and have done in my free time over my career (including a working hobby as a part time fitness instructor back in my younger days an avid runner and a weightlifter) spending more time sitting at a computer outside of work isn’t one of them.
And the obscure language would hardly ever outweigh the need to recruit developers easily.
Where have you seen that?
> I’m motivated to get up everyday for the same reason most people are - money.
You are quite mistaken. Once they have enough to exist comfortably, people tend to seek meaning not money. The emergence of OSS ecosystem is the best example -- a lot of it, including the most popular OS in the world, came about as hobby projects people did in their spare time. If you're a software engineer, I bet you use products of their passion a lot in your money-making activities.
> I bet you’re looking for people with “passion” and who are willing to consistently put in more than 40 hours a week aren’t you?
Again, all else equal, if I need to make a decision as to who would be a better, more capable employee in absence of other information, the one who managed to be productive in an obscure language would be higher on my list. Just that. Everything else, making people work overtime, etc., is your addition.
Look at a list of who the largest contributors are to Linux.
https://news.itsfoss.com/huawei-kernel-contribution/
Most of the contributors are getting paid to do so.
Do you really think most of the 2.7 million developers in the US are contributing to open source?
Regarding how many in the US contribute, I don't know the stats... Could probably be more if work-life balance/employment security was better.
https://www.hanselman.com/blog/dark-matter-developers-the-un...
I think this is an apt analogy. Mostly because carpenters who use hand tools produce more beautiful, unique works of art. When everything you do is on rails (no pun intended) you don't have the flexibility or creativity to make works of art. It's like saying Ikea tables (the equivalent of an idiot proof language) are just as nice to look at and functional as a purpose-driven hand crafted table. I have my doubts, despite using Ikea when I "just need something done".
Nice one, being it elucidates the art being lost in other fields (and perhaps all over).
You saw that whole spiel about my desire to exchange my labor for money to support my addiction to food and shelter?
> However, if you're actually a talented engineer these languages will hamstring you and your art.
I have no desire to be a starving artist. I turn requirements into code so businesses with money will give me some of it by adding business value. I don’t program to create the next Picasso.
I stopped considering programming “fun” after doing it for 10 years across 4 assembly languages (65C02, 68K, PPC, x86) before I graduated from college in 1996.
> and probably even leave your nice cushy gig to give a professional life in that stack a shot
So tell me again why I would leave my “cushy gig” (and it is the cushiest gig you can imagine in any BigTech company)?
> you can be proficient and productive in a language that you can't easily google a solution for, you're probably an excellent candidate for promotion into the higher echelons.
Every single leveling guideline I have seen at any tech company doesn’t mention “ability to code in an esoteric language well”. It’s all about “scope”, “impact”, “managing ambiguity”, etc. “Coding ability” really only comes into play from junior to mid. After that it is about system design even at the interviews.
this makes me sad to hear. I fell in love with programming at age 7 and still love it at 32. I'm extremely fortunate to enjoy something that pays well, rather than languishing at a cushy job that leaves me empty.
> Every single leveling guideline I have seen at any tech company don’t mention “ability to code in an esoteric language well”. It’s all about “scope”, “impact”, “managing ambiguity”, etc. “Coding ability” really only comes into play from junior to mid. After that it is about system design even at the interviews.
if you're hiring plumbers, sure. it's not all plumbing, though. there's algorithm design, compiler engineering, formal verification, program synthesis, numerical methods, etc. etc.
the really effective people in those fields use (or make) weird languages. Isabelle's written in HOL, Coq in OCaml, Agda in Haskell. having a knack for weird languages is a plus for brainy jobs working on that kind of stuff.
My job paying well allowed my wife to buy a vacation home/investment property for the winter and starting at the end of the month fly around the country and stay in mid tier hotels and do the whole “digital nomad thing”.
I spent the first fifteen years out of college having a great time outside of work as a part time fitness instructor (more of hobby) and training and running with friends.
Sure I’m learning a new language now - Spanish.
Making sure that you actually enjoy those hours has a massive impact on your quality of life.
For an extreme example, what pay cut would you be willing to take if you were able to do fitness training full-time?
> My job paying well allowed my wife to buy a vacation home/investment property for the winter and starting at the end of the month fly around the country and stay in mid tier hotels and do the whole “digital nomad thing”.
This is somewhat off-topic and I don't know you or your wife personally, but I find it flabbergasting that a spouse would choose to do the "digital nomad thing" when their partner can't or won't follow them. Even more so when they're being bankrolled by said partner.
If you look at the leveling or hiring guidelines for any major tech company, what separates “senior developers” and up from mid level developers are system design, “handling ambiguity”, leadership, “scope”, “impact” and in the case of Google did you write a messaging app.
Even the largest tech companies realize “coding ability” only gets you so far and most developers who want to get ahead would be far better off focusing on the other aspects of software engineering.
Coding has little to do with handling ambiguity.
While I have never been through a BigTech coding interview, I have been through (and passed) a BigTech system design interview, it has little to do with coding.
Designing (and redesigning) systems for large organizations is my $DayJob where I have to be able to explain those concepts.
Early in my career I thought of software as art. I was wrong.
The very last thing I want in any production software team is an artist looking to express themselves. I want the worlds most talented engineers who want to use consistent proven methods to create solid maintainable code with zero surprises.
Code as art has its place, granted, but that place is in the privacy of your own time in a repository with one single contributor. I occasionally still go back to writing lisp for fun, but it has no place in production.
The very best engineers are like artists, in that they harness their creativity to solve problems efficiently and effectively, often in innovative and personal ways.
And artists who are respected in the field of software can use consistent methods to produce solid maintainable code. I wouldn't say "zero surprises" though, I'm often surprised by reading the code of an artist, how they achieve extraordinary results with mundane code that a child can understand.
The example that comes to mind is Fabrice Bellard. He's one of the most talented engineers - and I'm sure many of us would agree that his software is a work of art.
Well, as someone who has to manage a team, I completely agree that what's needed are engineers who can consistently produce predictable results. We don't want someone who chooses (or worse, creates!) an esoteric language to pursue their art. But I myself am of the latter persuasion, "writing lisp for fun". And having a team of only non-artistic engineers would be so boring. But then again, boring is what we need most of the time.
As a reformed former dev lead, I wanted a consistent industry standard idiomatic method of writing code and I used a combination of static analysis tools and code reviews to establish a culture to do just that.
I don’t want my C# developers who came from Java writing an AbstractFactoryFacadeBeanProxyDecaratorSingleton.
“Fun” for me is doing anything except being in front of a computer after hours. Between time with my wife, exercise, learning Spanish and just vegging out, computers are the last thing on my mind. I don’t even have a personal computer anymore.
That reminds me of an excerpt from this humorous (but still relatable) bit of writing: https://www.stilldrinking.org/programming-sucks
> Every programmer occasionally, when nobody’s home, turns off the lights, pours a glass of scotch, puts on some light German electronica, and opens up a file on their computer. It’s a different file for every programmer. Sometimes they wrote it, sometimes they found it and knew they had to save it. They read over the lines, and weep at their beauty, then the tears turn bitter as they remember the rest of the files and the inevitable collapse of all that is good and true in the world.
> This file is Good Code. It has sensible and consistent names for functions and variables. It’s concise. It doesn’t do anything obviously stupid. It has never had to live in the wild, or answer to a sales team. It does exactly one, mundane, specific thing, and it does it well. It was written by a single person, and never touched by another. It reads like poetry written by someone over thirty.
> Every programmer starts out writing some perfect little snowflake like this. Then they’re told on Friday they need to have six hundred snowflakes written by Tuesday, so they cheat a bit here and there and maybe copy a few snowflakes and try to stick them together or they have to ask a coworker to work on one who melts it and then all the programmers’ snowflakes get dumped together in some inscrutable shape and somebody leans a Picasso on it because nobody wants to see the cat urine soaking into all your broken snowflakes melting in the light of day. Next week, everybody shovels more snow on it to keep the Picasso from falling over.
Even in C that lacks any form of sane abstraction capabilities, people have come up with object systems and what not if they fit a problem domain better. While I think that the language optimum is well past C, there is no significant difference between modern managed languages in any way besides ecosystems — and that is the most important thing.
Because of this: "The Python Paradox" [1].
Replace Python (which has become mainstream in the meantime) with any other "weird" language from the article and I think the point still stands.
If it matters I had started learning Python just about when this article was being written/published, and in my early to mid-career that advice of using a "weird" language (Python, at the time) was really good for me, got me into a couple of small companies where I really enjoyed working.
Granted, now I'm already over 40 years of age with a mortgage to pay, I'm a little more flexible when it comes to the technologies being used (even though I would cry myself to work in the early hours of morning were I to use Java, and I'm not kidding), but for people who are quite early in their careers letting them explore and use those "weird" languages will still do them a lot of good in terms of them enjoying their programming work, they might even land on a forum written in Arc.
[1] http://www.paulgraham.com/pypar.html
When I first started in my career over two and a half decades ago, my focus was on being able to be aligned with the market and being able to support myself. I was young, single, had no responsibilities and just moved to a major city. The last thing I considered “fun” was programming.
Yes, you leave money on the table if you do that (I know I did, I have friends the same age as me who earn a lot more than I do because they went the non-obscure language path early in their career), but at the same time you also bring some purpose into your professional life, which cannot be entirely bought with money.
Or maybe I was the weak one when I didn't see myself programming in something like Java for a living for my entire career (30 to 40 years), again, that would have literally caused me to cry before going to work, in which case, yes, those persons that can surpass that type of feeling should definitely go for the "more money/less interesting programming stuff" route.
By 2016, I knew I didn’t want to be “just a developer”. I enjoyed working with customers, leading projects, mentoring and teaching. But I still wanted to stay hands on
I belatedly discovered “the cloud” and realized I wanted to specialize in true “Devops” bringing developers and operations together and working with companies to show their developers how to be “cloud native” (application modernization)
When $BigTech came calling about a pure software engineer position, I really wasn’t interested. I kept talking to the recruiter and she told me about a cloud consulting position where I would be able to be involved in the full life cycle from pre-sales, to delivering a finished product including infrastructure. I jumped at the chance.
I think the ironic thing here is that these "approved" languages are both less safe and less expressive. Statically typed functional languages like Haskell and OCaml allow much more correct code and reject much more wrong code compared to something like Java or Go. I'd even go as far as to argue that in some ways, Haskell is more expressive than the mainstream dynamic languages (Ruby, Python, JS etc).
Now, if your developers are really "idiots" (which to me is a very condescending thing to assume, but that's a different story...), then maybe they won't even be able to get their code to type check in the first place and ship no code at all :)
In functional code, sure. In a predominantly mutable algorithm, you fight the language more than what you gain, and sometimes, yes, the mutable approach is simpler and easier to reason about. Especially local mutability can be very readable/maintainable.
Considering the popularity of the Android platform and Google's control over it, I don't think it is a bad idea to develop an Android app in Kotlin. According to Google, their Maps, Home, Play, Drive, and Messages apps are all built in Kotlin, and my personal experience is that Android developers like and prefer Kotlin.
Wow if Google is behind it, where do I sign up? It’s definitely going to take off and not be abandoned.
I probably could even write some games I could release on Stadia.
I thought they were fully committed to Dart or was that last week?
That's why I don't think it makes much sense to treat kotlin in the same category as the other languages. Sure, it's a programming language, but the way JetBrains executed on it with its easy upgrade path from java and really excellent design, not to mention the toolchain, mean that it's success and trajectory cannot easily be generalized to other "weird languages".
Also compiled languages have longer staying power because if you move on from the language, you can still make use of the binaries but simply never write it again. Look at all the Fortran libs that are still in use by other languages...
https://www.jetbrains.com/idea/download/
That is because the other option is a deliberately crippled Java from a decade ago. Also, while apps are indeed mostly written in Kotlin for android, I am fairly sure most of Google’s listed apps have a Java shared library that does the core of the functionality that is shared between backend, android, web frontend (j2cl) and ios (j2objc).
Also, don’t forget that android development is a niche, on the web backend side Java is just an incomparable bigger player.
Sure if your value add is content then go ahead and use mature tools within the paradigm, but if you want to cause a so called "paradigm shift" then you'll need to understand where the progress is happening and what kinds of opportunities it creates.
Ocaml for example is looking more and more enticing. Standard meta language is used by academics and programming language theory is developed in it. Meaning that it has a good long term trajectory (along with lisps I suppose).
Of course we are about to grow out of syntax, soon it'll just be another config param in your editor.. but I don't think these "obvious choices" you list will all be as well positioned w.r.t. that change.
Right now it may be harder to agree with me than with you, but that makes me think of a hn thread I was reading recently where people didn't want to admit to being programmers (in public / to strangers) because the perception is starting to be that what we do is immoral. Sufficient mastery of programming will make it a boring thing that everyone knows how to do but lowering the bar to that point won't happen within the web paradigm we currently inhabit. We'll see if wasm brings us closer but I think it will take more than that.
Anyway, I'd say your advice is good but not great. A CTO should be able to assess which tools fit the problem they have for the timescales they're considering. If they're swayed by your comment (or mine for that matter) then they're not fit for the role. The person you are actually talking to is someone who is building a company that suffers tech while the core business is something else or a company that is meant to be sold to some giant.
This is the most Hacker News thing I read all year. What are you talking about? Where did he say anything about wanting to cause a paradigm shift?
Facebook was PHP.
Google was C++.
Bitcoin was C++.
Netflix was Java.
Spend your innovation points on your product, not on programming language.
Most Telcos, what’s app used Erlang.
Apple used Objective C, and built its own language.
Microsoft used C++… and built a series of languages.
Most of the web programming was in flash… until suddenly JavaScript won out.
Except for Figma which uses WASM based stuff.
Spend innovation points on your product… but sometimes innovative products require innovative ways to built it.
Nokia Networks customers were using a mix of C++ and Perl running on HP-UX back in 2004, and nowadays it is mostly C++ and Java running on Linux distributions. Not every telco is using Siemens Erlang based switches.
Apple created Clascal and Object Pascal, migrated to C++, got Objective C via NeXT acquisition, which previously licensed it from StepStone. They also created Mac Lisp, Hypercard, Dylan and Newtonscript.
Microsoft used BASIC for a looong time, dabbled with Pascal, had one of the best macro assemblers in the market, was the last MS-DOS vendor to actually add C++ support to their C compiler, focused on VB and C++ until .NET came to be.
I've never in my life done anything that I feel standard languages aren't a good fit for.
I do think Dart deserves full best practices status, because the tooling and ecosystem around it is fantastic, and because it doesn't have a bunch of "Outside the paradigm" stuff, it's all things you can learn in a week coming from Py/JS/etc.
I'm not exactly sure what the slowness people talk about is. Even the most bloated of websites are fast.
The one thing that still is an issue is Android load times. It gets a little excited about killing background apps on my phone and will take 10 seconds to open my notetaking app again.
Runtime errors.
any chance you could find and link to that thread?
When I started the main project I am still maintaining, react wasn't even around yet. It started only 9 years ago, which might seem like a long time to some younger folks, but feels like yesterday to me.
Are you suggesting that languages and frameworks are 'solved' now? That we won't get a new react that changes the ecosystem? How will a new language or framework that makes things easier ever come about if everyone follows your advice?
It just somehow fell behind on the hype curve, mostly because Ruby itself wasn't used for anything else than Rails. Python took its spot in most general use cases.
If you only stay with what is popular nothing new becomes popular.l and you become mediocre.
Popular isn’t always the right choice. There’s the situation things are only popular because they are popular. React seems to fit that now, it’s the default as everyone else is using it even if there’s newer alternatives.
Innovation only happens by doing things different.
Choose what is appropriate, not what is popular or what is new.
The three you mentioned got over the hump by corporate backing. In particular Rust got in force thanks to Mozilla, golang to Google and TypeScript to Microsoft. Big guys sometimes make an abject irrelevancy or failure (e.g. F# which didn't quite catch on, old stuff like Visual Basic) but usually at least the support and visibility is there.
If the attitude you're encouraging were followed, these would all have been relegated to unsuccessful research projects and we'd all still be programming in assembly language.
I mean, I don't follow that advice at all, and if you don't want to you shouldn't either, but there's definitely a fair argument that it would be "better" for most cases to accomplish your goal with boring technology.
It's weird to me that it's the stubborn languages that seem to make it through.
And they continue to introduce new ML features in the form of pattern matching, ADT, etc.
I think sometimes these languages get unfairly evaluated.
I'm perfectly happy letting other people work in the middle of the bell curve, but I cry a little inside when I see a super cool application be ruined by highly conservative software thinking. I have never been able to understand that, usually hardware-oriented, companies will be doing something super advanced and novel with physics, engineering, biology, and other "hardware" related things, but then will bury their heads in the sand unless the most common denominator programming language is used because they supposedly can't hire people otherwise. But yet they're perfectly willing to hire and train people on the novel hardware designs. It doesn't add up.
There is a very strange uncomfortability with software ideas that are new to people that I do not see when it comes to even the most novel and cutting-edge hardware-related topics. I have experienced this in internal talks, where hardware-related talks will generate a huge amount of buzz and questions, despite often being well beyond the audience, and the software-oriented talks seem to attract crickets. Honestly, I think it's a bit of hidden hubris, in that many scientists and engineers consider themselves to understand software, and in showing interest in new software-related things, they fear showcasing that they don't know something they fancy themselves as knowing. The other possible answer is that people are just afraid of software in some sense.
I found this in a recent interview where it seemed to be expected to solve a problem using objects and either interfaces or inheritance. I solved the problem with discriminated unions and pattern matching, and there seemed to be some uncomfortability with the solution because it wasn't what they were used to as being the "right answer", when in reality it was just another spot in the solution space of the expression problem.
I'm not surprised, it is very difficult to scale Python to larger teams and projects. I mean people have done it to some degree, but at what cost?
It's much better to stick with a static language like Java or C#. You mentioned pattern matching and discriminated unions at the end of your post, which Java has recently gained, and C# to an extent as well.
Its value decreases swiftly the less glue you require, since that is its real niche.
It's such an insightful phrase.
In general, people are afraid of simplicity. When you show them a technique or programming language or method or perspective or whatever that is new to them but also simplified the problem, people are inherently bothered that it isn’t as complex as they’re used to, which convinces them that it isn’t a valid solution.
But mainstream languages also include C++, C#, Go and many others. It's a good thing to have several different tools in your toolbox, but a few tools can cover pretty much any scenario outside of really extreme corner cases (where something like e.g. Prolog might be of use).
(But then again your list is also kinda weird. I mean, seriously, it has React but not C++?)
I'm going with this as the problem statement, and it is a problem, but I submit that being saddled with a technology is a cultural problem, not a technical one. Related: Conway's Law Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure.
> If you are the person deciding which technologies to use, you should probably be using the most mainstream thing you can, not the coolest newest thing that you read on Hacker News.
This solution does not address the problem statement, and so will sometimes be a good answer, but only by accident, and makes the same mistake as choosing "the coolest new thing on Hacker News". Choosing a technology to address a specific challenge is not always easy or obvious, but takes thought, humility, consideration, familiarity with the options, probably even a team decision. A manager that just top-down decides for the engineers is doing it wrong, whatever they choose.
Come out of the reality distortion bubble, please.
A language of a somewhat more sophisticated design can make it harder to find developers but let you need much less.
E.g. Scala (which, contrary to the myth, has great learning curve and readability as long as you don't insist on making heavy use of the really weird parts - they are entirely optional) vs Java can easily boost productivity 10 times. Scala code usually is less verbose and works perfectly once built successfully - ~99% errors are detected at compile time. I know numerous Java devs who have switched to Scala to solo-dev efficiently, because they have no time to code and debug Java. Kotlin was designed based on the Scala experience to make it even better.
However I also think, that time should be spent in non-mainstream languages to learn new programming concepts, and eventually future version of "X, Y and Z" might even get those concepts and thus one is better prepared to apply them.
If it's an issue with existing devs refusing to skill up, they can just write their ancient antiquated Java until they retire, it'll still work just fine alongside the new Kotlin code. But in my experience it's rare that even the most institutuonalised Java dev doesn't appreciate the nullability support at least.
There's actually a tricky tradeoff here. Many startups working on hard problems can benefit from making one weird technology choice, if it offers them some kind of significant leverage on a previously difficult technical problem.
But when it comes to recruiting, it can actually be an advantage to be using a slightly obscure language. Often, these languages have communities of very skilled early adopters who wish they could use their favorite language at their day job. And especially if your company has a strong remote culture, this may make it possible to hire some extremely talented people.
I do agree that, on average, a company's overall tech choices should be mostly boring. But knowing when a lesser-known tool will offer a big advantage is an art, and it can pay off.
If you have so little awareness of the Scala ecosystem that you don't realize how laughable such a remark is in 2022, yet allow yourself to have such a strong opinion on the language, I have less than zero interest in the rest of your opinions about "weird languages".
I don't know Scala though, so perhaps your argument would make more sense to me if you explained why they were so wrong.
I'm tired of people who never really used Scala or haven't used it in years casually shitting on it like it's a cool thing to do. Like "Scala is a mess" is something self-obvious that doesn't even need any explanation / justification.
And Scala aside, it's pretty amazing that a blog post that can be summarized as "be a normie, being weird is expensive" is at the top of Hacker News. Such hackers we are.
Just gonna point out you didn't keep your cool and ignore it.
Keeping your cool: good!
Ignoring it: no way!
You obviously have a lot of passion for the topic, and may have rightly identified a flaw in the author's blog post. You can use that passion - and keeping your cool - to correct the record.
e.g. I dunno OP is wrong and Scala is not a mess, it is awesome! That culture war was resolved in favor of cats years ago, and here's why...
I know Python best. But I have reached my breaking point with its syntax, and its lack of binding constructs, and lack of symbol datatype, quote, etc. I am intending to use Clojure ... but I have to ship this thing by May 2023 come hell or high water.
All else being equal, I will proooobably be able to go further with Python. But I'm concerned it will hamstring me from doing the crucial feature of "extending the design [ie code] of a game as it runs" since, AFAIK, it's difficult to get a Lisp-ish experience of total live reloadability in Python... jurigged[2] and reloading[3] not withstanding.
I know some common lisp so I'm not a total lisp noob. I've learned enough CLJ to be dangerous ... but I'm worried I'm backing myself into an endless hole by using a language I'm not yet master of. Yet, I think the features of the ecosystem (total live reloadability of a CLJ/CLJS app! with current state preserved even down to what a user has typed in the HTML UI!) are so tempting...
Just venting out loud. comment/contact if you have suggestios or are curious about the project; i'm soon to begin blogging as I develop it.
[1] I'm reinventing the "virtual tabletop." Current ones are so fucking shallow. [2] https://github.com/breuleux/jurigged [3] https://github.com/julvo/reloading
There doesn't seem to be a good GUI framework for Clojure. There was Seesaw but it hasn't been updated since 2019 (no maintainer). There is a guy developing a new framework https://github.com/HumbleUI/HumbleUI/ but it's WIP. I guess you could sidestep this by making it a webapp and using figwheel + web framework of choice.
My project will definitely be a web app -- I'm most familiar with web dev, plus I'd much rather be able to point someone at a URL and say "here's the thing try it out" and have that happen in 5 seconds instead of dancing the installation mambo.
Thanks for the pointer to figwheel -- that looks like hot stuff and just what I need for end to end server/client interactive dev!
This makes it one of the languages of choice for auxiliary scripting a big system, like a game or an application. (The other common choice is Python, and nowadays also JavaScript.)
Anything else, it is relatively awkward at.
coupling clojure with python sounds like a drag, even using graal i dont think this will be easy. but janet you could bind as a dll and eat your cake while having it as just recently FFI was added. if you are interested, i can probably help a little as im working on an integrated (game)development repl myself. not sure how to classify what im working on but i think its close to your domain as i want to change my hotloop during runtime from the repl and from inside the running game. i just wrote you an email.
EDIT:
ah, just now read that you want to make this a webapp, in that case being closer to the metal isnt really helping, so nevermind ^^
Also, for anyone interested, Casey Muratori implemented such a system (though very simple) on C for his Handmade Hero game. It works by reloading a dynamically linked module on every frame. It's a model that should be adaptable to any compiled language.
>but I have to ship this thing by May 2023 come hell or high water.
Do you feel that you have to start working today in order to meet the deadline, or you can put a couple of weeks aside to develop your skill in whichever other language you'd like would be more adequate.
A big part of the value proposition is access to the entire JVM and JavaScript ecosystems. Bindings will be available for the more popular libraries, and if there aren't, well, Clojure is designed to make that easy.
It might not be pretty, it might not be idiomatic, but you're never going to hit a wall where "oh, if only I was using a popular language, I'd be able to do $obscure-thing". $obscure-thing is available for the JVM.
As a former Erlang developer it never ceases to amaze me that an entire language, standard library, toolchain, and runtime that's entirely dedicated to and on-paper perfectly technically suited for the most pervasive "backend" development challenges of our time somehow managed to effectively blow a 20-year technological headstart and failed to leverage the notoriety that should have come from several super high-profile "trendy" commercial use cases in the 2006-2013'ish era. Such that it's still relegated to general obscurity and is seeing its core competencies taken over by a hodgepodge of other languages and technologies that started much later but became rapidly more popular while also still arguably doing a worse job at those things than Erlang did.
I showed it to all my developer friends back around 2008 (I found out about it because a competitor used it and open sourced some of their stuff) and the only comments I ever got was how weird it looked. No one gave a shit about anything else. The story it told me wasn't about sales, it was about how shallow most developers are.
Once nodejs came out it was the final nail in the coffin - callback hell solves all your problems, no funny looking language necessary!
On the JVM you have languages like Clojure and Scala, which both are top class in their domains imho. I wish there was the same for the beam.
I wish clojerl were more than just someone's side project.
I simply like to put in a lot of focus during certain times to make the compiler understand what I'm trying to do and then go to "autopilot" later and have the compiler tell me exactly all the places I have to change (and often how) when I implement something new or fix a bug.
I actually really enjoy the assertive style of Elixir/Erlang. I think that while they are dynamically typed languages, the assertive style rests somewhere between dynamic and static typing, and in fact offers some safety benefits over your average statically typed language: while you don't get it at compile time, this idiomatic code offers benefits at runtime that most people don't bother with in other languages.
Maybe for example you have a good memory and I don't (I certainly don't). I forget things so quickly that it's always a huge hassle for me to be productive when I have to use e.g. python. That's just one example, there are surely other different traits of people that make them prefer one over the other.
Another one is that I really hate to write documentation and tests, except for very highlevel ones (UATs and high level documentation). The reason is that it gets outdated quickly and I don't like to keep it aligned. With types, they are automatically always aligned (the compiler forces me to) and it's easy to do so because there's lots of tooling for refactoring types.
Maybe other people actually like that part of the job and hence don't feel that a typesystem is helping them much.
The one innovation in it is the borrow checker - making it somewhat dependent on the quality of the compiler and adding a bit of noise to syntax for exchange in predictability of the code - and the cargo packaging system, unusual for a statically typed fully compiled language.
Anyone else read this and feel really old?
As someone who has used Nim in-anger and production at a couple companies now (and am currently using it to build our firmware for our industrial IoT sensor platform), I can wholeheartedly agree with this.
The first couple things I built in it at previous positions were small internal tools. They went well, team members contributed to them as well, things were good. It was that, plus the unique constraints of this firmware project that allowed us to have the confidence that it would work well -- and it has.
Of course, Nim is sort of cheating, as it being able to be compiled-to-C-sources means we have an out at any point we want, both in terms of being able to easily bind and use driver code from vendors, to wrapping up a Nim object file with a nice C header to call from some C/C++ code if need be.
Now: our backend is Java, and our front-end is Typescript and React. Pick your battles! If we were swinging for the fences with some other niche server side, and Elm or something (as much as I enjoy playing with it) for the client-side, as well as trying to use something non-standard for the firmware itself, I'm sure we would've failed immediately.
But we have our devices out in the wild in rural Papua New Guinea where no one's going to be flashing our boards for us, and they're working fantastically :)
If niche lang is so much better, then why is no one using it?
Well, quality doesn't necessarily lead to popularity. I would encourage talented solo devs to seek work in niche languages, at least once in their career. You can deliver more value, work with interesting people and solve more interesting problems.
Life is too short for Java CRUD.
The xkcd linked in the article had me laugh out loud. I hadn't known that one, it's great, and what it says about languages rings true.
Well, yes, there are. But picking the right language for the task is one easy way to improve software quality, so why discard it?
Also, for some issues and metrics, software quality is in fact limited in practice by the language used. Getting guarantees of certain properties is trivial in garbage-collected languages, near impossible in languages with manual memory management. Similarly, the lack buffer overruns and underruns, XSS exploits, properly following protocol, etc. are going to be trivial to guarantee in some languages, near impossible in others.
Now, I fully understand that following the hype wagon (or listening to fanbois singing praise about the latest tech, whether it's a language or anything else) is annoying. But let's not confuse hype and using the right tool. The intersection between those is often rather small :)
The language isn't all that important. The main problem is functional decisions that transcend the implementation language. It's not hugely important if I write this comment in English or French to get my point across, and that's why I'm writing it in English.
Beyond the random internet post (or the rare one, like "Beating the Averages", which might well be exaggerated) I haven't seen any obvious competitive advantages from choosing a non-mainstream language. On the contrary, what you often see is that immature ecosystems are huge timesinks because a lot of stuff simply isn't "there" yet.
That's not to say there aren't incremental improvements happening with new languages over time. But if your goal is to complete a project as opposed to evolving a language ecosystem I'd say that it's unwise to pick a non-mainstream language. Heck, I'm still using C for almost all of my projects (chances are I'd be using Java or C# if I was working in other domains). I've tried to switch - I have smaller and larger investments in a dozen languages. But no other language has stuck for me. A big reason for this inertia is that I simply know C well and I feel productive with it. But there are more objective qualities, some of which are related to it being mainstream and having a mature ecosystem. My language of choice has flaws, but they are well-known, with well-known workarounds. That lets me focus on the problem instead of the tools.
Blog posts generally don't consider these qualities because they can't be discussed with toy examples that show you how you can neatly turn an isolated problem from 10 lines of C code into a 2-line fancy language solution. The problem with these examples is that they are not representative of longer-term and larger-scale software development.
The additional effort to add tooling and workflows that most of the teams aren't comfortable with, extra effort implementing integration layers, might slow down delivery to the point of diminishing returns, thus withdrawing any advantage.
So while I personally might not like it, in some scenarios that is exactly the tool to use.
Same applies to other domains and whatever language might be the "to go option" there.
I think this is the root of the disagreement. For my domain at least, I find it very hard to write robust software in some languages and fairly routine in others.
Unfortunately the data on this topic is very limited - typically groups of college students implement something in various languages to compare. Hardly a realistic test.
What I can point to are code constructs that I cannot make in certain languages where the work arounds are either more verbose or less precise.
But you will be hard pressed to find a serious domain where there aren't solid mainstream tech choices.
> What I can point to are code constructs that I cannot make in certain languages
This is what I was alluding to, these examples are not very relevant. In a larger-scale codebase the important thing is the structure that you build, not the structure you get for free (or are being imposed) by the language.
If you cannot say certain things easily, then write a function to factor the common stuff in a layer that you can then build upon. This is the basics of programming, and from what I've seen this is already where it fails in most real-world codebases.
Functions and records (structs) are sufficient to cover you in almost all real world situations. I believe that the step up from assembly to higher-level languages is a very powerful step, because it frees you from doing a repetitive task again and again, that you can't even realistically do better than the compiler (because of time constraints), at least not on a large scale. Another reason that the step works is that what it automizes are quite local issues to solve. Barring extreme optimization requirements, we can simply come up with a function call ABI and have the compiler solve all register allocation for us. The tradeoffs and ramifications of this are quite clear - we can be confident by now that there are no unknown tradeoffs that will come haunt us later when the project has grown much bigger.
The same step up will be hard to repeat, since functions and structs are so expressive already, it's rare to find a problem that can't be elegantly solved using them. Garbage collection is another big help automating the repetitive in some domains, but it gets in the way in other domains.
One thing that's hard to express with them is a data type that's TypeA OR TypeB OR TypeC. For that you need Sum Types, which a lot of the newer generation of languages (Rust, Swift, Kotlin) have, but the older generation (Java, C#, C++) historically haven't had at all and still have poor support for.
I find this to be a significant productivity boost over languages that don't support this.
One thing I don't particularly about ADTs is that they remove opportunities to tweak the representation, and make you think less about smarter ways of avoiding certain complexities caused by choice (Sum Types) in the first place. But I have to admit that very often I'm simply doing the "struct with a tag member and a union member" thing manually, which one gets for free by using standardized ADT syntax.
This presupposes that the language even has facilities to enable appropriate abstractions! You can't argue that languages don't matter without reckoning with these real world matters. Yes, sure, I can just "abstract it away", yes, sure, "all languages are Turing complete so equivalent".... but no, that's not the whole story at all.
> The same step up will be hard to repeat, since functions and structs are so expressive already, it's rare to find a problem that can't be elegantly solved using them.
Expressive types are that next step up.
Maybe, sometimes, ... - in practice, I've often seen them pave the path to madness. When types become "expressive" the problem is that now you have to deal with 2 languages. An ok one and a soul suckingly bad one.
My thesis is that you need to pick the right language for the task and that language evolution regularly produces languages that are an order of magnitude better at some tasks than previous languages. To pick an extreme example, I doubt that you're going to code your next relational storage with pure C. You'll most likely use some SQL (or a competitor) somewhere in the stack.
And of course, as I believe we agree, the ecosystem matters a lot. In many, but not all, cases, it matters more than the language.
As usual, development is a matter of tradeoffs.
As everything in development, it's a tradeoff. I have written system code in JavaScript (calling directly into libc or kernel32.dll methods) and I don't want to ever do it again. I have written compiler code in C++ and the code was orders of magnitude worse than it would have been in a functional programming language. I have written database code (the actual dbms, not using a database) in both OCaml and Rust and I'd really prefer using SQL (or some layer on top of it), rather than reinventing it.
etc.
Just look at the market cap of YC companies started over its first 10 years and group by initial back-end language choices.
It wasn't dominated by companies using Java, .Net and PHP. On the contrary, those using Ruby account for over 50% of the valuation. Those using Python (a far less popular language then than now) accounted for another 17%. PHP, JS, Java and .Net combined were at under 5%.
https://twitter.com/logicmason/status/1371255029412233218
> "Stop wasting your time on programming languages"
"stop trying to fasc us out of having fun while being productive!" is my reply.
there are already enough people trying to improve software quality using rusty shears, let me use my fusion powered laser cutter if i want to!
In the end you just have to plow, and it doesn't matter all that much how you do it (as long as you use my preferred brand of course). Plowing tech isn't all there is to growing crop and vegetables. There is an awful lot more that you have to understand and plan and take care of, and upgrading your plowing tech won't help you with any of that.
Which XKCD? I read the article but missed it.
The XKCD: https://xkcd.com/568/
To stick with Java as the example, Java was designed with a set of affordances for managing mutability, complex inheritance relationships, and objects with rich behavior, and the coding norms and "wisdom" surrounding Java in the early years was based on that. Appreciation for immutability, value objects, and transformation rather than mutation came from outside of Java. That's my experience and the experience of the people I've worked with: our understanding of the value of immutability and dumb data came from working in languages that demanded or at least strongly suggested it and had elegant affordances for it. If we worked exclusively in Java, we would have been much less likely to realize the value of an approach that seemed alien and awkward in our language of choice. (Eventually, due to popular demand, better language support was tacked onto Java, but I'm talking about 10+ years ago.)
Every programmer should at least dabble in other languages and try to absorb the good big ideas from them, even if they ultimately put these ideas to work in "mainstream" languages.
This has naturally led me to prolog, but this is a very scary proposition for me to try and sell to the company though they have been very supportive.
It's a powerful tool but just so esoteric and I worry it'll be a pain to build a production grade system that can be worked on by someone other than myself.
Though trying to introduce clojure, as much as I enjoy it, would just be adding to my social woes :).
For example... by playing with a weird programming language purely for the joy of the craft?
You can do programming outside work, you know.
> Passion fades, but you’ll always need a job.
No and no.
The original post was about having fun with weird languages. If it were a post about windsurfing, would you advise people to check the availability/pay of jobs for programming languages/frameworks instead of going windsurfing?
> offer suggestions about the best course of action to someone.
I looked at D, Crystal, Nim, Go, Rust, Haxe, Swift and Zig (and C/C++, even Pascal). The language I liked the most (by far) is Nim, but unfortunately the niche community makes it a no-go for using it at my job, and the lack of hype like Rust makes me pessimist about its future.
The second most interesting languages where Rust (but the borrow checker and the amount of ', |, <, > intimidate me) and go (but for a weird reason I'm not hooked by its syntax).
My conclusion was that where I work (not a dev company), I can't use nothing but java, python and javascript if I want my code to be sustainable, and that I will keep Nim or maybe Rust/Go as a low level hobby
Edit: as a funny note, during my exploration i stumbled upon array languages programming languages like K, and I'm convinced there are mainly a scheme to guarantee jobs for people using them
https://github.com/vercel/ncc
I'm trying to think back to when we all started moving from Perl to Python and it's been so long I can't even remember what that looked like and if it was senior developers driving that or just a subconscious decision and happened "magically".
https://julialang.org/
I like Nim too, but it needs more adoption.
I came to Java as my 6th or so language (small amounts of Basic, VB, C, Assembly and Javascript before) and while I absolutely didn't like it in school, once someone told me how it was supposed to be used (rely an a real IDE) it became much easier.
I still continued to dabble in other languages (mostly php and python), but these days no way I would go back to Python.
What really makes me pessimist is the fact that software development decisions are increasingly hype/marketing-driven than based on technical reasons.
For instance, TFA suggests sitting down with a pot of coffee to read the language docs sequentially (they were written by a hermit). This is also a great way to try to familiarize yourself with a mystery system.
The author recommends paying attention to building your workflow, since you'll be figuring things out as you go and the cost of forgetting details is high. I've found the same to be the case when working on integrating unfamiliar systems: early investments in automation and testing pays dividends.