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
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#.
If only there were some F# jobs somewhere. F# compared with C# is like having Einstein and Bozo as brothers
I was already committed to learning Elixir, but reading the reactions here has motivated me even more to explore and learn Elixir
@Ilyes512 yep learn one functional language and you will never go back
I’d say it a little bit different:
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…
Yes you are right you will never want go back
Why not to use Rust instead C?
Rust is a great system language! You get native speed, and no freakin’ SEGFAULTS. That ought to be at least tempting.
If you’re doing embedded and willing to go full crazy, why not nerves?
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 have some stuff flying around I like to do using nerves/rust. But I need to wait for some better conditions:
- Nerves need to support the Pi3-Cam
- Nerves and Rustler need to work together
- Rustler needs to keep up with rustup.rs
- I need to have much more time
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
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.
Jet.com is hiring F# devs
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.
That’s a great point. If I lived in NYC I would definitely contact them. But I am in Michigan and they won’t consider remote workers.
It’s a nice notion to be a Language Agnostic who will pick the right tool for the job but I would expect that many if not most developers don’t have the luxury of that choice (provided they cared). For example in 2007 at Google:
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.
It is also wise to remember that the “right tool for the job” is difficult to discern when the job itself is so often poorly defined.
Just keep in mind that F# is just the translation of (O)?Caml for the .NET platform
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.