I wrote F# for a long time, and there were definite phases to learning and becoming comfortable with it. For example, it's often pitched as a functional language but in reality its a functional-first hybrid language on the .NET framework - to be efficient with it is to embrace this and write imperatively when you need to.
Pure syntax wise, its pretty nice, though having a single pass compiler makes it a bit dated feeling compared to other languages.
Forcing linear dependence of files and definitions is considered a feature of F#. In codebases that allow out of order definitions, things get wild real quick.
I found it rather annoying that you cannot organise your code to be readable from top-to-bottom in a file, going from the big picture to finer details. Which, I think is much easier for humans.
That is a matter of habit and not something that is "easier for humans", I think. I've written enough OCaml, which also enforces linear dependence of modules and definitions, that I often find it jarring to read code the other way around and I'd be lost without an IDE that lets me jump to definitions.
I'm not particularly attached to order of definitions within a module, but I definitely like the linear ordering of modules. Without the compiler enforcing that you always end up with cross dependencies between modules, which I think makes it much harder for humans to read the code.
I've had similar conversations about variable shadowing. I find it natural and it bothers me when I can't do it, especially in functional languages, but I have a friend who really doesn't like it and finds it jarring. I think his dislike stems from having learned Erlang before any language that has shadowing, because in Erlang when you reuse a variable name it'll be checking for equality with the value you're "assigning" it to.
I have not found that to be an issue at all. Most F# modules are just types at the top and then functions. This generally does mean that F# modules start with the big picture (i.e., the types) and then move to the details (i.e., functions). If a module is doing something more complicated than that, then I think it's a problem of the module's design likely being too broad.
In codebases that allow out of order definitions, things get wild real quick.
As I understand, Java allows this. You can effectively have circular dependencies. If true, I have worked on multiple million+ lines Java projects in my career; none of them were "wild real quick". Also, C++ has forward type declarations to effectively allow the same. Again, there are ginormous projects like Google Chrome and Firefox written in C++.
It can be an issue in C#. I've seen some mad circular dependencies between files. The file hierarchy doesn't always reflect the namespace hierarchy which sometimes doesn't reflect the actual code dependencies hardly at all and untangling the messes that result from that can be a big deal.
I'm not sure a project gets into that state "real quick", but it remains something that projects can do over time, sometimes without realizing it, especially when a DI abstraction makes it even less obvious how circular a project's dependencies really are.
I'm not sure why those things are necessarily a problem, particularly when with IDEs or at least editors that can parse a language's symbols. We're not programming the dark ages. Do you have a specific example of why these are an issue?
I think wild real quick might be a bit extreme but cyclomatic complexity[1] is a source of unnecessary complexity in software. While not a problem per se, all unnecessary complexity adds up. Leading to the eventual death of the project[2]
Pure syntax wise, its pretty nice, though having a single pass compiler makes it a bit dated feeling compared to other languages.