Прошу прощения, а нестандартные задачи это проходы по деревьям, задачи на бин поиск, интервалы там и прочие стандартные алгоритмические задачи, решения которых особо упорные кандидаты за полгода зубрешки забивают себе в мозжичок, не особо понимая сути решения?
Если нет, зачем вообще проводить собеседование, можно же просто отбирать призеров олимпиад и турниров, не тратя время на собесы?
А можно поинтересоватся, какая связь между IQ, решением алгоритмических задач на собеседованиях и решением задач реальных, и как это должно выявлять сильных кандидатов?
Если ужать все в одно предложение - мы создали копию Idea чтобы занять место JetBrains.
Единственный плюс - не зависеть от прихоти негодяев из JB. Это да. В остальном.
OpenIDE, напротив, полностью локален. Мы не передаём исходный код за границу и не отправляем телеметрию в сторонние облачные сервисы. Для компаний, особенно крупных, это вопрос доверия и информационной безопасности.
Где гарантии что завтра вы сами не станете это делать как только наберете достаточную базу пользователей?
OpenIDE Pro будет коммерческим продуктом. Это ответ на запросы рынка, которых получили немало, и закономерное решение: корпоративная поддержка требует реальных ресурсов — инженеров, времени на тестирование, инфраструктуры и процессов по SLA.
Предположу что вы изначально делали проект не из альтруизма но оно и понятно.
Проблема в другом. Что нового вы привнесете с этим продуктом помимо независимости от редисок из JB?
Да это не на Ваш комментарий ответ а на то что выше, а ответил Вам скорей в контексте эликсира. Специально написал "Это я в контексте прошлого комментария." Признаю, сформулировать получилось неудачно.
Я не поклоняюсь Rust, для меня это не более чем отвертка для решения ряда задач, как и любой другой ЯП.
Я не понимаю претензий вида Rust не совершенен - я в нем разочаровался, и это еще на фоне таких "совершенных" языков как C++. Есть один инструмент который одной делает хорошо а другое - плохо и другой который имеет обратные характеристики. Мы все ждем идеальный инструментов, но что-то пока не завезли. Когда завезут то что во всем будет лучше и решать большинство проблем, мне вот честно нафиг тогда не нужно будет копятся во временах жизни. Но это когда-то и возможно. А пока что есть то есть.
Я (внимание! лично я! это частное мнение! не претендующее на объективность!) не вижу архитектурных проблем в эликсире.
Во первых, вопрос не про архитектурные проблемы(что бы это не значило) а скорее глобальные, а они есть у всех. В данном контексте - проблема управления памятью, которая не решена нигде.
Мы имеем либо: - просто и безопасно но не быстро(GC языки) - просто и быстро но не безопасно(C/C++, все остальные виды C с бантиками) - быстро и безопасно но не просто(Rust)
Я не знаю сейчас более менее живых языков, которые решают одновременно три эти проблемы. В этом контексте я не понимаю претензии к Rust. Разработчики сделали ставку на скорость и безопасность решая конкретную проблему - сделать быстрый язык без отстрела себе ног, это имело свои последствия в виде сложности. За все нужно платить. Можно было лучше? Наверное. Но где те идеальные инструменты где все и быстро и надежно и просто? Очевидно нигде. Когда появиться такое то уже будет интересно сравнить или действительно прийти к выводу что Rust не торт. А сравнивать с самострелами в контексте простоты наглухо закрывая глаза на отстреленные конечности такое себе.
Это я в контексте прошлого комментария.
По поводу Эликсира, в данном контексте его проблемой была бы производительность.
Я бросил раньше, видя глобальные проблемы. Правда я начал уже "зная брод".
Можете поделиться, в какой альтернативе нет глобальных проблем?
- я ранее наткнулся и переводил статью Александреску касательно Раста
Почитал. Целых две и обе невероятно объективные.
Первая - почему Rust, разработчики которого поставили цель сделать язык безопасным управлением памятью и высокой производительностью, вместо этого не сделали еще один Си с бантиком.
Вторая - "Чуждый синтаксис. Это раздражает людей, пришедших из языков семейства Algol’а". Ну это по мне стыд и позор такие претензии предъявлять, что-то на уровне, язык плохой потому что у него маскот - краб.
Тестировать приватные функции, сиречь — дентали реализации, — самый страшный грех разработчика (после плохих имен и некорректной инвалидации кэша).
Вынужден с Вам не сгогласится. Звучит красиво и я сам раньше в это верил, но реальность такова что часто мы встречаем код вполне понятный, вполне компактный но чертовский неудобный и сложный для тестирования, и вот на него нужно написать тесты. И тогда перед нами ставят четыре стула:
декомпозировать сложную логику на несколько более простых публичных частей. Грех, потому как мы начинает подстраивать код под тестирование а не под задачи, возможно эти публичные функции никому не нужны или даже недопустимы для публичного пространства, плюс код сразу усложняется, превращаясь из местечкового в раздробленный.
не заморачиваться с инкапсуляцией и сделать все функции публичными. Думаю комментировать не нужно.
писать супер сложные и адски неудобные тесты с проверкой все возможных комбинаций всех инвариантов этой слогики. Но для этого лучше уже подойдут интеграционные или более реалистичные тесты.
писать на тесты на части приватной логики. Да местами прибиваем гвоздями детали реализации, с другой стороны, unit тесты это и есть история про прибивание гвоздями реализации в том или ином виде. Зато можно написать компактный хороший и простой код с закрытой реализацией и удобным тестированием.
Лично пришел к выводу что последнее меньшее из зол. Судя по тому что во многих языках есть такая возможность, не я один.
Потому что не все типы ссылочные, есть еще и типы значений(i32, bool, структуры с копированием, перечисления и т.д.).В подавляющем большинстве языков дефолт - это передача по значению. Передавать все по ссылке а значения передавать специальным синтаксисом - это разрыв мозга.
Метапрограммирование
Это ад. Всё, кроме этого — вкусовщина и вопрос привычки, но если в языке в 2025 году заявлено метапрограммирование — оно не может быть настолько убогим.
Тут вообще не поспорить.
комментарии — это ад; 2025 год на дворе, но я не могу просто прочитать документацию перед функцией, нет — передо мной выстроен частокол //!. Ну как так-то?
Пока Вы не написали, если честно даже не замечал. А сейчас сходил посмотрел, точно.
какие тесты я кладу рядом с кодом, какие в папку test?
Рядом с кодом - модульные. И получаете доступ ко всем приватным функциям модуля, что очень полезно. В различные test интеграционные и прочие тесты.
матчи внутри одной функции вместо нескольких голов, компилируемых во внутренний матч — ну чуваки, вы вообще хоть одну завалящую статейку про «как оно сделано у соседей» читали, или сразу свой велосипед строить начали?
Ну справедливости ради, такой велосипед не только в Rust но и в Python, Kotlin, C#, Scala, Swift и будет в Java. Думаю подход выбран для единообразия синтаксиса. В Rust нет перегрузок функций и делать исключения в виде особого синтаксиса именно для PM видимо было нецелесообразно. По карайне мере мне так кажеться.
Можете пожалуйста пояснить, кого можно называть инженером (в айтишке, офк) и почему?
Если по уму то никого. Есть профессия инженер а есть программист. В большинстве своем, названия типо software engineer и прочее - это странные понты некоторых компаний, которые хотят поставить себя выше остальных, потому что у них не какие то никчемные программисты работают а целые software engineers.
Но если бы ко мне пристали с задачей - "нет ну ты все-таки придумай, хотя бы субъективно, как разделить программистов и инженеров", то я бы наверное поделил так: инженеры, пусть это будут разработчики ОС, драфверов, компиляторов, виртуальных машин, игровых движков, железячники т.д., т.е. специалисты, для работы которым нужны фундаментальные знания, часто научный подход, люди которые строят базу для всех остальных, а вот все остальные - это программисты, по сути пользователи того что сделали инженеры. Наверное так.
Интересно наблюдать, в какое еще говно мокнут и обесценят некогда почетное слово инженер.
Сначала, формошлеперы и json-перекладчики провозгласили что все, они теперь не какие то там веб программисты а целые инженеры. Теперь вот докатились что уже вайбкодеры на себе примеряют.
Правильно, сейчас не модно как раньше расти чтобы соответствовать, сейчас проще обесценить термин и натянуть его на себя.
Тогда, во многом солидарен. Мне вообще нравиться отчасти перекликающийся подход в Rust в этом плане. Где трейты, очень похожи внешне на интерфейсы но являются не контрактами а по сути ограничителями для дженериков, и по больше части используются для ограничения параметров функций.
Вы показали примеры где интерфейс используется для сокрытия реальной зависимости и как абстрактное возвращаемое значение, но самое интересное обошли стороной - интерфейс как параметр функции. Хотелось бы услышать Ваше мнение по этому поводу.
Постоянные и непременные отсылки к дядюшке Бобу, или другим корифеям как-то странно звучат. Я не опираюсь на авторитет, никогда не апеллирую к нему в аргументах, мне он не важен. Это интересно как историческая справка, не более.
Ну, во первых, я специально не привожу это как аргумент из-за субъективной его природы. Но тем не менее, полностью не учитывать связь между творчеством и творцом - нельзя.
Благодаря популярности и широкому охвату аудитории среди специалистов, принципы на сегодняшний день очень хорошо разжёваны и расписаны, и достаточно раскритикованы. Смотрите на это, как на библиотеку, которую написали сообществом и можно использовать в работе, не затрачивая усилий на создание новых, узких и малоизвестных принципов или подходов.
То что он разжёваны и то что их вообще нужно толковать - это и есть проблема, у нас вроде бы не теология а программирование. Если у принципа нет однозначной интерпретации то пойдут толкования, различные взгляды и направления. Кто будет определять кто из толкователей самый правильный и какая трактовка самая верная? И мы приходим к тому с чего начали: на МР два разработчика будут спорить каждый со своей колокольни, потому что правильного ответа нет как и методики. Если же ссылается к толкованиям от авторитетов то мы превратиться в подобие религии а должны хоть как то походить на науку.
Да, это не формула, высеченная в камне, не аксиома, не ответ на все вопросы, не решение всех задач, но это весьма конкретные указания, общие принципы, которым итак многие следуют вполне естественным образом.
Когда строят здание то руководствуются не абстрактными общими принципами а конкретными обоснованными с точки зрения науки и практики нормами.
Отдельные принципы могут иметь различия в деталях, на то они и принципы, а не конкретные методики, где написано до буквы: делай А, получишь Б.
Проблема в том что такое прокатывает в гуманитарных дисциплинах, когда судья руководствуется внутренним чувством справедливости, к примеру, в отдельных аспекта. И такое абсолютно не применимо в технических.
Т.е. суть в том, что они действуют не только между участниками одной команды, а между участниками всех команд в мире.
В том и проблема, что даже между участниками одной команды не будет понимания, потому что эти самые принципы не дают никакой конкретики, они просто хорошо и красиво звучат. А прицип, который для каждого звучит по разному имеет низкую практическую ценность.
Но я наблюдаю другой тренд: давайте вообще всё выкинем, под корень. Всё это туфта. Конечно, не забудем принизить значимость авторов: да это какой-то писака, вообще не шарит и далёк от реальных задач.
Ну тут Вы явно преувеличиваете. Я ни разу не видел что кто-то предлагал выкинуть вообще все. Чаще, одно радикально поперек другого. И оно не удивительно. К примеру, тот же ООП, который захватил огромную часть IT на несколько десятилетий, практически выдавив любое инакомыслие. Чистый код, SOLID и паттерны проектирования, про которые можно было послушать из каждого утюга. Все это в том числе, дичайшим образом догматизировало огромную часть сообщества и остановило в развитии. Огромное число людей стали не искать решение проблем а то как пользоваться инструментом. Ожидаемо было, что после многих лет в таком режиме, оно бомбанет и многие люди, разочаровавшись в старых инструментах, подходах и авторах, пойдут искать радикально другие подходы. И это хорошо, т.к. маятник будет ходить туда сюда балансируя и выверяя эти самые инструменты и подходы. Намного лучше, чем застрять в развитии, заменив прагматизм на веру.
У меня другое мнение на этот счёт. Многие люди признают, что с опытом заявленные принципы становятся очевидными и применяются даже без явного знания или умышленного следования им. Эти принципы нужны для согласования работы, новичкам.
Понимаете, вопрос ни в том какой у кого мнение. Можно было бы сказать что Роберт Мартин и ко, никакие не светилы с олимпа создавшие грандиозные проекты а скорей успешные писатели. Что если посмотреть его проекты то он давно не следует своим же принципам. Что в своем блоге он писал что когда придумывал SOLID не очень понимал принцип подстановки Лисков. Что принципы формировались так чтобы получилось красивое слово а не по соображениям важности. Но я не будет приводить это как аргументы так как это в некоторой мере субъективно. Я приведу объективный аргумент.
На мой взгляд, в каких либо принципах, главное - это точки их приложения а не красивая идея на фоне. И вот здесь главная проблема. Возьмем SRP, вроде бы и звучит красиво и как будто бы о правильном - "хорошо делай - хорошо будет", но говорит ли нам этот принцип о том как делать хорошо или хотя бы о том что такое ответственность, как это все посчитать или распределить? Нет? Возьмите двух разработчиков дайте им одну и ту же задачу и попросите использовать SRP. С огромной долей вероятности Вы получите разные решения, потому что каждый будет интерпретировать SRP по своему.
Как минимум, это может быть полезно на code review, естественно без фанатизма.
Выкатил Петя МР, а ему Дима говорит: ты тут нарушаешь SRP, после чего начинается срачь, т.к у каждого свое видение. Потому как SRP не описываем хоть как то детерминированный механизм реализации собственного постулата а получается тотальная субъективщина. Толку от такого принципа, как от совета прохожего: "живите правильно и все у вас будет". Тоже самое с ISP и т.д. Принцип LSP наиболее адекватный и детерминированный но самый редко применимый, да и к примеру, если посмотреть на стандартную библиотеку Java, то там раз через раз он нарушается (видимо разработчики языка программирования забыли сходить к Мартину).
В общем говоря, принципы SOLID по большей части это красивые советы (возможно даже где-то правильные) без определений их приложения (и соответственно большого практического смысла), которые появились потому что пару человек, которые ни разу не гении в IT, по приколу их собрали исходя из своих субъективных взглядов и понятий красоты, при этом вся заслуга популярности принципов это популярность их автора а не ценность или важность для сферы. Не нужно делать из попсы религию.
Тренд отрицания всего и вся тоже можно назвать завирусившимся.
Завирусившимся можно назвать тренд на возврат к критическому мышлений, когда мы должны во всем сомневаться, переосмысливать, критиковать и требовать доказательств в противовес догматическому мышлению когда миллионы людей поклоняются тому что какой-нибудь дяденька написал в книжке.
К сожалению, в русскоязычном Go-сообществе действительно очень слабо с пониманием SOLID и чистой архитектуры в частности. Вместо того чтобы разобраться, как это работает, многие разработчики просто уходят в отрицание и заявляют, что им это не нужно, хотя на самом деле, скорее всего, просто стесняются признаться, что не смогли разобраться.
YAGNI упомянут совершенно не к месту. Это не «принцип, который почему-то большинство игнорирует», а скорее философская установка, которая формально «за всё хорошее и против всего плохого», но при этом не даёт никаких конкретных границ или ограничений, в отличии от реальных принципов
Для меня загадка как Вы это видите в YAGNI но в упор не замечаете что SOLID - ровно тоже самое. При этом считаете что сообщество языка, авторы которого активно продвигали философию простоты во всем, обязано наперекор принципам языка, тащить туда неповоротливые чистые архитектуры, с которыми уже и так намучались в других языках.
Что значит "отказался" от YAGNI, KISS, SOLID? Делаем наперекор? Если не упарываться, то эти принципы выведены из практики, а не практика построена на этих принципах.
Наверное - это перестать делать вид что какой-нибудь SOLID - это действительно что-то умное и важное посланное нам полу-богами величайшими светилами IT а не абстрактный, завирусившийся набор практически бесполезных советов в духе "хорошо делай - хорошо будет", придуманных из буков собранных по принципу как красивее в слово собрать, дяденьками которым банально было нечем заняться.
Вы делаете эти предположения на уровне конфигурации.
Нет. На уровне кода. В любом месте можно задать контекст выполнения.
То у вас уже большие проблемы, и да, автоматически их виртуальные потоки не починят. К счастью, таких библиотек исчезающе мало.
Всю 30 летнюю экосистему Java взяли и по быстрому переписали? Оптимистично.
То что у вас снаружи написано async не значит, что внутри нет большого синхронного куска, не позволяющего переключать контекст.
Есть разница между тем что автор библиотеки написал async но не реализовал, потому что он дурак и тем когда автор ничего не писал и не гарантировал.
Я вообще не рассуждаю о том, что лучше - иметь очень так себе имплементацию сразу или пилить хорошую 11 лет. Я рассуждаю на состояние сегодня, что лучше - заставлять красить методы (и перекрашивать, что самое плохое) или иметь stackfull на стороне рантайма. И на мой вкус, раскраска проигрывает колоссальным образом.
Так Вы и рассуждайте сегодня. А сегодня есть go и java а подавляющее большинство остальных языков раскрашивают функции. Что вы предлагаете, переделать им на виртуальные потоки все? Если нет, то что по Вашему "зло во плоти" то, инструмент который позволил сэкономить 11 лет? Понимаете, если бы Java сейчас выкатила что-то невероятное, инновационное, меняющее подходы кардинальным образом то это еще ладно, но по факту но они просто догнали конкурентов. Поэтому я не понимаю идею про "зло во плоти", есть работающий много лет инструмент а есть может быть чуть более удобное решение(время покажет) которое запоздало на десяток лет. Async/await явно прорывное для своего времени решение которое позволило многим языкам и экосистемам работать удобно и эффективно, в то время как другие десять лет изобретали, так что я бы не стал это называть "зло во плоти" точно.
Не важно что написано в документации библиотеки, виртуальные потоки (stackfull-корутины) работают прозрачно и для вас, и для библиотеки. В любом safe-point может произойти переключение виртуального потока, автор библиотеки (или вы) вообще ничего не должны для этого специально делать.
Ну во-первых. Будут блокироваться вызовы или нет, зависит от контекста. Вот находитесь Вы в произвольном месте кода и знать не знаете как этот код будет работать, потому как это целиком и полностью зависит от вызывающего - изволил он запустить метод, который запустил метод, который запустил метод... из виртуального потока или платформенного. В отличии от Go, где весь рантайм асинхронный или C# где четко видно по функции синхронная она или нет, в Java смотря на код вообще невозможно сделать никаких предположений о том как он выполниться. Тоже и с ошибками, если кто-то ,на верхнем уровне, создаст случайно не виртуальный поток, то все начнет работать не виртуально и никто этого вообще не заметит.
Во-вторых. То что написано в документации и самое главное, как реализована библиотека - критически важно. Чуда не случиться. Если Вы вызываете библиотеку внутри которой создаются платформенные потоки по старой доброй памяти, или она использует свой пулл не виртуальных потоков или например внутри нее нативные вызовы, которые будут блокировать Ваши потоки, то работа с асинхронностью превратиться в тыкву. Самое неприятное что проблемы могут быть даже не у самой библиотеки а у библиотек которых она использует или библиотек библиотек. Причем самое обидное все это будет неявно. Вообще нет четкой границы, где версия n блокирующая а версия m неблокирующая, можно только или верить документации, которая может врать или путешествовать по кишкам библиотеки и всех ее зависимостей. В отличии от тех же раскрашенных функций, где автор явно выражает это в API.
Да, разумеется, сделать поддержку stackfull корутин намного сложнее, чем stackless. Но мы же не о сложностях реализации? И не про 2012й год. Речь всё-таки про пользователя, и пользователя сегодня.
Ну Вы написали что раскраска функций - зло во плоти, а я считаю что пилить фичу 11 лет, заставляя либо тысячи проектов быть отсталыми и не эффективными или разработчиков подвергать мукам работы с реактивным программированием, только ради того чтобы быть похожими на недо-Go 2012 года - вот что настоящее зло. Есть хорошая фраза - "лучшее враг хорошего". B Java может себе позволять такие фортели только из-за своей мега популярности и огромной значимости для энтерпрайза .
Остается надеяться что самая темная ночь перед рассветом
Прошу прощения, а нестандартные задачи это проходы по деревьям, задачи на бин поиск, интервалы там и прочие стандартные алгоритмические задачи, решения которых особо упорные кандидаты за полгода зубрешки забивают себе в мозжичок, не особо понимая сути решения?
Если нет, зачем вообще проводить собеседование, можно же просто отбирать призеров олимпиад и турниров, не тратя время на собесы?
А можно поинтересоватся, какая связь между IQ, решением алгоритмических задач на собеседованиях и решением задач реальных, и как это должно выявлять сильных кандидатов?
Если ужать все в одно предложение - мы создали копию Idea чтобы занять место JetBrains.
Единственный плюс - не зависеть от прихоти негодяев из JB. Это да. В остальном.
Где гарантии что завтра вы сами не станете это делать как только наберете достаточную базу пользователей?
Предположу что вы изначально делали проект не из альтруизма но оно и понятно.
Проблема в другом. Что нового вы привнесете с этим продуктом помимо независимости от редисок из JB?
Да это не на Ваш комментарий ответ а на то что выше, а ответил Вам скорей в контексте эликсира. Специально написал "Это я в контексте прошлого комментария." Признаю, сформулировать получилось неудачно.
Я не поклоняюсь Rust, для меня это не более чем отвертка для решения ряда задач, как и любой другой ЯП.
Я не понимаю претензий вида Rust не совершенен - я в нем разочаровался, и это еще на фоне таких "совершенных" языков как C++.
Есть один инструмент который одной делает хорошо а другое - плохо и другой который имеет обратные характеристики. Мы все ждем идеальный инструментов, но что-то пока не завезли. Когда завезут то что во всем будет лучше и решать большинство проблем, мне вот честно нафиг тогда не нужно будет копятся во временах жизни. Но это когда-то и возможно. А пока что есть то есть.
Во первых, вопрос не про архитектурные проблемы(что бы это не значило) а скорее глобальные, а они есть у всех. В данном контексте - проблема управления памятью, которая не решена нигде.
Мы имеем либо:
- просто и безопасно но не быстро(GC языки)
- просто и быстро но не безопасно(C/C++, все остальные виды C с бантиками)
- быстро и безопасно но не просто(Rust)
Я не знаю сейчас более менее живых языков, которые решают одновременно три эти проблемы. В этом контексте я не понимаю претензии к Rust. Разработчики сделали ставку на скорость и безопасность решая конкретную проблему - сделать быстрый язык без отстрела себе ног, это имело свои последствия в виде сложности. За все нужно платить. Можно было лучше? Наверное. Но где те идеальные инструменты где все и быстро и надежно и просто? Очевидно нигде. Когда появиться такое то уже будет интересно сравнить или действительно прийти к выводу что Rust не торт. А сравнивать с самострелами в контексте простоты наглухо закрывая глаза на отстреленные конечности такое себе.
Это я в контексте прошлого комментария.
По поводу Эликсира, в данном контексте его проблемой была бы производительность.
Можете поделиться, в какой альтернативе нет глобальных проблем?
Почитал. Целых две и обе невероятно объективные.
Первая - почему Rust, разработчики которого поставили цель сделать язык безопасным управлением памятью и высокой производительностью, вместо этого не сделали еще один Си с бантиком.
Вторая - "Чуждый синтаксис. Это раздражает людей, пришедших из языков семейства Algol’а". Ну это по мне стыд и позор такие претензии предъявлять, что-то на уровне, язык плохой потому что у него маскот - краб.
Вынужден с Вам не сгогласится. Звучит красиво и я сам раньше в это верил, но реальность такова что часто мы встречаем код вполне понятный, вполне компактный но чертовский неудобный и сложный для тестирования, и вот на него нужно написать тесты. И тогда перед нами ставят четыре стула:
декомпозировать сложную логику на несколько более простых публичных частей. Грех, потому как мы начинает подстраивать код под тестирование а не под задачи, возможно эти публичные функции никому не нужны или даже недопустимы для публичного пространства, плюс код сразу усложняется, превращаясь из местечкового в раздробленный.
не заморачиваться с инкапсуляцией и сделать все функции публичными. Думаю комментировать не нужно.
писать супер сложные и адски неудобные тесты с проверкой все возможных комбинаций всех инвариантов этой слогики. Но для этого лучше уже подойдут интеграционные или более реалистичные тесты.
писать на тесты на части приватной логики. Да местами прибиваем гвоздями детали реализации, с другой стороны, unit тесты это и есть история про прибивание гвоздями реализации в том или ином виде. Зато можно написать компактный хороший и простой код с закрытой реализацией и удобным тестированием.
Лично пришел к выводу что последнее меньшее из зол. Судя по тому что во многих языках есть такая возможность, не я один.
Потому что не все типы ссылочные, есть еще и типы значений(i32, bool, структуры с копированием, перечисления и т.д.).В подавляющем большинстве языков дефолт - это передача по значению. Передавать все по ссылке а значения передавать специальным синтаксисом - это разрыв мозга.
Тут вообще не поспорить.
Пока Вы не написали, если честно даже не замечал. А сейчас сходил посмотрел, точно.
Рядом с кодом - модульные. И получаете доступ ко всем приватным функциям модуля, что очень полезно. В различные
testинтеграционные и прочие тесты.Ну справедливости ради, такой велосипед не только в Rust но и в Python, Kotlin, C#, Scala, Swift и будет в Java. Думаю подход выбран для единообразия синтаксиса. В Rust нет перегрузок функций и делать исключения в виде особого синтаксиса именно для PM видимо было нецелесообразно. По карайне мере мне так кажеться.
C# язык в котором есть практически все, в том числе goto
Если по уму то никого. Есть профессия инженер а есть программист. В большинстве своем, названия типо software engineer и прочее - это странные понты некоторых компаний, которые хотят поставить себя выше остальных, потому что у них не какие то никчемные программисты работают а целые software engineers.
Но если бы ко мне пристали с задачей - "нет ну ты все-таки придумай, хотя бы субъективно, как разделить программистов и инженеров", то я бы наверное поделил так: инженеры, пусть это будут разработчики ОС, драфверов, компиляторов, виртуальных машин, игровых движков, железячники т.д., т.е. специалисты, для работы которым нужны фундаментальные знания, часто научный подход, люди которые строят базу для всех остальных, а вот все остальные - это программисты, по сути пользователи того что сделали инженеры. Наверное так.
Интересно наблюдать, в какое еще говно мокнут и обесценят некогда почетное слово инженер.
Сначала, формошлеперы и json-перекладчики провозгласили что все, они теперь не какие то там веб программисты а целые инженеры. Теперь вот докатились что уже вайбкодеры на себе примеряют.
Правильно, сейчас не модно как раньше расти чтобы соответствовать, сейчас проще обесценить термин и натянуть его на себя.
Тогда, во многом солидарен.
Мне вообще нравиться отчасти перекликающийся подход в Rust в этом плане.
Где трейты, очень похожи внешне на интерфейсы но являются не контрактами а по сути ограничителями для дженериков, и по больше части используются для ограничения параметров функций.
Вы показали примеры где интерфейс используется для сокрытия реальной зависимости и как абстрактное возвращаемое значение, но самое интересное обошли стороной - интерфейс как параметр функции. Хотелось бы услышать Ваше мнение по этому поводу.
Ну, во первых, я специально не привожу это как аргумент из-за субъективной его природы. Но тем не менее, полностью не учитывать связь между творчеством и творцом - нельзя.
То что он разжёваны и то что их вообще нужно толковать - это и есть проблема, у нас вроде бы не теология а программирование. Если у принципа нет однозначной интерпретации то пойдут толкования, различные взгляды и направления. Кто будет определять кто из толкователей самый правильный и какая трактовка самая верная? И мы приходим к тому с чего начали: на МР два разработчика будут спорить каждый со своей колокольни, потому что правильного ответа нет как и методики. Если же ссылается к толкованиям от авторитетов то мы превратиться в подобие религии а должны хоть как то походить на науку.
Когда строят здание то руководствуются не абстрактными общими принципами а конкретными обоснованными с точки зрения науки и практики нормами.
Проблема в том что такое прокатывает в гуманитарных дисциплинах, когда судья руководствуется внутренним чувством справедливости, к примеру, в отдельных аспекта. И такое абсолютно не применимо в технических.
В том и проблема, что даже между участниками одной команды не будет понимания, потому что эти самые принципы не дают никакой конкретики, они просто хорошо и красиво звучат. А прицип, который для каждого звучит по разному имеет низкую практическую ценность.
Ну тут Вы явно преувеличиваете. Я ни разу не видел что кто-то предлагал выкинуть вообще все. Чаще, одно радикально поперек другого. И оно не удивительно. К примеру, тот же ООП, который захватил огромную часть IT на несколько десятилетий, практически выдавив любое инакомыслие. Чистый код, SOLID и паттерны проектирования, про которые можно было послушать из каждого утюга. Все это в том числе, дичайшим образом догматизировало огромную часть сообщества и остановило в развитии. Огромное число людей стали не искать решение проблем а то как пользоваться инструментом. Ожидаемо было, что после многих лет в таком режиме, оно бомбанет и многие люди, разочаровавшись в старых инструментах, подходах и авторах, пойдут искать радикально другие подходы. И это хорошо, т.к. маятник будет ходить туда сюда балансируя и выверяя эти самые инструменты и подходы. Намного лучше, чем застрять в развитии, заменив прагматизм на веру.
Понимаете, вопрос ни в том какой у кого мнение. Можно было бы сказать что Роберт Мартин и ко, никакие не светилы с олимпа создавшие грандиозные проекты а скорей успешные писатели. Что если посмотреть его проекты то он давно не следует своим же принципам. Что в своем блоге он писал что когда придумывал SOLID не очень понимал принцип подстановки Лисков. Что принципы формировались так чтобы получилось красивое слово а не по соображениям важности. Но я не будет приводить это как аргументы так как это в некоторой мере субъективно. Я приведу объективный аргумент.
На мой взгляд, в каких либо принципах, главное - это точки их приложения а не красивая идея на фоне. И вот здесь главная проблема. Возьмем SRP, вроде бы и звучит красиво и как будто бы о правильном - "хорошо делай - хорошо будет", но говорит ли нам этот принцип о том как делать хорошо или хотя бы о том что такое ответственность, как это все посчитать или распределить? Нет? Возьмите двух разработчиков дайте им одну и ту же задачу и попросите использовать SRP. С огромной долей вероятности Вы получите разные решения, потому что каждый будет интерпретировать SRP по своему.
Выкатил Петя МР, а ему Дима говорит: ты тут нарушаешь SRP, после чего начинается срачь, т.к у каждого свое видение. Потому как SRP не описываем хоть как то детерминированный механизм реализации собственного постулата а получается тотальная субъективщина. Толку от такого принципа, как от совета прохожего: "живите правильно и все у вас будет". Тоже самое с ISP и т.д. Принцип LSP наиболее адекватный и детерминированный но самый редко применимый, да и к примеру, если посмотреть на стандартную библиотеку Java, то там раз через раз он нарушается (видимо разработчики языка программирования забыли сходить к Мартину).
В общем говоря, принципы SOLID по большей части это красивые советы (возможно даже где-то правильные) без определений их приложения (и соответственно большого практического смысла), которые появились потому что пару человек, которые ни разу не гении в IT, по приколу их собрали исходя из своих субъективных взглядов и понятий красоты, при этом вся заслуга популярности принципов это популярность их автора а не ценность или важность для сферы. Не нужно делать из попсы религию.
Завирусившимся можно назвать тренд на возврат к критическому мышлений, когда мы должны во всем сомневаться, переосмысливать, критиковать и требовать доказательств в противовес догматическому мышлению когда миллионы людей поклоняются тому что какой-нибудь дяденька написал в книжке.
Для меня загадка как Вы это видите в YAGNI но в упор не замечаете что SOLID - ровно тоже самое. При этом считаете что сообщество языка, авторы которого активно продвигали философию простоты во всем, обязано наперекор принципам языка, тащить туда неповоротливые чистые архитектуры, с которыми уже и так намучались в других языках.
Наверное - это перестать делать вид что какой-нибудь SOLID - это действительно что-то умное и важное посланное нам
полу-богамивеличайшими светилами IT а не абстрактный, завирусившийся набор практически бесполезных советов в духе "хорошо делай - хорошо будет", придуманных из буков собранных по принципу как красивее в слово собрать, дяденьками которым банально было нечем заняться.Нет. На уровне кода. В любом месте можно задать контекст выполнения.
Всю 30 летнюю экосистему Java взяли и по быстрому переписали? Оптимистично.
Есть разница между тем что автор библиотеки написал async но не реализовал, потому что он дурак и тем когда автор ничего не писал и не гарантировал.
Так Вы и рассуждайте сегодня. А сегодня есть go и java а подавляющее большинство остальных языков раскрашивают функции. Что вы предлагаете, переделать им на виртуальные потоки все? Если нет, то что по Вашему "зло во плоти" то, инструмент который позволил сэкономить 11 лет? Понимаете, если бы Java сейчас выкатила что-то невероятное, инновационное, меняющее подходы кардинальным образом то это еще ладно, но по факту но они просто догнали конкурентов. Поэтому я не понимаю идею про "зло во плоти", есть работающий много лет инструмент а есть может быть чуть более удобное решение(время покажет) которое запоздало на десяток лет. Async/await явно прорывное для своего времени решение которое позволило многим языкам и экосистемам работать удобно и эффективно, в то время как другие десять лет изобретали, так что я бы не стал это называть "зло во плоти" точно.
Ну во-первых. Будут блокироваться вызовы или нет, зависит от контекста. Вот находитесь Вы в произвольном месте кода и знать не знаете как этот код будет работать, потому как это целиком и полностью зависит от вызывающего - изволил он запустить метод, который запустил метод, который запустил метод... из виртуального потока или платформенного. В отличии от Go, где весь рантайм асинхронный или C# где четко видно по функции синхронная она или нет, в Java смотря на код вообще невозможно сделать никаких предположений о том как он выполниться. Тоже и с ошибками, если кто-то ,на верхнем уровне, создаст случайно не виртуальный поток, то все начнет работать не виртуально и никто этого вообще не заметит.
Во-вторых. То что написано в документации и самое главное, как реализована библиотека - критически важно. Чуда не случиться. Если Вы вызываете библиотеку внутри которой создаются платформенные потоки по старой доброй памяти, или она использует свой пулл не виртуальных потоков или например внутри нее нативные вызовы, которые будут блокировать Ваши потоки, то работа с асинхронностью превратиться в тыкву. Самое неприятное что проблемы могут быть даже не у самой библиотеки а у библиотек которых она использует или библиотек библиотек. Причем самое обидное все это будет неявно. Вообще нет четкой границы, где версия n блокирующая а версия m неблокирующая, можно только или верить документации, которая может врать или путешествовать по кишкам библиотеки и всех ее зависимостей. В отличии от тех же раскрашенных функций, где автор явно выражает это в API.
Ну Вы написали что раскраска функций - зло во плоти, а я считаю что пилить фичу 11 лет, заставляя либо тысячи проектов быть отсталыми и не эффективными или разработчиков подвергать мукам работы с реактивным программированием, только ради того чтобы быть похожими на недо-Go 2012 года - вот что настоящее зло. Есть хорошая фраза - "лучшее враг хорошего". B Java может себе позволять такие фортели только из-за своей мега популярности и огромной значимости для энтерпрайза .