2 ms·
I recently left a c# shop in finance. My background c/c++. I was very interested to see if c# was less work: easier to write and build. I was not impressed by
by scrubs 1y ago
I recently left a c# shop in finance. My background c/c++. I was very interested to see if c# was less work: easier to write and build.
I was not impressed by what I saw - it was junk code. One of the major errors was writing apps as MS services which dragged in tons of MS OS junk.
I cannot totally blame c#; i think the staff there were not engineers but more guys doing stuff.
The code was complex; replete with async calls. Build artifacts were entire directories of dlls, exes, json eg 50+ files per task.
The code was littered with warnings. The company could not or would not do hardly anything outside Visual Studio.
There were entire repos of code without comments; no method contracts, obscene reliance on exceptions.
I'm prepared to think f# could be better but never underestimate how bad things can be with a good language if the devs are not engineering grade developers.
- smoothdeveloper 1y agoNever under-estimates wrong defaults in a language, for example: C++, const modifier, verbose for more correct code (less mutable state, etc.) Rust, mut modifier, verbose for less correct code C/C++, bothersome to have tight scopped values, due to split of expression & statement ML languages, nesting of let bound values, everything is tight scoped, even recycling local names non destructively via shadowing. C#: mostly, all flaws of C/C++/Java F#: mostly all right things of ML, OCaml, Rust F#: Structural comparison of ML types from day 1 C#: just adding records recently; most of libraries, idioms, and semantics geared towards reference comparison idioms C#: mainly OO, noisy syntax, low expressivity (constructing immutable values out of generators or expressions), lots of navigation due to adhoc things needed to be named, poor type inference F#: data & functions, concise end non noisy syntax, high expressivity (list expressions, computation expression values), less scrolling & navigation, object expression rather than defining type used once, great type inference (less noisy diff on refactorings) etc. So average F# codebase is by construct, more sound, than average C# codebase, however F# code quality may be poor, and C# great, still, more soundness in F#, IMHO.