Комментарии 37
Эта совместимость гарантируется на бинарном уровне или на уровне API?
Похоже, глупость спросил. Ибо если не бинарная совместимость, то как мы сможем использовать одну и ту же библиотеку под разными целевыми платформами.
О какой бинарной совместимости вы ведете речь, если все сборки это метаданных + код на IL? Они собственно везде одинаковые.
Ну для тех же Windows 8.1 и Windows Phone 8.1 совместимость по API была на неплохом уровне. Но вот на бинарном была печаль. Отсюда была подпорка в виде Shared проектов, кодовая база которых использовалась в целевых платформах.
Так при одинаковом API работы с файлами код на IL (реализация этого самого API) для той же WP8.1 может разительно отличаться от Win8.1. Ну точнее не может, а так оно и было, скорее всего.
код на IL
Так при одинаковом API работы с файлами код на IL (реализация этого самого API) для той же WP8.1 может разительно отличаться от Win8.1. Ну точнее не может, а так оно и было, скорее всего.
.NET Standart — это как старый PCL, но в уже серьезном таком виде. Вы же PCL когда/если писали там код одинаковый для всех этих платформ. Я вот о чем речь веду. Конечно исключая варианты условной компиляции.
Если писать либу под .NET Standart — гарантируется, что она будет работать на всех платформах, которые поддерживают версию стандарта вами указанного.
Если писать либу под .NET Standart — гарантируется, что она будет работать на всех платформах, которые поддерживают версию стандарта вами указанного.
Что такое платформа win? Которая версии 8.0 и 8.1. И чем она отличатся от .Net Framework ?
Есть подозрение, что это WinRT вызовы которые стали доступны для вызова в Windows 8/8.1, например Windows.Storage
А где это реально указывается? Это проекты типа '.Net Standart` теперь можно создавать или что?
В файле project.json. Да, по умолчанию в .net core все class library создаются под netstandart1.6.
Я наверно чего-то не понимаю, но project.json же только для dotNet_Core? А остальные?
Да с введением всех этих стандартов путаница усилилась. И надо время, что бы разобраться теперь во всем что MS и сообщество сделали за эти пару лет. Особенно вся хрень с переименованиями платформ, стандартов, металиб и т.п.
Вы можете создать проект .netCore указать, что весь код совместим с netstandart1.6 и собрать его. Потом, сборку — вы можете использовать во всех проектах, которые будут совместимы с netstandart1.6 в том числе и c .NET Framework.
Вы можете создать проект .netCore указать, что весь код совместим с netstandart1.6 и собрать его. Потом, сборку — вы можете использовать во всех проектах, которые будут совместимы с netstandart1.6 в том числе и c .NET Framework.
Внутри project.json указываются таргет фреймворки, так что он не только для dotNet Core.
По последним новостям, MS отказывается от project.json и возвращается к csproj и msbuild. https://blogs.msdn.microsoft.com/dotnet/2016/10/19/net-core-tooling-in-visual-studio-15/
Что их так колбасит-то. То туда, то сюда. Причём по разным проектам же видно.
Что бы не плодить лишние сущности был вариант переносить весь туллинг для всех видов проектов на project.json или использовать и развить уже существующую систему. Они выбрали второй путь.
В существующей системе существуют несколько проблемы, которых нет в project.json.
1) В .csproj указываются все файлы включаемые в проект. Это увеличивает вероятность конфликтов при мерже изменений и вообще зашумлет файл
2) Информация о включенных пакетах заносится в два места в package.json и в .csproj
3) Нет поддержки сross-targeting для различных версий фреймворка
Выбранный путь дает плюшки для всех видом проектов, и старых и новых, не выкидывая, а улучшая старый туллинг. В бонус пойдет работа через dotnet cli для всех видов проектов, и автоматическая миграция с project.json.
В существующей системе существуют несколько проблемы, которых нет в project.json.
1) В .csproj указываются все файлы включаемые в проект. Это увеличивает вероятность конфликтов при мерже изменений и вообще зашумлет файл
2) Информация о включенных пакетах заносится в два места в package.json и в .csproj
3) Нет поддержки сross-targeting для различных версий фреймворка
Выбранный путь дает плюшки для всех видом проектов, и старых и новых, не выкидывая, а улучшая старый туллинг. В бонус пойдет работа через dotnet cli для всех видов проектов, и автоматическая миграция с project.json.
Почему бы просто не портировать .net framework для macos/Linux?!
Что вы подразумеваете под «портировать»? Как я понимаю, собственно, .NET Core и есть попытка запилить как можно более широкую кроссплатформенную часть.
MS говорили, что портировать почти невозможно, поэтому просто написали все заново раздробив на мелкие кусочки так, что бы больше не приходилось ставить на машину отдельно фреймворк, чтобы запустить приложение. Так .NET Core появился.
Чета много написано, а суть .NET Standard простая. До него в .NET Standard явно указывались совместимые платформы. Вышла новая платформа или версия — пересобирай либу, публикуй новую версию пакета
После появления .NET Standard в PCL указывается не версия платформы, а версия стандарта. И проекты под все совместимые с этой версией стандарта платформы могут либу добавить.
Ну и вторая причина — так как стандарт развивается раньше конкретных платформ, то платформы будут стремиться соответствовать стандарту. В идеале (где-то в районе .NET Std3)это будет один и тот же код на всех платформах.
Microsoft добавляет новую платформу .NET Standard Library. [..] .NET Standard Library — формальный набор спецификаций общих интерфейсов
И всё-таки, .NET Standard Library — это платформа, библиотека (library) или набор спецификаций?
Самое понятное объяснение что такое .NET Standard я видел у David Fowler вот тут
Если кто пропустил, то есть анонс .NET Standard 2.0 на Хабре. Из особенностей — был откат изменений, поэтому новый стандарт совместим с .NET Framework 4.6.1, а не 4.6.3.
.NET выглядит лучшим, на мой взгляд, решением для разработки кроссплатформенного ПО
Обоснуйте.
Просто выскажу своё мнение(серверсайд). Это сугубо ИМХО :)
1. Java — непонятно, что будет дальше. Oracle как-то не внушает доверия, да и JCP ИМХО тормозит развитие. Хотя к ней я не равнодушен :)
2. Go — для больших приложений ну его нафиг. Пусть дженерики сделают и динамическую подгрузку либ :)
3. Ruby(RoR) — это было весело в районе 1.9-2.0. Закидоны DHH поднадоели.
4. Python — ничего плохого не скажу. Просто не лежит душа и не хочу соваться в native interop для некоторых задачек. Да и вакханалия с версиями удручает.
5. Scala — достаточно нишевая, дико бесит долгая сборка. C# активно добавляет некоторые её фичи.
6. JS — для высокопроизводительного бэкенда с большой долей compute — сразу до свидания. Изоморфный рендеринг пусть на отдельном бэкенде рисуют если так прижало :)
7. PHP — свои мысли оставлю при себе :)
Остальные как-то сильно специфичны или мало распространены.
На текущий момент я вижу три основных проблемы:
1. Негатив к MS и просто незнание текущего состояния дел.
2. Небольшой размер активного open-source комьюнити. Тут дела идут на поправку, но это чувствуется.
3. Много «тру-энтерпрайз» разработчиков, которые дальше пузыря MS не видят и сидят в своём мирке. Для них дикость, что можно выкинуть EF, не использовать SqlServer, поменять MVC на Nancy, так как они ждут что эти решения примет за них MS.
Сорри, если кого обидел случайно, просто личные наблюдения :)
1. Java — непонятно, что будет дальше. Oracle как-то не внушает доверия, да и JCP ИМХО тормозит развитие. Хотя к ней я не равнодушен :)
2. Go — для больших приложений ну его нафиг. Пусть дженерики сделают и динамическую подгрузку либ :)
3. Ruby(RoR) — это было весело в районе 1.9-2.0. Закидоны DHH поднадоели.
4. Python — ничего плохого не скажу. Просто не лежит душа и не хочу соваться в native interop для некоторых задачек. Да и вакханалия с версиями удручает.
5. Scala — достаточно нишевая, дико бесит долгая сборка. C# активно добавляет некоторые её фичи.
6. JS — для высокопроизводительного бэкенда с большой долей compute — сразу до свидания. Изоморфный рендеринг пусть на отдельном бэкенде рисуют если так прижало :)
7. PHP — свои мысли оставлю при себе :)
Остальные как-то сильно специфичны или мало распространены.
На текущий момент я вижу три основных проблемы:
1. Негатив к MS и просто незнание текущего состояния дел.
2. Небольшой размер активного open-source комьюнити. Тут дела идут на поправку, но это чувствуется.
3. Много «тру-энтерпрайз» разработчиков, которые дальше пузыря MS не видят и сидят в своём мирке. Для них дикость, что можно выкинуть EF, не использовать SqlServer, поменять MVC на Nancy, так как они ждут что эти решения примет за них MS.
Сорри, если кого обидел случайно, просто личные наблюдения :)
НЛО прилетело и опубликовало эту надпись здесь
Только вот реально времени это займет больше. И дальнейшая поддержка дороже выйдет. Все-таки, что не говори, а С# и Java в плане скорости разработки, особенно под энтерпрайз, ушли существенно дальше чем C++.
НЛО прилетело и опубликовало эту надпись здесь
Простое отсутствие стандартной библиотеки в C++ уже усложняет разработку. Да есть сторонние, куча их, несовместимых между собой. Самая боль — строки.
Да, понятно, что на проекте выбирается определённый набор библиотек под стандартные задачи, но если разработчик меняется, приходит новый, то тут дополнительные расходы на знакомство с текущим набором библиотек под простейшие задачи, в худшем случае разработчику придётся учиться работать с новой библиотекой. А если где-то в процессе пойдёт сбой, так и вообще свою библиотеку подтянет, с которой уже работал.
Синтаксический сахар для асинхронной работы: в C# можно писать асинхронный код, будто он последовательный. Ну и куча таких мелочей.
Да, понятно, что на проекте выбирается определённый набор библиотек под стандартные задачи, но если разработчик меняется, приходит новый, то тут дополнительные расходы на знакомство с текущим набором библиотек под простейшие задачи, в худшем случае разработчику придётся учиться работать с новой библиотекой. А если где-то в процессе пойдёт сбой, так и вообще свою библиотеку подтянет, с которой уже работал.
Синтаксический сахар для асинхронной работы: в C# можно писать асинхронный код, будто он последовательный. Ну и куча таких мелочей.
НЛО прилетело и опубликовало эту надпись здесь
Ничего не имею против C++, но в большом бэкенд проекте я бы отдал предпочтение type safe(хотя бы почти) языку — проще найти людей, люди стоят дешевле, меньше способов выстрелить себе в ногу(особенно при наличии junior разработчиков). Плюс в том же C# всегда можно уйти в unsafe, если сильно припекло :D Ну и тот же CoreRT пилят.
C++ 17 вроде как — «nearly feature-complete».
Хорошо хоть memory model завезли ;)
C++ 17 вроде как — «nearly feature-complete».
Хорошо хоть memory model завезли ;)
Я сейчас конечно не бекенд ковыряю, но реально кроссплатформенную тулу на C++ которая работает на всех десктоп и мобильный осях. И это ад. Во многом, конечно, из-за того, что код тянется с 90х. Там куча задефайненных флагов под разные платформы. И там собственная реализация строк. Хорошо, если во всех нужных вам зависимостях будет использоваться STL, а если нет? Зоопарк зависимостей.
Кстати, на iOS эта штука ходит в интернет через Obj-C, вероятно потому что все стандартизировано и универсально.
>Ну и async/await в C++17 уже завезли.
Даже в C#, где компилятор можно считать один, прошло 3-4 года, пока нормально обновились большинство библиотек с поддержкой этой фичи, и стало комфортно пользоваться ей.
Вспомнить менеджеры зависимостей ещё. (да, я знаю, есть альтернативы для плюсов, но стандарта нет даже де-факто).
Это все мелочи, но каждая потенциально отъедает время. За счёт этого у Java и C# скорость разработки и выше. Понятно, что это во многом зависит и от разработчиков и от внутренних процессов. Но средний результат будет такой.
Кстати, на iOS эта штука ходит в интернет через Obj-C, вероятно потому что все стандартизировано и универсально.
>Ну и async/await в C++17 уже завезли.
Даже в C#, где компилятор можно считать один, прошло 3-4 года, пока нормально обновились большинство библиотек с поддержкой этой фичи, и стало комфортно пользоваться ей.
Вспомнить менеджеры зависимостей ещё. (да, я знаю, есть альтернативы для плюсов, но стандарта нет даже де-факто).
Это все мелочи, но каждая потенциально отъедает время. За счёт этого у Java и C# скорость разработки и выше. Понятно, что это во многом зависит и от разработчиков и от внутренних процессов. Но средний результат будет такой.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
.NET Standard Library – адекватный стандарт?