поделки гугла в виде Хромо оси и Ведроида врядли будут конкуретно способны при новом подходе мелгомягких к этому рынку

Потому что главный менеджер у них хороший и правильно определяет направление работ.

в том смысле, что мс тоже может запустить линукс рядом со своим ядром, а на ядре линукса запустить андроид как хуавей? да, это тоже интересная мысль, я про это не думал.

вроде же это очевидно, не?

… а на ядре линукса запустить андроид как хуавей?

Приложения андроида уже работают в Windows.
Постами выше была ссылка на то, что Microsoft сейчас ARM-ами занялась и стругает под них ОС.

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

ну они как-то обанкротили нокию,

С нокией они просто обосрались …

они наш мультик посмотрели и приняли на вооружение - " Настоящие герои идут всегда в обход"… Потому что в лоб не всегда и не у всех получается)

еще не забывай про рынок одноплатников, тв приставок и т.д

Net Core «переплюнет» Java.

Net Core «переплюнет» Java.

Так что тренд сейчас таков - использовать Net Core /C#/ и «намекать» на то, что у меня друг гей.

Владимир

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

ну примерно как оракле пересобирает дистр из рхела и в ус не дует. но у оракле своя ниша, а майкрософт - прямой конкурент например в облаке.

посмотрим как всё повернётся.

Это все очень гнусно, но это «ценноости» западного мира и культуры.
Называют они всю эту гадость - СВОБОДА ВЫБОРА.

Владимир

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

… и что был когда-то такой поисковик..

… и какой-то Linux

Владимир

а резве сейчас не мелкомягкие втихаря спонсируют красную шапку? красная шапка довольно агрессивно стала толкать/вталкивать свои идеи в линукс сообщество с определенного времени.

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

самой красной шапке с этого то профита не видно, а вот если за ней торчат уши мелкомягких….картина проясняется…

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

… шлют какие-то патчи в ядро линукса.

Интересно было бы услышать мнение тех кто может сказать какое было ядро в Linux и каким становится.

Владимир

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

Вариантов как правило не так уж и много

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

Именно потому что простые ЯП для простых вещей

Я именно об этом и говорю. Только надо понимать именно то, что ВСЁ формошлёпство - простое. Поэтому там скриптота рулит и тянуть туда что-то сложное - ну… если хочется в 3 раза дольше и дороже, то можно, да.

На типизированных языках тоже получается говнокод. Просто он другой и его больше. Если это ещё сдобрить инновационными архитектурными паттернами типа микросервисов - имеем 800000 строк кода на ровном месте.

как-то так

4 января 2001: Linux версии 2.4.0 (3 377 902 строки кода)

7 января 2019: первый релиз-кандидат Linux 5.0 (более 26 млн строк кода)

18 лет - совершеннолетие

4 января 2001: Linux версии 2.4.0 (3 377 902 строки кода) 7 января 2019: первый релиз-кандидат Linux 5.0 (более 26 млн строк кода)

ИМХО на базар стало похоже.

Владимир

Дарт вроде на пуксии не браузерный, вроде же писали там Flutter и собственный движок рендера какой то, на vulkan-е…

ИМХО на базар стало похоже.

«Тысяча и одна мелочь».

Владимир

Если все нормально проверяется и тот же редактор это все умеет то в целом проблемы нет.

да, точно, флютер.

Он используется для разработки приложений под Android и iOS, а также это пока единственный способ разработки приложений под Google Fuchsia.

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

это стандартные практики

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

вам наверное проще получить стектрейс и исправить в конкретном месте чем добавить одну строчку в тест метода. что какбы намекает на важность проблемы которую решают разработчики котлина.

Т.е. они мешают любителям «хуякс-хуякс и в продакшен».

Ясно-понятно.

Ох, а эти-то чем Вам не угодили?

Практика показала, что возвращать и обрабатывать ошибку через возврат конструкции на sealed class-ах, в стиле Go, не сильно элегантнее.

То есть, понятно, что checked exceptions в заметном числе случаев использовались не по делу, но и альтернативные решения не больно-то изящны и удобны.

А checked exceptions - понятное зло.

появится с опозданием - это сколько? на пол года, а из ппа поставить вообще никак нельзя?

Вот коллеги с другой стороны Земли ахренеют, когда я из убунтовых ppa что-то в центос в облаках что-то потащу...

К сожалению, корпоративная разработка, даже если в команде десять человек и один дохленький дженкинс, не предполагает резких движений. У админов и девопсов достаточно дел и без моего супер-нупер модного стека. Не говоря уже о QAшниках и DBA, которые сидят на Debian 9 и постгресе 9.6 и перелазить на свежачок совсем не горят желанием.

Давеча не уследили и при установке нового сервиса притащили в боевую виртуалку ненароком 11 Яву. 8-я при этом осталась, но jsvc башню оторвало конкретно при смене дефолтной явы. Оно, вроде, и не сложно поправилось, но было нервно и неожиданно.

