Every time I see these (LFE, Elixir, perhaps others) mentioned I feel sad that people don't seem to see the beauty in the Erlang language itself. Learning Erlang was a watershed moment for me and it had little to do with the actor model or OTP.
That should not be meant to take away from these other projects that do interesting things. It just seems like people needlessly avoid Erlang because it's unfamiliar and they miss something amazing in the process.
I find Erlang a harder tool to shoot yourself with than Elixir yet there are definitely some things it could improve on, and not only at the language level (always running xref on compilation would be nice).
An "atom" is an Erlang/Elixir thing, kind of like an enum value. "true" and "false" are implemented as atoms, you might create atoms to represent connection states ("idle", "connecting", "connected", "disconnecting"), or to represent errors ("file_not_found", "no_permission", etc). It's a really useful thing and something I miss in every language that doesn't have it.
In Erlang, a variable is a token that begins with a capital letter ("UserId") and anything that begins with a lowercase letter is either a keyword ("if", "case", "end") or an atom. Since keywords are a finite set, this is pretty straightforward. Module names and function names are atoms, so there's no additional complexity there.
In Elixir, a variable is a token that begins with a lowercase letter, unless it's a keyword or one of the special atoms "true", "false", and "null". An Elixir atom either starts with a capital letter (typically module names) or has a ":" in front of it (":file_not_found") or has a ":" after it when used as a map key ("file_error: :file_not_found" -- both words there are atoms).
So the problem that I run into is that identifying whether a token is an atom and, if so, if it's the same atom as in another spot, requires more thought than I think it should.
My Elixir experience was that there were quite a few cases like this where I hit minor friction. In general, I felt that Elixir code is a little easier to write but a little harder to read and Erlang code is a little harder to write but a little easier to read. I feel like the latter situation should be much preferred.
This is just coming from an Erlang background. For those of us who came from other languages, atoms are often implemented with the colon syntax (ruby, julia)
The reverse colon syntax was a bit wierd, but it (and including the parser assuming that it's in a list when it's the last term) make parameter lists buttery.
Well, I do of course see the beauty of the Erlang language; it is a simple, concise and consistent syntax. However, I also like Lisp being an old lisper. Lisp was actually the first high-level language I learnt. So LFE is an attempt to get the best out of Erlang and Lisp, at the same time.
I love Elixir, and I've played around with Erlang, but only very briefly. What made learning Erlang a watershed moment for you apart from the actor model and OTP? What do you think are the most elegant parts of Erlang?
'Elegant' is probably not a word I would choose, although it may apply at times. Erlang was the first place I saw pattern matching and is also how I came to actually understand list comprehensions, although I'd seen them elsewhere. There were other little things. And I liked the syntax! I don't think it was any one thing though. It was more the way things worked together, and worked much differently than other languages I had worked with. At that point I had been a programmer for 10 years and felt kind of jaded. Everything seemed fundamentally the same. I was even surprised now not-weird Lisp was when I finally got around to it. It seemed like once you get to a certain place with programming you think you basically have it all worked out and everything becomes implementations details. And then something comes along and shakes that understanding. It's that shake that I was grateful for. It was a personal experience. Others have probably had that with Haskell, etc.. I hope everyone gets to have that now and then.
Erlang is a very ugly language with brutalist, esoteric syntax. If Erlang adopted a C-like syntax (like nearly every other successfuly language in the world) it would see much wider adoption.
C is a very difficult-to-parse language for both humans and computers and its syntax family got popular as much from circumstance as anything else. JavaScript stole Java syntax to court Jaca developers, Java stole C++ syntax to court C++ programmers, C++ stole C syntax to court C programmers and now you have most of the biggest languages of the past 20 years using C syntax because C got big back in the day (and it didn’t get big because of its syntax).
Modern C-family/Algol-family syntax is nice but I certainly welcome trying out other syntax families (in the case of Erlang, Prolog-family).
Erlang syntax indeed seems a little strange. But it's only because today we are accustomed to languages with much more usable/friendly syntax. But when Erlang was born in the 80's the usability wasn't much of a concern yet for programming language designers. Compare popular languages born in the 80's such as C++, Perl, Tcl with the languages born in the 90's such as Python, Ruby, Lua, Haskell. There is a clear pattern. Later languages are much easier to read and write.
Jamming C syntax into everything is how we get eyesores like ReasonML.
A syntax should match the semantics of the language. C style is not the only way to design a programming language and does not fit all domains and semantics.
Brainfuck is esoteric, C++ Template Metaprogramming is pretty esoteric. But once you wrap your head around the pattern matching, the erlang syntax becomes pretty straight forward. I found it interesting because it explicitly didn't look like a C-derivative. The only thing that I think can be a bit cumbersome are specs and types.
I am not really a fan of clojure and I much prefer the Erlang concurrency model to the options that clojure gives you. I don't agree with Rich Hickey here. And I prefer classic lisp syntax to clojure syntax.
But clojerl does give you the chance to run on a better VM so in that respect it is good. ;-)
It is NOT, is cool that you love Clojure, Scheme or Common Lisp but LFE is not a re-implementation of any of those things nor envy any of the features on them.
LFE is a clean, beautiful an proper Lisp for the complete BEAM ecosystem.
I love this. But go ahead and have a look at the "Who's hiring" post and you'd be correct to think that investing in languages like Clojure does limit your career choices.
It's depressing I know. I will always write my personal projects in Clojure but it's a shame that I can't rely on it as the primary means of making a living.
I’ve used Clojure to complete coding challenges that ended in getting hired for full-stack engineering positions, twice. So it’s shown some value there.
Aside: If you let yourself get spoiled by Clojure’s efficient data structures and concise functions for manipulating them, it can be really frustrating to work in other languages that aren’t so data-oriented. It feels like it takes forever to “get to the point” when reading most traditional web application code.
On the other hand, if you have some flexibility with the program design, you can get many of the same benefits of Clojure in traditional languages by applying Clojure’s data-oriented architecture lessons (it feels almost as good as doing Clojure at work). Even frameworks like Ruby on Rails can be bent with minimal strain to fit the data-first paradigm; it does, however, require some departure from convention.
Finally, you can always use Clojure as a secret weapon at your own startup. One of the primary benefits of Clojure is the extreme simplicity of design, and conceptual compression you can achieve as a result. This allows small, even single-person, teams to build and manage an impressive degree of functionality with decent performance. Keep at it part-time, and you’ll grind out a solid MVP in a few weeks.
Clojure is my favourite language by far but the community's apathy towards web frameworks continues to do serious damage to its chances of widening adoption. There is Luminus but it's at best a curated list of libraries and the community refuses to throw its weight behind it. It's good as far as it goes but it will never compete with Rails or Django. There's a kind of smug pride in the Clojure world that "we don't do Rails", prefering instead to build everything from the ground up with libraries. Good luck with that one. Look at how few Clojure jobs there are at Indeed.com or Angle.io. Maybe, just maybe, this attitude might have something to do with it.
DHH wrote Rails. An individual. Not a community. Granted, a community grew up around Rails, but it took one person to get it started. The "DHH of Clojure" position is there for the taking. Are you the one to do it?
A community is a group of individuals. If you would like to see something like Rails in Clojure, there's nothing stopping you from writing it. "We don't do Rails" is as much a number of individuals not finding a use for a Rails-like framework as it is someone not having written one yet.
This isn't language or community specific. If there's something you want to see, write it! Expecting others to meet your needs smacks of entitlement. I find it much more empowering to think of areas for improvement as opportunities, rather than expecting everything to be handed to me.
As for job opportunities, some people value ease of getting a job, while others favor working in a language they prefer. Recognizing which you prefer is important, as is recognizing that others may not share the same priorities you do.
Sounds like you're not fine with that. What are you actively doing to change the situation? I saw your comment from yesterday and was prompted to respond when you made the same complaint again today. I sympathize with the frustration that it's not everything you want it to be, but it won't change unless the individuals who make up the community work to change it. Believe me, I have my own list of things I want to see improved. But I think it's more useful to dig in and try to make those improvements: if nothing else I learn a lot in the process. I encourage you to join in improving the situation :)
It's pointless if the community ethos is working against you. What good is one man's efforts if the community isn't interested in a full-featured framework? There was a lot of noise about Arachne a year or two ago and that died a death. The Clojure community lacks ambition in that they're content to work in a libraries-only niche and let the jobs go to other languages. Fair enough but that's not where I want to spend my time.
> "What good is one man's efforts if the community isn't interested in a full-featured framework?"
The community that grew around Rails didn't exist in the Ruby community prior to its release. Many discovered Ruby via Rails, not vice versa.
IIRC, I was first exposed to Clojure though the extended Ruby community, having been exposed to Rails. I also recognized that while Rails was useful for some things and introduced me to some good practices that spread through the Ruby community, I also came to think that the MVC pattern encouraged by Rails is actually an anti-pattern: one that works well in some cases but doesn't actually encourage one to learn better application design, that one molds the application to the framework. Applying that to Clojure, I personally haven't seen a great way to make a generalized framework that does encourage good application design. Just porting Rails MVC framework from Ruby to Clojure isn't something that interests me. But that's just me. I don't expect others to necessarily share my opinions. If I see something I want improve, I write a library or submit a patch.
Again, I hear you blaming the Clojure community for something that individuals need to do. Have you hired or contracted someone to design such a framework? Is it something that you would use personally? What would such a framework look like to you? I was glad to hear about Arachne, although what I heard didn't sound like something I personally would enjoy using. I've found some success using Pedestal. One of the reasons I think Rails was successful is that it was extracted from a successful project. What I hear comments such as your doesn't necessarily reflect this, that it almost expects something written ex nihilo. In my experience, those generally aren't as successful.
When I hear "The Clojure community lacks ambition", I frankly see that reflected in your own comment. Where's your ambition? Why expect that of others and not yourself? I guess I'd ask you to be part of the solution rather than pepper comments with complaints, asking things of the community rather than being an active participant. Be the change you want in to see in the world.
Having used clojure for quite a while now I both agree and disagree. I agree that these very productized, opinionated, monolithic libraries/scaffoldings are great in getting people to use your language and clojure lacks them. OTOH I think it does lacks them mostly for the right reasons. Libraries just being a bunch of functions/macros you can use anywhere you want is what's great about lisp/clojure. Personally I hope the clojure community puts less emphasis on ever becoming a mainstream language and instead focuses on making sure it's THE modern viable lisp for years to come.
I think it’s perfectly possible to have a career in Clojure in London. But, of course, I couldn’t advise anyone to move to the U.K. until the final state of Brexit is known.
Don't choose a language because it will make you money. Choose language because it's something to learn and you'll enjoy programming in it. You can know more than 1 language. The main one is that which will earn you an income. The other, or others it to play and enjoy what the language and environment has too offer.
Look on the elixir job boards, slack and forum. Some companies are hiring for multiple roles. E.g Whitehat are hiring 10 more devs, Toyota are building a team of 20. Etc. There are more open positions than Elixir devs in London atm.
Even in London there are only a handful of Clojure jobs. Clojure growth has stagnated. Likewise with Elixir though Elixir has a better chance in the long run due to the community's support for Phoenix.
After three years of trying to push for adoption, I’m also starting to find it depressing. I’ve talked with various people also looking to introduce Elixir or Clojure in my workplace (large company), and even when it’s a perfect fit for the problem, we invariably hit a wall because it’s not popular enough to be considered seriously. Anything not in the TIOBE top 10 or so might as well not exist.
It's easier to ask for forgiveness then for permission. Next time you get a project, just do it in Clojure or Elixir, don't ask.
The beauty of this is, if you are using the JVM, JavaScript or Erlang, it doesn't even have to be green field. You can just write a section of the code in it.
Call me old fashioned, but as a developer if I did this I'd feel completely responsible if it didn't turn out well. Not just to the company paying me for my work (which apparently I feel free to do in whatever way I like?), but also to my coworkers who may have to manage more complexity because of my choices. Imagine if everyone on just a 5 person dev team did this... pretty risky, and potentially company sinking behaviour.
I've experienced this ethic in others and it sucked (and the person basically shrugged and walked away). Obviously this could work out well, but I suspect most of the time it doesn't.
I'm sure there are situations in which it's perfectly fine though. Like working on your own on a fixed quote greenfield project.
Well, you would be responsible if it didn't turn out well. This obviously assumes that you can pull off a successful delivery. But I feel that goes for any project you take on. It's all about calculated risk. If you don't know the language at all, maybe don't do it on a task where you wouldn't have time to pivot back to a language you know if you didn't succeed.
And if it added more complexity, well then it was the wrong technical choice that you made. Normally people switch to Clojure[Script] and Elixir in order to lower complexity and help manage it. If for some reason your project would get more complex with the switch, then don't. I mean, why would you want to switch to a language that you thought would make the code worse?
Finally, I guess I see myself as employed by my company to specifically make such decisions and bring about positive change.
Also, it's okay to say that you're bored, and you need to keep learning and challenge yourself to your employer, otherwise you'll get disinterested and might look elsewhere for work. And this is a way for you to learn and be motivated which costs nothing to them. I mean, that one you can only do if you're valued on your team, but if you are, and I think you'd be surprised more devs are then they think. It's an option.
Now, there's ways to do this that work, and won't feel like a big jab at your employer and your co-workers, but it's not easy, and there are risks you have to be willing to take. I did it at my current job. It does take extra effort on my part. Give other devs good support and mentorship when they need to maintain that part. Plant the seed in their minds beforehand. Let them know you started doing it in a different language, and how it's going. And make sure the end product is good, and explain to the business that it was successful in less time, because of the language choice you made. Etc.
I’ve been through that already for a relatively minor project and been asked not to do it again, even though the project worked out very well. The problem is we end up with something that can’t be properly maintained if I leave, and even if it’s a small service, it tends to grow in scope. Sadly we don’t really use any of the VMs you listed either.
People around me don’t doubt that you can do cool stuff in Elixir or Clojure, they just think it’s too hard to hire for these languages, and that the same is possible in any scripting language with Redis, Kubernetes, Kafka, etc.
> Sadly we don’t really use any of the VMs you listed either
That might be too much to ask then. A change in runtime is much more difficult then a change in language. That's also the beauty of hosted languages like Clojure[Script] and Elixir. They give you a painless transition which doesn't need new infrastructure, and you can slowly adopt them for parts of your code.
> I’ve been through that already for a relatively minor project and been asked not to do it again, even though the project worked out very well
I think it's important to emphasise the benefits. This would have taken me twice as long without X language. X language allowed it to be more robust and suffer from less operational issues.
Also the business shouldn't know about the language choice as much as possible. You can say things like, because of our use of the Clojure[Script]/Elixir technology and library, the project was delivered twice as quickly.
> they just think it’s too hard to hire for these languages, and that the same is possible in any scripting language with Redis, Kubernetes, Kafka, etc.
For this it helps to emphasise ease of learning, and quality of engineers. Something like, any talented engineer can pick it up quickly with minimal overhead. If an engineer can't pick it up, they might have been a bad hire. Engineers interested in such languages are normally more passionate, polyglot, and are continuously learning on their own time. They're most likely better engineer then the average, and this is actually a good way to appeal to such high quality talent and recruit good engineers.
So basically, you have to be a good marketer and leader, since you'll need to evangelize and lead people into adopting the new language, starting with a good hand off to the next person needing to maintain the code.
I've done many of these things, documenting the arguments, evangelizing and building up enthusiasm in my team (I didn't write the Elixir system alone), etc. but was still told by our lead engineer and technical managers not to use the language for new systems. Some arguments I heard:
* Even if we can find some people excited about a minor language right now, what about in 10 years? The language could be abandoned and nobody would want to learn it. If we use a popular language instead, we know we'll be able to maintain the systems and hire people for a decade or more.
* It's already hard enough to hire average engineers fresh out of school, let alone experienced, polyglot ones.
* We couldn't reuse internal libraries in popular languages so our systems would take more work, and other teams wouldn't be able to help us.
* Kubernetes / Kafka / Redis are language-agnostic and more powerful than OTP supervision / messaging / ETS.
IMHO some of these arguments are flawed, but it's been difficult getting the more resistant folks to actually consider the pros and cons and not just toss the idea aside. Your comment about hosted languages is a great point though, and your post makes plenty of sense. Thanks for the motivation :)
Well, it looks like you did try hard then. You definitly get my respect for that. Your company and leadership sounds simply too stubborn.
In that case, I think there's only three options.
1) Resolute yourself that you won't be working in your preferred language. And try instead to find satisfaction in other aspects, such as your designs, maybe bring in some functional influences, adopt more data driven patterns, etc.
2) Look for a more open minded place to work. Honestly, that might be a good career move. If all they can hire are new grads or mediocre coders who can't pickup a new language, what's in it for you? Who will you learn from? Remember, 10 years from now, do you want to have 10 times the same experience, or 10 years of experience? If the latter, it means every year you have to be given an opportunity to take on something you don't know, that's at the next level of your capacity. Which allow you to grow, learn new skills and master existing ones.
3) Work to gain trust and leadership yourself, until you are in a position with the right authority to make the decision your own.
I think all three are fine choice by the way. With different trade offs of risk/reward/effort. It's a personal choice. I'm just listing them, because sometime we don't realize there are options.
Learning alternative languages opens our mind to architectures and approaches to solutions that we wouldn't though of when staying in a silo Developer X.
As for making a living in Clojure, there a couple of places in Europe using it, HN "Who's hiring" isn't the only source of job ads.
Every Java, JavaScript or Erlang shop is possibly a place where you could start using Clojure or Elixir though. But you'd need to champion it yourself.
That should not be meant to take away from these other projects that do interesting things. It just seems like people needlessly avoid Erlang because it's unfamiliar and they miss something amazing in the process.