Точнее добавился ещё один annotation processor, который часть своих функций выполняет через дикие хаки.
И без поддержки в IDE c ним никак.
Kotlin точно так же всовывается в любой проект на любой стадии без проблем.
А зачем переписывать? На Lombok (это фактически диалект Java) тоже никто бы не стал переписывать всё с нуля.
И там, и там можно писать новый код «в новом стиле» (без шаблонных геттеров и прочего), не трогая старый.
Я согласен с тем, что это может быть далеко не самой приоритетной задачей для разработчиков данной ОС, и это совершенно нормально.
Но вот концепция «один ПК — один пользователь» — нет. Сегодня вам это не надо, а завтра понадобится, и что делать будете, систему менять? Возникнуть такая потребность может в разных случаях, например +1 пользователь ПК в доме или понадобится дать кому-то «гостевой» доступ.
Возможно, «бред» — это слишком категорично, но я не представляю современную «серьёзную» ОС даже для дома без поддержики разных пользователей. Это выглядит как Windows 9x на фоне Windows NT.
Считать, что у домашнего компьютера может быть только один пользователь — это странновато. И дело не только в безопасности — несколько профилей дают возможность персонализации, разграничения файлов. А главное, пароли и cookie в браузере у каждого свои (не переключаться же на свою учётку на каждом сайте).
Это есть даже в Android на смартфонах, и некоторым это действительно нужно. Отсутствие такой возможности в «современной» ОС для ПК — это бред, и сказать «это фича» нельзя.
Обновил браузер — все панели скрылись. То есть остался только заголовок с кнопками меню и свернуть/развернуть/закрыть. Включил обратно в настройках. Интересно, что это было такое.
Смешаны в кучу претензии к спецификации схемы и к reference implementation кодогенератора. Никто не заставляет использовать protoc от Google.
Лично моё мнение:
Заточенность системы типов на типичные случаи использования — это не так уж и плохо. Почти все описанные проблемы решаются обёртыванием в отдельный тип.
Работа с опциональными типами в сгенерированном гугловым компилятором коде действительно ужасна: эти hasFoo() и getFoo() с дефолтными значениями — прямой путь к неожиданному поведению кода вместо вылета NullPointerException. Значение по умолчанию практически никогда не имеет смысла — какие полезные операции можно сделать с объектом, у которого во всех полях нули, пустые строки и вложенные такие же пустые объекты? Это выглядит дико даже в Java, не говоря о языках со встроенными средствами работы с опциональными значениями.
Proto3 пошёл ещё дальше и теперь такая же ситуация в спецификации, так как required полей больше нет. А уж что там происходит с enum — это вообще нонсенс. Не указал значение — получаешь первое объявленное. И нет способа узнать, было ли оно установлено или это "дефолтное". В результате десериализации можно получить всё что угодно — любое поле могло быть не задано и код будет по-тихому работать не так, как задумано.
По мне так такая "схема данных" — это просто мусор.
То, что из-под крыла Google выходит нечто сомнительного качества, я вижу не в первый раз. Впрочем, что ещё можно ожидать от большой корпорации, в которой разными продуктами занимаются совершенно разные люди с разными целями, умениями и бюджетами.
Отличные задачи! Небольшие и близкие к практике.
Чего не скажешь о таковых на стендах у многих других компаний — в стиле "что будет при запуске такого наркоманского кода с сайд-эффектами в Stream.peek()".
Вы, выполняя тестовое, разве выполняете трудовые обязанности («приступили к работе»)?
— Вы не находитесь на рабочем месте.
— Вы получили его не от своего (потенциального) руководителя, а от HR-а.
— Код, который вы при этом пишете, не принадлежит работодателю.
Вы это не докажете, потому что это не так. Если только у работодателя юристы совсем дураки или судья дурак или подкуплен.
Про разные реализации для Latin-1 и юникодовских строк нет смысла писать, не упомянув Compact Strings.
А они, кстати, новинка для тех, кто переходит с Java 8.
Спасибо за ответ.
Вот так и получается, что отсутствие GC принуждает иметь средства для управления любыми ресурсами (память, сокеты, файлы и т.п.), а если он есть, то можно ни о чём не думать до встречи с нативными ресурсами, и тут становится неудобно.
Я согласен, что это редко приходится делать, но иногда, к сожалению, даже в чисто прикладных программах возникает такая необходимость.
Проблема не в том, что use определён только для AutoCloseable, а в том, что как и try-with-resources в Java он спасает только в ситуации, когда надо взять ресурс, что-то сделать с ним и освободить в одном блоке кода.
Если я хочу например абстрагировать два ресурса, создавая и освобождая их вместе со своим объектом, начинается боль. Вот так сделать нельзя:
class MyClass : AutoCloseable {
val resource1 = Resource1(...)
val resource2 = Resource2(...)
override fun close() = listOf(resource1, resource2).forEach { it.close() }
}
Есть много нюансов с обработкой ошибок при инициализации и освобождении, которые надо учесть, чтобы не допустить утечек.
JVM любит память. Очень.
Любое приложение на JVM рано или поздно съест всю память, выделенную под хип, и даже не будет возвращать её обратно системе, просто потому, что так работает GC (по крайней мере, те, которые сейчас в Hotspot JVM).
И без поддержки в IDE c ним никак.
Kotlin точно так же всовывается в любой проект на любой стадии без проблем.
И там, и там можно писать новый код «в новом стиле» (без шаблонных геттеров и прочего), не трогая старый.
Но вот концепция «один ПК — один пользователь» — нет. Сегодня вам это не надо, а завтра понадобится, и что делать будете, систему менять? Возникнуть такая потребность может в разных случаях, например +1 пользователь ПК в доме или понадобится дать кому-то «гостевой» доступ.
Возможно, «бред» — это слишком категорично, но я не представляю современную «серьёзную» ОС даже для дома без поддержики разных пользователей. Это выглядит как Windows 9x на фоне Windows NT.
Это есть даже в Android на смартфонах, и некоторым это действительно нужно. Отсутствие такой возможности в «современной» ОС для ПК — это бред, и сказать «это фича» нельзя.
grpc, webp, google cloud
Ну было бы странно, если бы на go не было всё готовое для использования этих технологий.
Обновил браузер — все панели скрылись. То есть остался только заголовок с кнопками меню и свернуть/развернуть/закрыть. Включил обратно в настройках. Интересно, что это было такое.
Поясните, пожалуйста, каким образом к снимкам может получить доступ стороннее приложение?
Да, так и делаем. Но это же ужасно, вам не кажется?
Смешаны в кучу претензии к спецификации схемы и к reference implementation кодогенератора. Никто не заставляет использовать protoc от Google.
Лично моё мнение:
По мне так такая "схема данных" — это просто мусор.
То, что из-под крыла Google выходит нечто сомнительного качества, я вижу не в первый раз. Впрочем, что ещё можно ожидать от большой корпорации, в которой разными продуктами занимаются совершенно разные люди с разными целями, умениями и бюджетами.
Отличные задачи! Небольшие и близкие к практике.
Чего не скажешь о таковых на стендах у многих других компаний — в стиле "что будет при запуске такого наркоманского кода с сайд-эффектами в
Stream.peek()".— Вы не находитесь на рабочем месте.
— Вы получили его не от своего (потенциального) руководителя, а от HR-а.
— Код, который вы при этом пишете, не принадлежит работодателю.
Вы это не докажете, потому что это не так. Если только у работодателя юристы совсем дураки или судья дурак или подкуплен.
Про разные реализации для Latin-1 и юникодовских строк нет смысла писать, не упомянув Compact Strings.
А они, кстати, новинка для тех, кто переходит с Java 8.
Но одну проблему такой паттерн не решает: компилятор никак не помогает не забыть применить его.
Спасибо за ответ.
Вот так и получается, что отсутствие GC принуждает иметь средства для управления любыми ресурсами (память, сокеты, файлы и т.п.), а если он есть, то можно ни о чём не думать до встречи с нативными ресурсами, и тут становится неудобно.
Я согласен, что это редко приходится делать, но иногда, к сожалению, даже в чисто прикладных программах возникает такая необходимость.
Проблема не в том, что
useопределён только дляAutoCloseable, а в том, что как и try-with-resources в Java он спасает только в ситуации, когда надо взять ресурс, что-то сделать с ним и освободить в одном блоке кода.Если я хочу например абстрагировать два ресурса, создавая и освобождая их вместе со своим объектом, начинается боль. Вот так сделать нельзя:
Есть много нюансов с обработкой ошибок при инициализации и освобождении, которые надо учесть, чтобы не допустить утечек.
Странная подборка (для совсем начинающих?), учитывая отсутствие must have бестселлера Effective Java.
Планируется ли в Kotlin хоть какая-то поддержка RAII?
use { }не в счёт, хотя его и достаточно в самом простом и частом случае.Любое приложение на JVM рано или поздно съест всю память, выделенную под хип, и даже не будет возвращать её обратно системе, просто потому, что так работает GC (по крайней мере, те, которые сейчас в Hotspot JVM).