Ну выучишь этот хипсторский язычок. Денег на работе не добавят, бабы как не давали, так и не будут. В чем смысл потраченного времени?

С каких пор nullable стал свойством типа?

Дорогуша, от того, что у тебя там проверка на null, не поможет тебе не наговнять.

А чего ж их тогда нет в котлине, скале, сишарпе? Даже либы уже давно клепают чтобы не было checked exceptions. Я тебе ща открою одну тайну, ты лучше присядь: альтернатива для checked exceptions - unchecked exceptions

Денег на работе не добавят, бабы как не давали, так и не будут. В чем смысл потраченного времени?

Ну дык на работе и так затрахаешься со 100500 язычками, зачем тебе ещё и бабы?

А как без Checked Exception заставить разработчика закрыть I/O ресурс? Сейчас в java они заставляют обрабатывать ошибки или использовать тот же try-with-resource. В c++ с этим справляется RAII.

Мне кажется Checked Exception в java сейчас там где нужны - в I/O. Больше ни для чего другого они ненужны. Как с этим в C#? Если в потоке упадет I/O и не будет вызван close(), то сокеты и файловые дескрипторы окажутся не доступны?

А как без Checked Exception заставить разработчика закрыть I/O ресурс?

А что, в жабе try finally без catch гасит эксепшен? Очевидно, что нет. И в этом как раз проблема - Checked Exceptions заставляют обрабатывать ошибки (которые могут никогда не случиться - я кстати видел где-то пример, где прописанный checked exception просто не может возникнуть в принципе) сразу на месте вызова, вместо того чтобы просто поймать выше.

Как с этим в C#?

В C# используется using clause (сахар для try finally) для автовызова Dispose у IDisposable.

Если не обернул и не сделал Dispose руками - сам дурак

Если не обернул и не сделал Dispose руками - сам дурак

Если не сделал Dispose руками, то он вызовется в Finalize автоматически.(безусловно, нужно использовать using)

со 100500 язычками

Не, уже плавали, знаем. В чем главная ценность java или шарпа? Это мейнстрим за которыми или оракл или микрософт или ibm. А значит рынок насыщен специалистами, поэтому команду можно целиком выкинуть на улицу и на ее место взять другую, но уже за меньшие деньги, просто чисто на сопрождение. С экзотическими язычками такое не прокатывает.

И кто такие эти джетбрайнс? Бизнес таких не знает.

Так что если кто-то всерьёз ставит на долгую карьеру мобилоразработчика под Ведроид - я б на вашем месте серьёзно подумал.

И тем не менее Андроид уже вырос до 10ой версии, устройств на нём миллиарды, он удобнее и доступнее, чем убогий дорогущий айфон. И те, кто поставил на карьеру разработчика для Андроида живут неплохо и ни о какой «замене» не думают.

Точно так же говорили и криптовалютах и множестве других вещей, которые выглядели для технарей «неидеальными», а для людей - удобными. Так что пока анатилитки сидят на жёпе и ждут смерти Андроида - люди голосуют ЗА него деньгами, а разработчики зарабатывают на хлеб с маслом и икрой.

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

И я трачу время чтобы читать вот такой упоротый бред?

то он вызовется в Finalize автоматически.(безусловно, нужно использовать using)

Если опустить очевидное «Вызов Finalize недетерминирован», то есть еще один нюанс: если finalize не переопределен, он вообще никогда не вызовется. В базовой библиотеке такого конечно быть не должно, но вот что в васянском IDisposable Вася забудет переопределить Finalize - я бы шанс оценил как ненулевой.

https://pastebin.com/9gVpUZSG

А checked exceptions - понятное зло.

В Rust’е и Swift фактически checked exceptions, и все довольны.

Я писал бек год на котлине. Мне понравилось, особенно расширения. А с «Сосукой» ты классно обыграл =)

можно ли быстро въехать в котлин и стать сеньором?
какой порог вхождения?

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

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

При этом то, что автоматически не обработаешь, нужно просто прокидывать до верхнего уровня в стиле «ой, что-то пошло не так, но наши специалисты уже работают над этим». Собственно, для неисправляемых случаев unchecked exceptions и нужны. Но нужно понимать, что за каждую такую надпись на экране клиенты жестко долбят саппорт, а саппорт потом спускает это на инженеров. Поэтому делать все, что можно, чтобы исправить проблему автоматически или, по крайней мере, спихнуть в структурированном виде на клиента, пусть он уже разбирается

Собственно, котлин в этом месте позволяет сделать почти хорошо - sealed classes + exhaustive when решают проблему с выбрасыванием и обработкой разнородных типов ошибок. Но получается не очень элегантно.

Если знаешь java/c#/swift/typescript то от месяца до полугода.

и стать сеньором?

Синьор это компетенции помимо языка, т.е. фреймворки, базы, etc или если 3+ лет работал в продуктовой фирме и потому в контексте её бизнес процессов и стеков, для такой фирмы ты синьор, потому как более опытный разработчик с улицы будет год въезжать в то что ты уже знаешь.

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

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

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