Do people decide to go to work for a company based on the language they'll be working in? Seems like something that should be very far down the priority list?
Just like I'm sure many people would reject jobs that would force you to write assembly code now when we have higher abstraction languages, I reject jobs that are requiring me to work with inferior languages and ecosystems like Rust, Go or JavaScript. It's simply not worth the frustration anymore.
In the beginning of my career I didn't have the flexibility to choose what languages to work with though, but nowadays I am that lucky.
They are not lisps :)
> What if you need performance
Choose a lisp that gives you performance. Clojure gets you about 80% on the way there, for the rest you can use Common Lisp if you really require performance. I've found that Clojure usually does the trick if you optimize it a bit.
> Or even a community at all
Clojure does have a community, not sure what you mean? There are forums, chats, Q&A sites, blogs, people on Twitter.
> libraries and support?
Plenty of battle-tested libraries with stable APIs, and loads of companies that offer Clojure support (not to mention the great public community that can also help with most if not all questions).
Have you actually used Clojure in any capacity? These points seems to be coming from someone who haven't actually tried to get involved.
As long as it's s-expressions and interactive development oriented, I'm probably fine with it.
But for the last 4-5 years, I have literally not found a single use case where I'm forced to use C++ or Rust since multiple other (lisp-like) languages has the same target market and the ergonomics are just so much better.
I use C++ to write realtime audio processing applications, especially DAW plug-ins. This is hardly C++'s primary market, but AFAIK there are no lisp-like langauges that can compete with C++ here. I'd be happy to learn something new if this isn't the case!
It would help if you outlined what's missing from for example Common Lisp in order for it to compete with C++, then maybe I'll be able to give more helpful suggestions that will help you.
This is why managed languages like Lisps are rarely (if ever) used for the DSP in audio applications. I am an audio programmer who loves all things lispy, so believe me, I wish this weren't the case.
Linux is written in C, and, perhaps someday, Rust.
Linus doesn't like C++ and has explicitly objected to, among other things, its enthusiasm for implicit allocation. Rust's implicit allocation all lives in libraries and so the Rust for Linux project ripped that out.
What type of shortcomings? Can you provide some examples?
(The question is coming from someone who wrote a Scheme interpreter in the past, but have been using Python for the last 8 years and haven't touched Lisp in long time).
With a more mainstream language like Java, you're not necessarily going to select for that trait. This isn't to knock Java engineers, since I know a ton of Java engineers much smarter than me, but that fact that Java (JavaScript/Python/C#/any-other-mainstream-language) is popular means that a lot of people learn it because there's a lot of jobs in it and/or it pays well. There's nothing wrong with using a language that makes you money obviously, and there's nothing wrong with liking Java, but as a perpetual-geek I am certainly less drawn to "Java Shops".
I have been in the fortunate position of being able to provide employment to others (and myself) in several companies. I don't exploit people, I offer wages as competitive as possible, I hire people from non-traditional backgrounds and mentor employees who probably would not get the attention of other large tech companies.
I am not a saint and admit I may be clueless about some things. Providing a workplace that is safe, free of discrimination, rewards people for hard work and supports those who are in need of help are areas I think I do have a clue about.
If you're doing application development, it's nice to have a language that truly cares about backwards compatibility and interoperability with a common platform. It means I can focus on solving problems and not incidental complexity. I can easily hack Clojure from the comfort of a pom.xml if necessary.
I'm not working in Clojure right now because I found interesting work outside of application development, but when I was last looking in 2018, I could get roughly all of the things I wanted from a job and still hack Clojure from a CIDER REPL in Emacs all day.
I was wrong and the company was the worst professional experience of my ~20 year career. Now I vet my future employers' tech stack before signing any papers. It doesn't have to perfect (that's what I often come there to improve) but it has to be not shit, and they have to accept that fundamental problems need to be fixed.
So it's very hard to land a job in a language I don't know. It's all pretty stupid, for the most part any software engineer can pick up any new language pretty quickly when working 9 hours a day on it. The language is the easy part of comp sci.
I'd love to take a job in Android or web development but I just don't have experience so I don't get interviews.
Not entirely. It's a proxy - and a window - on the company culture.
You're most susceptible to intellectual bullying in this stage. It's really what makes switching jobs the worst part in programming: you look like an idiot no matter what the first week or two, and are completely at the mercy of your manager and team culture to sink or swim.
Add a new language as ammunition to be intellectually bullied? No thanks.
I stay away from those people, not going to lie.
Every place I've worked at, I only applied after asking a) what language do they use b) is it technically cool.
Edit: Just to clarify, the comment was a joke but yes, devs for sure reject jobs at prominent workplaces because of tech. I myself know a highly attractive workplace that want me to join but I won't because I don't believe in their tech stack.