Lisp-Flavoured Erlang
lfe.io
lfe.io
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.
It’s not a dislike of Erlang as much as it is a joy of Elixir situation.
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).
Can you please elaborate? I was of the opinion it was the other way around.
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.
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.
The atom for "null" is actually `nil`.
For those who are not familiar, in Elixir you can write
result = value
|> f1()
|> f2()
result = f2(f1(value))
so if you wanted to check on on the values you can do this:
result = value
|> IO.inspect(label: "value")
|> f1()
|> IO.inspect(label: "result-of-f1")
|> f2()
|> IO.inspect(label: "result-of-f2")
Pattern matching and immutability are pretty sweet aren't they? So is homoiconicity and macros.
Did I suggest otherwise?
Personally I like the Erlang syntax better but most colleagues find it weird.
Modern C-family/Algol-family syntax is nice but I certainly welcome trying out other syntax families (in the case of Erlang, Prolog-family).
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.
So Erlang syntax feels natural, I just don't have any use for it on my line of work.
LFE is a clean, beautiful an proper Lisp for the complete BEAM ecosystem.
But clojerl does give you the chance to run on a better VM so in that respect it is good. ;-)
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.
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.
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.
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.
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.
* 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 :)
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.
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.
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.
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.
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.