You’re right, maybe we are comparing apples and oranges.
But it depends on what perspective you are seeing. Is it paradigms? Totally apple vs orange.
Is it server side programming? Totally not, we are evaluating two different tools and what they have to offer.
And thanks for the F# code! I’ve never looked into it (out of pure prejudice, I must admit) but it is pretty neat. Easy to read, easy to follow.
But there is one key distinction there:
That piece of code opens up an HTTP client every time isValid is called. The code from Elixir is 100% different. The is_valid? from the code I’ve written doesn’t open any HTTP connections. All possible mimetypes are compiled as bytecode from the module source, which only fetches them once. In fact, this technique is used by Elixir authors to properly support UTF8.
Now, maybe F# is great and also has a macro system and homoiconicity. But there is also one thing you can’t beat: Erlang VM. The Erlang VM can give your programs some reliabilities (supervisors, workers, fault tolerance, automatic restarts, distributed goodness) that the CLR just can’t.
And that’s ok! They were built for different problems, anyway. It all depends on what you want to achieve.
I’ve heard this argument a few times–“why should I learn FP language x when I can do all of that stuff in my existing language y”? The simple answer is that FP languages support primitives that make it much easier to work in a functional way. There are a few things that FP languages support:
1.) Default immutability.
2.) First class functions
3.) Lambdas
Now they can tack several FP features on to C# but C# will never be immutable by default. And as long as it’s not immutable by default, developers will continue to write mutable code because developers aren’t going to fight the language. Developers will take the defaults unless there’s a very good reason to do otherwise. Most developers accept side-effect errors as a fact of life since they’re mostly accustomed to writing imperative code.
Have you ever tried passing a function or returning a function from another function in C#? The syntax is very clumsy. Even in F# (which is still a .Net language) the syntax is much cleaner and therefore easier to follow.
The “there are lots of jobs for C#” argument is hard to debate. They’re right–there are lots of jobs for C#. But by that reasoning, there are highly paid jobs for COBOL and FORTRAN too which are going unfilled. So why bother to teach young people OO and C# when you could be teaching them how to work with COBOL and FORTRAN and they could be making lots of money.
Just wanted to weigh in. As a long time C# developer, I sincerely hope that we can get past C#.
yep learn one functional language and you will never want to go back, but you will be forced to every now and then
They lured me with haskell in the first semestre but now? I have to use C for openGL, some of my co-students have to use some other C-like language for an embedded device. Firsties are teached in Pascal, Haskell is only shown to a handfull of students. Java for OOP. As far as I have heard situation is even worse at other universities, where different paradigms are teached using the same language…
And to be honest, I like it beeing trained to stay diverse. I’ve seen people loosing their jobs because they weren’t flexible enough…
I can only guess, but I do think that it does depend on at least one of the following:
Rust is not officially taught on my university.
Rust would make the graphics course unnecessary complex due to life time restrictions
There is no LLVM code gen available for that device, only a propretiary compiler for that C-like language
Rust is not available in official Ubuntu 14.04 repositories
Rust is much newer than the current curricula (my curriculum is from 2011)
No sane student wants to learn a new language AND a new topic at the same time
Most other students at my university appear to be very monoglottish… Evangelizing the language used at their sidejob while using languages taught as less much as necessary and as less as possible…
I know this is a couple months old, but I’m surprised no one mentioned “async” in this. This, for me, is the shining attribute of Elixir/Erlang. I’ve been mostly in the C# world for the past decade or so, and I’ve been writing multi-threaded code using BackgroundWorker, callbacks, and more recently async/await for a long time (in Delphi before that as well!). But in my eyes, those kinds of constructs and others, e.g. mutexes, semaphores, critical sections etc., are basically afterthoughts from the transition from single-threaded procedural paradigm to more and more multi-threaded one.
I am loving Elixir/Erlang because it doesn’t add asynchrony on top of something else…it IS asynchronous! And I am a hard-core OO dude that doesn’t hate FP stuff…I just didn’t grow up that route. But the most common issue that I’ve run into with FP is handling state. In even simple examples in most FP languages, state on a project-wide basis seems at best to be tricky to handle properly. Elixir has addressed this with Behaviors, and specifically the GenServer and Agent (which I believe is built on GenServer anyway). It’s like the best of both worlds…FP with superb, and natural state-handling capabilities. And asynchronous coding has become much more straight-forward, because it does these things (mostly) transparently - though you still need to be aware of race conditions and where the asynchrony is happening.
I’m not an Erlang expert, but I think the Beam+Actor Model architecture is the best for its asynchronous design. And Elixir (and its community) is adding to that awesomeness some really excellent options making it much more accessible to those of us from the OOP world.
For me comparing these two languages is like to compare whole programming paradigms. C# is different than Elixir, so you can learn it as well as and use when it’s useful. Languages are tools- don’t try to solve every issue in home with hammer. Same story here- Elixir will be great to other things that C# is.
You have to play inside the fence defined by C++, Java, Python, and JavaScript.
i.e. anything not in that list cannot be the “right tool for the job”. And in many environments the selection of sanctioned languages/tools is even more restricted than that. For stakeholders “can I readily (and cheaply) hire developers for maintaining this” is a significant aspect for “the right tool for the job”. For Google this even became a primary consideration in the design of Go:
It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical.
So given the existing install base of solutions already implemented in C# and given that developers familiar with C# are more readily available make it much more likely that C# will be used for something that F#, not to mention Elixir, is better suited for, not the other way around. So that gives C# has a huge advantage.
Elixir may need some help from people who also handle mainstream languages like C# in order to infiltrate the mainstream (rather than, for example, poaching the Ruby/Rails community) in order to “cross the chasm”.
For one it would be nice (and helpful) if Erlang was considered less niche and more mainstream. According to Bryan Hunter in his presentation CQRS with Erlang: “60% of the world’s mobile traffic is going through Erlang” - that should make it worth paying more attention to (but that didn’t seem to generate or require a tsunami of Erlang developers). Elixir as a “more accessible Erlang” should benefit from a wider awareness of Erlang’s maturity and capabilities.
Yep I agree this is Google primary stack and I don’t think so they move something beyond this.
But it doesn’t mean than any can’t contribute to other languages for their’s APIs.
In fairness (and yes I am splitting a hair here), F# is both more and less than OCaml on the .Net platform. F# adds Active Patterns (there’s no such thing in OCaml as far as I know). F# has modules like OCaml but the focus is more on namespaces which is in keeping with other .Net languages.
And, of course OCaml isn’t tied to the CLR. While Microsoft may argue otherwise (especially these days), CLR is still pretty much de facto Windows and Windows only. Yes, I know their efforts to port to Linux–but I also know that their efforts are still pretty much at the proof of concept level for now and it’s likely to be that way for the foreseeable future.
While I quite liked Elixir/BEAM, I’ve actually gone with F#. It’s a statically typed functional language, supports lightweight processes, reasonably simple to use Actor model via orleans, there’s lots of tooling, and can leverage a large amount of libraries which allows integration with lots of things in a mostly effortless way. MS is pushing everything open source and cross platform as well.
Elixirs advantage is not really that it has BEAM / LWP / Actors etc… it’s that most everything gets built with that model in mind. Which is nice, F# doesn’t have that as it’s a smaller player in a larger ecosystem, so most things don’t explicitly take advantage of F#s capabilities/philosophy.
When it comes to actual coding… you can write in a very similar style in both, the main thing I like is the static typing in F#, which despite all the arguments for not having it in Elixir, it still helps eliminate errors.