Си-шарп-ствуете ли вы?

Тебе зачем?

Нет, и вам не советуем.

В нашем Linux-мирке больше популярна Java и JVM-стек, а не эта химера Microsoft’а.

При всей моей большой любви к шарпу, пришлось его забросить как только потребовалась реальная кросс-платформенность а не «урезано, работает только вот тут и вот так, написано (в половине случаев) хз кем и кз как, без гуя и без гарантий». Благо на Яву перейти не сложно, а вот там то настоящая кроссплатформа

Речь идёт не о C# вообще, а о реализации этого языка в движке Unity.

только няшная Сишечка

урезано, работает только вот тут и вот так, написано (в половине случаев) хз кем и кз как, без гуя и без гарантий

.NET Core + Avalonia, и ваши волосы станут мягкими и шелковистыми.

С точки зрения пользователя - игры на этом движке самые тормозные и убогие графически. Но прогерам нравится. Пипл хавает.

Игровые движки используются не только для игр. Их применение куда шире. Это и previz, и архитектурная визуализация, и много чего ещё.

Шарпы это стандарт для юнити. Как движок, вполне ок со своими плюсами и минусами. Спрашивать про это лучше на геймдевном форуме. Де факто, юнити один из самых популяных движков. На практике, много юдей знает его, но поверхностно.

Боже упаси. Проприетарный движок, мерзкий язык с говённой микрософтовской экосистемой.

Использую C# на полную катушку. Но без Unity. Зато с реализацией Winforms от Xamarin.

NET Core + Avalonia, и ваши волосы станут мягкими и шелковистыми.

Увы не станут - кор без плюшек полного .нет жиже и беднее Явы, а авалония - хз кем хз как написаное и несовместимое с wpf поделие.

Я понимаю гонять шарп на винде ради полного .net, интеропа и wpf, но гонять его на линухе стоит разве что от безнадеги или если это простенький бэкенд (правда не очевидно почему его изначально писали на шарпе ну да бывает) для какого-нить вэб гуя.

Вы говорите о C# вообще. Если же сузить до Unity, то у вас появляется возможность выбора scripting backend. То есть код, который вы пишите на C# можно прогнать через il2cpp (intermediate language to c++), а затем этот с++ будет скомпилирован в «машинный код» для необходимой вам платформы. То есть финальное приложение не потребует .net runtime для своей работы.

но гонять его на линухе стоит разве что от безнадеги или если это простенький бэкенд

Мягко говоря - это неправда. Очень неплохо он работает на Линуксе.

Использую C# на полную катушку.

