Idea people are most of the time really creative. Creative people are most of the time more chaotic. This article is all about a well balanced team composition in the end. A team full of code robots does not work and a team full of 'idea people' does also not work.
Most of the time my C# code uses most of the functional paradigms. I write pure functions when i can and use LINQ almost everywhere. Recently i created a F# API with the dotnet CLI, but the syntax is not even close. I get the concepts, but syntax is a little bit to much to just try it when i have to write a new microservice. Am i the only one?
F# syntax is so much better than C# for functional programming - and arguably for object programming too. However, it is sufficiently different that you really need to jump in with both feet. Don't assume it will be easy because you know C#. However, once you start to grok the syntax, you begin to see how the language features elegantly tie together, and the language design decisions make perfect sense. Unfortunately, you just have to take it on faith that this moment will occur... you can't see it unless you put in the time to learn it.
This different is a big thing. People learn C#, Java, JavaScript, Basic, PHP or C/C++ early on their carrier. Hoping between these is hard but not because of syntax. Hoping from this OO gang to a modern functional syntax is brutal.
I think key to proper functional adoption is wide range entry level adoption (and not only university).
Indeed. And sometimes these same people will claim, based on their experiences only with the OO gang, that PL choice doesn't matter! If this is you, set aside an afternoon and try a Lisp or something from the ML family, it might change your whole perspective!
(I wrote this without realising that you specifically meant "syntax for functional programming". Sorry.)
Syntax is fairly different but the concepts are broadly similar. Rust has many of the same nice things as F# does, like "if" as an expression rather than a statement, algebraic data types, mutability declared as a keyword, etc. In fact Rust is much stricter with the "declared mutability" thing, because in F# you can use an immutable reference to a mutable object to mutate the object.
The really big paradigm difference I found as an F# person when starting to learn Rust was the lack of guaranteed tail-call optimisation, meaning that Rust kind of wants you to avoid recursive functions. I also find it much more annoying to write sequences ("Iterators") in Rust than in F# (where the `seq` computation expression makes everything ludicrously easy at the cost of some oddly bad performance sometimes). F#'s anonymous interface implementations are also really handy, but Rust's situation there is at least no worse than C#.
Rust is influenced by OCaml but has lots of C++ concepts thrown in too. I don't think it makes sense to be choosing between OCaml/F# and Rust since they are so different. If you need the performance characteristics of Rust, then the choice is made for you (and you should also consider modern C++). If not, then the borrow checker is probably a burden that you don't need.
Maybe I'm missing something. Under what use-cases would someone be choosing between OCaml/F# and Rust?
I don't think I ever would, I just knew they had common heritage and wondered if that was evident to the developer. I've been a professional c++ dveloper for the last 18 years and I've got a couple small projects now that we are using rust for. I know enough to modify rust or fix bugs but not to create an idiomatic design in it. If I don't need the speed I am usually prototyping so I use matlab. If I don't the speed and I'm not prototyping I use python, but that isn't often. I think Julia might end up having a spot in that range of options but c#/java isn't enough faster than python or enough easier to develop than c++/rust for me to consider it unless I need to use existing code.
Rust is kinda like F# with curly braces and no garbage collection. =)
There are many more differences than that, but definitely if you know F#, Rust feels very familiar, and vice versa.
Yeah Sway looks really appealing to me since i'm already using i3wm. But every now and then i'm searching if screen sharing on MS Teams already works. As a Software Engineer in this pandemic i rely a lot on screen sharing. But every time i search for it i find out that it still does not work (without a work around). That's basically the only thing that holds me back. Does anyone know if Sway or Wayland is trying to fix this? Seems like a high priority fix to me in this pandemic.
xdg-desktop-portal-wlr works (with a bit of cli work) with MS Teams in chromium with a flag to enable pipewire. The Desktop app will only support it when the Electron release containing pipewire support releases & gets used in Teams.
