Василий Банников

Если без шибко умных слов, то приватными поля нужно делать, чтобы код отображал намерения разработчика и чтобы скрывать детали реализации (польза второго менее очевидна).

Вот пример из комментариев о том, как делать не стоит:

class Character {
  public double health;
  public void TakeDamage(double damage) {
    if(damage <= 0) return;
    this.health -= damage;
    if(this.health <= 0) {
       this.Die();
    }
    // ...
  }
  public void Die() {
    this.DoSomethingSpecial();
    // ...
  }
  
  // Этот метод в будущем будет удалён, оставлен пока как костыль
  public void DoSomethingSpecial() {/*...*/}
}

Потом спустя хз сколько времени ты вернулся к коду.
Как ты будешь вспоминать, как правильно стоит наносить урон персонажам?
Через TakeDamage или в каких-то случаях можно напрямую изменить поле health?
Если в каких-то случаях нужно напрямую использовать поле health, то в каких?
Если ошибёшься - возникнут закономерные баги.

Про скрытие деталей реализации:
Допустим, что ты решил добавить в игру поддержку модов.
Как разработчик мода поймёт, какие методы на персонажах можно вызывать не беспокоясь о том, что мод сломается в следующей версии игры?
Например без использования модификатора internal - разработчик мода может подумать, что этот метод можно вызывать, а по факту - в следующей версии ты, как разработчик игры, планируешь его удалить или изменить сигнатуру, что поломает мод.
+ если у тебя многие вещи сделаны через поля, то тогда ты не сможешь использовать интерфейсы (ну или их использование будет затруднено)

Ожидал что значение будет типом Foo, а там Foo option

Сам же tryHead вызвал. А что должно произойти, если коллекция пустая?

https://learn.microsoft.com/en-us/dotnet/fsharp/la...

"оригинальная" Arduino - это та, которая продаётся компанией Arduino на их сайте.
https://store.arduino.cc/products/arduino-nano
Там mini usb.
Всё остальное - клоны

будет ли она работать эффективнее и занимать меньше места

Если сделаешь более эффективно и компактно, то тогда будет работать более эффективно и компактно.

полноценного открытого мира

Это сразу забудь.
Полноценный открытый мир, разработка в одно рыло, эффективнее чем любой из общедоступных движков, адекватные сроки разработки - выбери, пожалуйста, 3 из 4х.

Учитывай, что UE развивается уже больше 20 лет и над ним работали уже сотни разных разработчиков.
Если ты хочешь сделать что-то подобное, то тогда:
1. Сразу забудь об OpenGL - это достаточно старый API и он не позволит получить максимальную производительность.
(Хотя вероятно он тебе таки понадобится для каких-то платформ)

2. Тебе нужен будет какой-то редактор

3. Раз тебе нужна кросс-платформенность, то тебе нужно поддержать графический SDK для каждой платформы.
На Windows - DirectX, Vulkan
На Linux - OpenGL, Vulkan
На MacOS - Metal

4. Для работы на Android у тебя два независимых куска, которые нужно учитывать:
А - как упаковать уже собранное приложение (на самом деле меньшая из проблем, тк решается)
Б - как собственно взаимодействовать с ОС, как получать инпут от пользователя, как выводить картинку и звук. Тут уже тебе надо обратиться к Android NDK и писать свой код.

5. Осталось малое - графика, физика, загрузка ресурсов (придется научиться обрабатывать файлы с 3d-оъектами и рисовать их), управление. И всё это надо как-то сделать универсальным, чтобы не пришлось для каждой платформы половину кода самой игры переписывать.

А ну и последнее - нужно ещё как-то убедиться, что оно работает лучше, чем уже готовое решение.

И это только по верхам прошёлся, внутри ещё много нюансов.

let! result = bar |> Async.AwaitTask
Убери вот тут AwaitTask. У тебя же там Async

Но вообще лучше по возможности не использовать Async - используй Task и соответствующий CE

Ну давай начнём с самого простого: пусть клиент передаёт два числа, а сервер отвечает суммой этих чисел