а вы (программисты с#) не обижаетесь, когда вас шарпеями зовут?

Внесите Лавсана, он по шарпу упарывался вроде.

А я не только на C# пишу. Использую разные языки. На работе на С#, а хобби на других.

Окстись смутный! Даколеже бесноваты мысли твои! Синяпомигу в царствие сишечном кличать бесноватого шарпового. Сизимъ ижимися. Остановисъ.

С точки зрения пользователя - игры на этом движке самые тормозные и убогие графически

С точки зрения пользователя самые убогие игры, это игры сделанные на собственных движках любителями

Вот пример убогой игры: https://www.opennet.ru/opennews/art.shtml?num=53578

Иронично, но виндовые версии игр на юнити — самые беспроблемные в плане совместимости с wine (+dxvk), особенно последних версий. Что актуально, если разработчик принципиально не хочет делать/поддерживать билд под онтопик и игра напрямую не запускается с нативным unity-плеером.

Касательно убогости — она, как правило, проистекает из высокой дуракопригодности Unity3D. В комплекте идёт библиотека ассетов и справиться с накидыванием их в мир может даже специально обученная обезьяна школьник. Очевидно, рано или поздно штатные ресурсы примелькаются и начнут резать глаз.

А так — производительность, требования к железу и визуальная эстетика игры напрямую зависят от прямоты рук, извилистости мозгов и художественного вкуса разработчика, а вовсе не от фреймворка.

И да, очевидно что нативный движок будет эффективней и производительней «мерзкого сишарпа». Но тут уже вопрос компромиссов — время разработки, уровень требуемых навыков для разработчиков, итд/итп.

Мягко говоря - это неправда. Очень неплохо он работает на Линуксе.

я не говорю что он работает плохо - но от блеска шарпа на винде, где у него вся ОСь обёрнута вокруг .Net’а и это писали те-же люди, что и сам шарп, под линухом у него разве что осколок радости в виде удобного синтаксиса - кор не велик, инороден, заперт внутри себя (нет чудесного взаимодействия с системными/прикладными сервисами, ради которых Net и создавался) и чот сомневаюсь что является приоритетом поддержки для дистростроителей, родное окружение (mssql/iis/mso) отсутствует или вкрячено костылями, гуй - чья-то левая поделка.

при этом держаться за один синтаксис … в яве он плюс-минус такой-же, при этом ява на линухе тебя ничем не ограничивает (полный jdk), она гарантированно работает в любом вменяемом дистре ибо довольно приличный процент серверных установок рассчитаны именно на запуск ява-бэкендов, имеет родное окружение и несколько гуёв на выбор.

и да, это всё не ограничивается только платформами вин-лин - это всё на 100% совместимо (включая гуй) с макосью, юнихом (фрёй и т.п.), соляркой (рип) и т.п.

имхо если речь изначально за прикладной софт, то писать кроссплатформенный изначально на шарпе … не нужно - ты будешь зависим от левой реализации гуя и жить в рамках.
если речь за бэк - то можно, но смысл изначально писать бэк под целевую систему в виде винды … довольно странно.

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

То есть код, который вы пишите на C# можно прогнать через il2cpp (intermediate language to c++), а затем этот с++ будет скомпилирован в «машинный код» для необходимой вам платформы. То есть финальное приложение не потребует .net runtime для своей работы.

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

смысл в чём - что шарп что ява нацелены на наличие в среде выполнения сборщика мусора. на это ориентированы:

• логика - в логике программы вы нигде не трогаете стек/память, вы вообще обычно не в курсе что там за пределами названий переменных
• синтаксис - формально есть возможность взять и приравнять объект к null, тем самым его убив до прихода GC, но де-факто у встроенных классов нет деструкторов
• рабочая среда - ни одна ide под шарп/яву не контролирует цикл жизни переменных (кроме открытых ресурсов, которые надо закрывать)
• отладчик - аналогично, ни один отладчик не контролирует утечки вне ресурсов в явном виде, т.к. реальная утечка в шарп/яве это либо нормальное поведение программы (если ты хочешь набивать бесконечным кол-вом объектов память и оставляешь на них ссылки то значит тебе это зачем-то надо раз оставлены ссылки в явном виде) либо не закрытый ресурс

дык вот - проблемы скомпилить это в байт-код нет никакой, но если это скомпилить в байт-код, то либо это будет работать плохо и не долго (пока не кончится память) либо это изначально должно быть написано «как на сях» с явным убийством объектов (но тогда не проще ли сразу писать на сях, где для этого есть все удобства?), либо с указанием компилятору что он должен грохать в процессе (но это даже менее логично чем первый вариант).

за сим единственный логичный вариант носимого (портабельного) решения - это включение виртуальной машины (среды вполнения) в комплект и оборачивание это стартующей оберткой. увы и ах. человечество уже ходило по этим граблям.

нет чудесного взаимодействия с системными/прикладными сервисами, ради которых Net и создавался

Я пишу на C# на Линукс со времён ещё до покупки Xamarin Макрософтом. В процитированном доля смысла есть - под Линуксом жутко не хватает библиотек Uniscribe, для глубокой работы с Юникодом, и встроенных средств для работы c RTF. И ещё по-мелочи чего нет.

Тем не менее, вот пример приложения .NET Core на Raspberry PI - https://www.fastreport.ru/ru/blog/336/show/

под Линуксом жутко не хватает библиотек Uniscribe

harfbuzz?

harfbuzz

Наш технический директор смотрел в его сторону. Да и я его собирал из сырцов, когда надо было кой-чего подсмотреть. В целом приемлемо, но есть засада в виде того, что harfbuzz не managed. Для C# к нему есть обёртка, но автоматическая кроссплатформенность при этом теряется - нужно прицепом тащить библиотеки для разных аппаратных платформ.

под Линуксом жутко не хватает библиотек Uniscribe, для глубокой работы с Юникодом, и встроенных средств для работы c RTF. И ещё по-мелочи чего нет.

под явой - любая либа (кроме тех что используют nativeApi, но они для прямой работы с железом и как правило сами по себе то-же кросс-платформенные, типа JSSC, либо опираются на нативные библиотеки типа VLCJ) работает под любой осью (по сути являются «своим кодом» с точки зрения вм)

ем не менее, вот пример приложения .NET Core на Raspberry PI - https://www.fastreport.ru/ru/blog/336/show/

так это внешней библиотекой - вот аналог на яве, такой-же плюс-минус синтаксис, та-же логика - библиотека «черный ящик», пара вызовов:

https://www.ibm.com/developerworks/ru/library/os-javapdf/index.html

под вин просто шарп может то, чего не может ява - цепануть человечий word, набить через него полный документ, экспортнуть в pdf и оставить исходник в doc(х) - тупо родными штатными средствами. но только под виндой. ява может под любой осью через апачевские либы, но это не то (с)

под явой - любая либа…

Ну так это слабость платформы, невозможность нормально переиспользовать уже написанный и отлаженный код на другом языке

А, ну если нужна либа на C# - тогда да. Я по этой же причине пилю порт harfbuzz на Rust.

Переписываем сладкий вебушек с ASP.Net на ASP.NET Core, потому что заказчики изволят разворачивать на линуксе, а на жабу переписывать дороже и дольше.

так это внешней библиотекой - вот аналог на яве

IBM это конечно авторитет, и пока голубой гигант поддерживает Java, этому языку никакое забвение не грозит.

Но вот конкретно пример с iText ты привёл неудачный. iText позволяет собирать PDF файлы, а я говорил о целой фабрике отчётов. Чтобы повторить функциональность, тебе десяток библиотек Java придётся в кучу собрать, а затем заставить всё это работать вместе.

Cities Skylines - шикарная игра.

Чтобы повторить функциональность, тебе десяток библиотек Java придётся в кучу собрать

13 лет назад я пользовался iText для генерации и PdfBox для парсинга pdf. Сейчас работаю в фирме где используют jasper reports для генерации pdf документов по шаблонам.

Она не гуманна к CPU, мне кажется даже если у cpu больше 4-х ядер это практически не влияет на производительность.

А еще мне понравилась игрушка The Long Dark, её хотели портировать на свич но не смогли, разработчики сказали что свитч слишком медленный. При том что игрушка по графики довольно проста.

Так что таки да, на unity годные игры есть, но имеют некоторые лимиты по железкам.

Если говорить про игры (хотя поднятая мной тема ими не ограничивается), под unity есть много интересных как с точки зрения геймплея, так и с визуальной точки зрения проектов. Inside, Firewatch, Gone Home.

Но, меня интересует именно работа Unity под Linux.

Ну если говорить про упомянутую мной Cities Skylines, то на одном и том же железе под виндой виндовая версия по параметрам производительность/картинка/отзывчивость управления лучше чем на линуксе нативная версия этой же игры.

Нет, но если что я отношусь к таким людям абсолютно нормально

Ну так это слабость платформы, невозможность нормально переиспользовать уже написанный и отлаженный код на другом языке

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

например я активно пользую: https://github.com/caprica/vlcj

с другой стороны, это используется обычно только для вещей, которым нужен прямой доступ к железу/ядру/памяти т.к. всё остальное давно написано на самой яве и, как правило, отлажено как минимум не хуже (ввиду простоты отладки) :-)

Но вот конкретно пример с iText ты привёл неудачный. iText позволяет собирать PDF файлы, а я говорил о целой фабрике отчётов. Чтобы повторить функциональность, тебе десяток библиотек Java придётся в кучу собрать, а затем заставить всё это работать вместе.

я привел пример, который реализует то-же что и в твоём примере в аналогичном синтаксисе но на другом языке - пихает строчки в pdf.

если цель наполнить строчки смыслом, то для сбора отчётов полно готовых библиотек: https://www.finereport.com/en/reporting-tools/free-and-open-source-reporting-tools.html которые, как правило, сами по себе умеют в pdf, даже старенький yarg, например :-)

Я не проггер, эта область очень далека от моего бытия. Но. Но я пользуюсь исключительно /usr/bin/pwsh (symlink) и это чертовски удобно, в сто крат опережает bash. Именно bash, как интерпретатор. Это .Net Core.

Сорта химер — «химера Оракла» от сдохших санок ничем не лучше :)

Просто владельцы UE4 берега попутали с «революциями» и на святое замахнулись — на бабло платформодержателей :) Ясное дело, девелоперам немножко стремно на сужающейся платформе. Кстати... сложно придумать что-то более убогое, чем собирать плюсы(!) самодельной билдсистемой... на шарпе (?!) — а в UE4 оно так (да и сорцы у него все еще выглядят как привет из 2003-го (это я ему еще польстил).

А оно разве работоспособно?

Сишная дырень не может быть няшной!

Уже да. Monodevelop это бледная тень Visual Studio, но работать в Monodevelop можно.

Иронично, но виндовые версии игр на юнити — самые беспроблемные в плане совместимости с wine (+dxvk), особенно последних версий. Что актуально, если разработчик принципиально не хочет делать/поддерживать билд под онтопик и игра напрямую не запускается с нативным unity-плеером

Как человек, кучу времени посвятивший работе с оффтопом, не могу удержаться от комментария.

Причина проблем с wine — это кривое использование штатного API и использования недокументированных фич. То есть, разрабы действуют методом тыка: заработало — не трогай. В свою очередь, разрабам винды из Microsoft для переноса софта на новые версии винды приходилось извращаться, вплоть до того, что делать в операционной системе workaround-ы для одной единственной софтины. Я вот в казаков пробовал играть на семерке — такое себе удовольствие. И это совместимость винда-винда!

Source и UE прекрасно работают под вайном, и я уверен, что куча других качественных, но более закрытых проектов.

Касательно убогости — она, как правило, проистекает из высокой дуракопригодности Unity3D

Проблема в том, что у юнити нет адаптации для профессионалов. По мере усложнения требований ты не разрабатываешь с движком, ты начинаешь разрабатывать против движка, обходя его неожиданные особенности работы, вроде классического кривого PhysX. Ориентация среды разработки Unity на дураков сочетается с недоработанностью ее для профессионалов, что в итоге и с этой стороны приводит к экспоненциальному росту пустого прожигания времени в борьбе с Unity по мере роста команды, вроде необходимости дружно всей командой перекомпилировать весь проект в начале рабочего дня. Или может разрабы Unity наконец сделали адекватную поддержку Perforce, чтобы проект не разваливался случайным образом? Перестали автоматически тащить артефакты разработки в проект?

UPD: чуть не забыл, что в Unity так и не завезли вещественные числа с двойной точностью, что делает его непригодным для больших миров.

Когда ты делаешь инструмент разработки для профессионалов, то ты можешь сконцентрироваться на максимизации производительности обученного профессионала. Можно сделать инструмент, который подойдет одновременно для профессионала и для дурака, но проблема в том, что создатели Unity выкрутили дуракопригодность на максимум — в этом смысл закона Мерфи «сделай что-то, чем может пользоваться каждый дурак, и только дураки будут этим пользоваться», то есть, ориентация на полнейшего дебила сильно бьет по функциональности, что и произошло с Unity.

И да, очевидно что нативный движок будет эффективней и производительней «мерзкого сишарпа». Но тут уже вопрос компромиссов — время разработки, уровень требуемых навыков для разработчиков, итд/итп

По мере роста проекта неизбежно придется избавляться от C#, потому что внутри него нет никаких способов избавиться от мерзких неожиданных зависаний (или огромного жора памяти, если GC отключить). Ты не можешь сказать «мне этот объект не нужен — удалите, пожалуйста», нет, хрен тебе — подождем цикла GC, чтобы огранизованно подвиснуть. Я понимаю, что есть проекты вроде
https://github.com/jacksondunstan/UnityNativeScripting
но это уже пошла каша из топора, выходящая за рамки Unity — идя по такому пути и решая проблему за проблемой в результате ты получишь гору надстроект и костылей, за которой самого Unity уже не видно. И тогда ты поймешь, что лучше было взять UE, где все проблеы уже решены из коробки.

Ахинею не неси, нетрантайм никуда не денется, поди хоть строчку документации прочитай, раз читать код и писать его не способен, балабол форумный.

По мере роста проекта неизбежно придется избавляться от C#, потому что внутри него нет никаких способов избавиться от мерзких неожиданных зависаний (или огромного жора памяти, если GC отключить).

Сталкивался я с «мерзкими зависаниями» в относительно крупных проектах на C#. Анализ кода показывал, что виноват не GC, а следующее:

1. В проекте было очень много потоков, а доступ к общим данным был либо через стандартный lock, либо даже через самописный lock, который от стандартного ничем не отличался. Решалось ограничиванием числа потоков, а также заменой лока на монитор с таймаутом (по крайней мере монитор позволяет выяснить где слабое место).

2. Как дополнение к первому, обмен данными между сервером и клиентами был асинхронным, любой мог слать данные в произвольный момент времени. Естественно тут будут ситуации, когда все шлют данные разом и система подвисает. В 99% случаев решается заменой на систему запрос-ответ. В 1 % случаев, когда требуется быстрая реакция на какое-то событие, надо делать систему с приоритетами.

Для тех, что работал с разными протоколами можно привести такой пример. В RS-232, где связь точка-точка, допустима передача в обе стороны. В RS-485, где клиентов много, только запрос-ответ, управляемый от мастера. В CAN система с приоритетами, когда одно устройство может «перекричать» другое с более низким приоритетом.

И в большинстве случаев упираются не в GC, а в непонимание таких вещей. Но так как опыта разрулить ситуацию не хватает, то виноватым оказывается GC.

Справедливости ради надо сказать, что если недопустимы задержки в десятки миллисекунд, то да, лучше C# не использовать. Но тут и Windows может миллисекунд 15 украсть. Linux крадёт меньше, особенно, если его специально настроить под задачу.

Си-шарп-ствуете ли вы?

Почему этот язык программирования именуется Си + «#»?

Но тут и Windows может миллисекунд 15 украсть.

Это да.
У Windows руки все время «чешутся».
К примеру если запустить монитор рессурсов и ни чего не делать, то видно, что Windows все время «не мнется».

Наши руки - не для скуки

Поэтому то при настройки Windows нужно все отключать, что не критично для выполнения процессов /все логи, …, …/. Тогда Window - летает.

Владимир

Родной мой, зачем нужен рантайм, если ваша программа скомпилирована в «машинные коды», а не в промежуточный intermediate language. Для исполнения такой программы рантайм ненужен. il2cpp как раз и позволяет проделать такой трюк.