Комментарии 62
Хотелось бы еще увидеть сравнение скорости работы этих программ
Думаю в этой задаче разница будет не заметна, скорость будет определяться внешними факторами: открытием страниц и записью на диск. Но попробовать можно, правда у меня интернет не очень, могу только предложить jar для теста.
Моё субъективное мнение: скорость — это не главное. В крупном приложении скорость определяется архитектурой. На много важнее, чтобы приложение работало правильно и легко изменялось.
Моё субъективное мнение: скорость — это не главное. В крупном приложении скорость определяется архитектурой. На много важнее, чтобы приложение работало правильно и легко изменялось.
В плане «работало и легко изменялось» имхо выигрывает Go, как в принципе и какие-нибудь другие компилируемые ЯП, которые не требуют установки виртуальных машин/интерпретаторов.
НЛО прилетело и опубликовало эту надпись здесь
Так какая разница, если на машине стоит старый рантайм? Всё зависит от продукта и клиентов, одно дело тырпрайз, где ваш продукт может нигде кроме как уютненьких серверов не крутиться, и совсем другое — десктоп, где может быть дичайший зоопарк. Вот не установит/снимет галочку/удалит/не обновит юзер нужный вам Java runtime, и всё.
Ну или я не понял суть OSGi.
Ну или я не понял суть OSGi.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Я говорил к тому, что бывают случаи(подобные этому), где имеет значение отсутствие лишних прослоек и зависимостей.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Сейчас за 1500 рублей продаются вполне работающие китайские андроиды — для них можно скомпилировать бинарник из Go-кода.
Ну вы же понимаете, что создание 100 потоков на Java — это не то же самое, что создание 100 горутин? В данном простом примере воркеров всего 4, так что можно и забить, а когда будет что-то помасштабнее, чем просто опрос одного HTTP-сервера, то в Java начнутся проблемы. В общем, пока в Java не реализуют настоящую вытесняющую многозадачность, Java так и будет сосать в сторонке.
Правда интересно что в джава не так с этим?
Каждый поток кушает ресурсы, даже если в данный момент они ничего не делает (например, висит на блокирующем вызове).
Но эта проблема спокойно решается в библиотеке, без изменения языка.
Но эта проблема спокойно решается в библиотеке, без изменения языка.
Гляньте вот этот тред. Там всё довольно неплохо описано
НЛО прилетело и опубликовало эту надпись здесь
Я что-то слышал про то, что в Java есть зеленые потоки, которые легковесны как горутины. Было бы не плохо, если бы кто-то что-то про это разъяснил.
НЛО прилетело и опубликовало эту надпись здесь
Сейчас пилят библиотеку quasar для реализации зеленых потоков, но там какой-то хардкор с байткод-инструментацией происходит, чтобы всё это могло работать поверх JVM. А вот пример уже рабочего кода.
пишите на clojure и используйте core.async ;)
Akka? Вместо горутин — акторы.
Akka реализуется поверх обычных OS потоков, в результате чего наследует все те же проблемы. Если не делать блокирующие вызовы, то да, канает. Но а если я хочу? Ну потому что синхронный код выглядит проще и читабельнее, чем асинхронный. Да, есть фьючеры, коллбэки, скедулеры, но с ними код выглядит сложнее — это факт. Спросите любого эрланг-программиста, пересаживающегося на Akka.
Читая статью, создается впечатление, что все более-менее нормально, но вот когда открываешь код…
Код написан плохо не потому, что в нем не хватает паттернов. Грабберы при первом IOException завершатся — программа никогда не закончится (фактически зависнет). Один и тот же файл одновременно открывается на запись и на чтение. Входные параметры не проверяются. Нет синхронизации. Если программа остановится в момент записи в файл — он может быть поврежден, далее на чтении валидность не проверяется и программа прочитает битый хэш. За Hex.encodeHexString еще можно было побороться и написать самому, а не тащить сразу либу. Хэши сохраняются в файл как массив байт и на чтении каждый раз конвертятся в строку — можно было сразу записать строку. Используются обычные стримы, но вдруг — BufferedWriter, который все время флашится. Число записей в секунду округляется.
Сравнивайте go с питоном. там тоже кодестайл влияет на смысл кода.
То же на go: time.Sleep(100 * time.Millisecond)
Что-то на Java я такое не увидел.
Ну и не совсем понятен посыл статьи. Производилось сравнение? Какое сравнение? Читабельности кода? Скорости? Использование тредов вместо гороутин — это совсем не равноценная замена: по семантике они чем-то похожи, а по смыслу — совсем не похожи. Делать выводы на основе одной несложной задачи тоже не совсем верно. Что автор хотел показать-то?
Что-то на Java я такое не увидел.
Ну и не совсем понятен посыл статьи. Производилось сравнение? Какое сравнение? Читабельности кода? Скорости? Использование тредов вместо гороутин — это совсем не равноценная замена: по семантике они чем-то похожи, а по смыслу — совсем не похожи. Делать выводы на основе одной несложной задачи тоже не совсем верно. Что автор хотел показать-то?
Использование time.Sleep обсуждали в этой ветке комментариев. Если я правильно понял, это нужно для того, чтобы дать возможность выполниться основному потоку. Но в моём случае это не нужно, т.к. я явно указал приоритет worker.setPriority(2). Чтобы сохранить дословность пересказа, можно использовать Thread.sleep(100), но лучше подойдёт Thread.yield() — он переместит поток в конец очереди планировщика без задержки.
О смысле статью расскажу подробнее. Я работаю с Java относительно давно, и в целом уже нормально разобрался, а о Go только слышал, но довольно много. Мне стало интересно, стоит ли бросать Java и переходить на более современный Go? Поэтому я и решил их сравнить на этой задаче. Как вывод скажу, что Go моложе и что-то в нём сделано удобнее, и если вы не знаете ни того ни другого, то возможно лучше выбрать Go. Но Java пока держится, хоть и некоторые решения выглядят как костыли, например аннотации. И имея опыт в Java пока рано её бросать.
О смысле статью расскажу подробнее. Я работаю с Java относительно давно, и в целом уже нормально разобрался, а о Go только слышал, но довольно много. Мне стало интересно, стоит ли бросать Java и переходить на более современный Go? Поэтому я и решил их сравнить на этой задаче. Как вывод скажу, что Go моложе и что-то в нём сделано удобнее, и если вы не знаете ни того ни другого, то возможно лучше выбрать Go. Но Java пока держится, хоть и некоторые решения выглядят как костыли, например аннотации. И имея опыт в Java пока рано её бросать.
Я работаю с Java относительно давно
Ха-ха. Как сказал Joel Spolsky, 5 years of experience may be 1 year repeated 5 times
Мало того, что у вас ужасный код, так ещё и непотокобезопасный. Почему вы quotesCount модифицируете из нескольких потоков без синхронизации?
Это похоже на вызов :) Я не могу не ответить.
Вам не кажется глупым ради обнуления счётчика городить синхронизацию? Ведь самое страшное, что может произойти — мы недосчитаемся цитаты при подсчёте скорости.
Тогда уж больше опасность представляет чтение этих переменных, они ведь не объявлены volatile, и результат может быть устаревшим.
Вы уверены, что нужно уделять столько внимания вспомогательной функциональности? Вероятность ошибки ведь очень низкая.
Вам не кажется глупым ради обнуления счётчика городить синхронизацию? Ведь самое страшное, что может произойти — мы недосчитаемся цитаты при подсчёте скорости.
Тогда уж больше опасность представляет чтение этих переменных, они ведь не объявлены volatile, и результат может быть устаревшим.
Вы уверены, что нужно уделять столько внимания вспомогательной функциональности? Вероятность ошибки ведь очень низкая.
volatile
Вот честное слово не это хотел написать :)
На работе pastebin заблокирован злой прокси, кода не видел. Не хватило бы сделать счетчик volatile?
На работе pastebin заблокирован злой прокси, кода не видел. Не хватило бы сделать счетчик volatile?
Синхронизация и volatile несут несколько различный смысл.
Думаю, что volatile значительно улучшило бы ситуацию в случае инкремента. Без volatile переменная может кэшироваться в потоке. Т.е. есть вероятность, что переменная обнулится из другого потока, а мы не заметим, и присвоим ей {старое значение + 1}.
Но, теоретически, между чтением и записью переменная всё равно может быть изменена другим потоком. Наиболее вероятно это между подсчётом скорости и обнулением, т.к. там несколько операций выполняется. Поэтому для полной уверенности нужно синхронизировать блок от чтения до записи.
Думаю, что volatile значительно улучшило бы ситуацию в случае инкремента. Без volatile переменная может кэшироваться в потоке. Т.е. есть вероятность, что переменная обнулится из другого потока, а мы не заметим, и присвоим ей {старое значение + 1}.
Но, теоретически, между чтением и записью переменная всё равно может быть изменена другим потоком. Наиболее вероятно это между подсчётом скорости и обнулением, т.к. там несколько операций выполняется. Поэтому для полной уверенности нужно синхронизировать блок от чтения до записи.
Забавно смотреть, как автор, не разобравшись толком в Go, начинает сравнивать его с другими языками.
Для начала, флаги можно указать так:
var (
WORKERS = flag.IntVar(«w», 2, «количество потоков»)
REPORT_PERIOD = flag.Int(«r», 10, «частота отчетов (сек)»)
DUP_TO_STOP = flag.Int(«d», 500, «кол-во дубликатов для остановки»)
HASH_FILE = flag.String(«hf», «hash.bin», «файл хешей»)
QUOTES_FILE flag.String(«qf», «quotes.txt», «файл записей»)
)
это гораздо короче и удобнее того что автор понаписал как для java, так и для Go. Более того, аналога этой конструкции в java нет.
Далее, автор превратно понял логику обработки исключений в Go. Если по каким-то причинам удобнее при ошибке прерывать flow и обрабатывать в 1 месте, вы можете даже не проверять err != nil, а просто recover'ить рантайм панику при вызове метода у нулевого объекта, созданного при ошибке — не идеальное решение, но избавляет от проверки результатов работы функции.
Вообще же сама по себе логика, когда при почти любой ошибке прерывается flow и исключения «обрабатываются» где-то высоко, если явно не предусмотрено обратное — ущербна — непредусмотренная явно ошибка может привести к непредсказуемым последствиям. Особо приятно ловить в Java null pointer exception. В Go в этом смысле более явный и унифицированный подход, когда разворачивание стека вызовов наверх происходит только по делу — при паниках — а ошибки возвращаются из самой функции.
В данном случае у вас go-код, иллюстрирующий парсинг HTML, работает неидентично java-коду. Если в java-код добавить дополнительный try-catch вокруг запроса страницы, чтобы она не падала при сетевых ошибках — получится ещё уродливее, чем в go, в дополнение к неудобной проверке ошибки далеко от её места возникновения.
Прибавляя к этому абсурдность сравнения системных тред и лёгких тред, общий вывод печальный для автора: данная статья — треш, и её надо очень долго дорабатывать, чтобы она не обесценивала хабр своим присутствием.
Для начала, флаги можно указать так:
var (
WORKERS = flag.IntVar(«w», 2, «количество потоков»)
REPORT_PERIOD = flag.Int(«r», 10, «частота отчетов (сек)»)
DUP_TO_STOP = flag.Int(«d», 500, «кол-во дубликатов для остановки»)
HASH_FILE = flag.String(«hf», «hash.bin», «файл хешей»)
QUOTES_FILE flag.String(«qf», «quotes.txt», «файл записей»)
)
это гораздо короче и удобнее того что автор понаписал как для java, так и для Go. Более того, аналога этой конструкции в java нет.
Далее, автор превратно понял логику обработки исключений в Go. Если по каким-то причинам удобнее при ошибке прерывать flow и обрабатывать в 1 месте, вы можете даже не проверять err != nil, а просто recover'ить рантайм панику при вызове метода у нулевого объекта, созданного при ошибке — не идеальное решение, но избавляет от проверки результатов работы функции.
Вообще же сама по себе логика, когда при почти любой ошибке прерывается flow и исключения «обрабатываются» где-то высоко, если явно не предусмотрено обратное — ущербна — непредусмотренная явно ошибка может привести к непредсказуемым последствиям. Особо приятно ловить в Java null pointer exception. В Go в этом смысле более явный и унифицированный подход, когда разворачивание стека вызовов наверх происходит только по делу — при паниках — а ошибки возвращаются из самой функции.
В данном случае у вас go-код, иллюстрирующий парсинг HTML, работает неидентично java-коду. Если в java-код добавить дополнительный try-catch вокруг запроса страницы, чтобы она не падала при сетевых ошибках — получится ещё уродливее, чем в go, в дополнение к неудобной проверке ошибки далеко от её места возникновения.
Прибавляя к этому абсурдность сравнения системных тред и лёгких тред, общий вывод печальный для автора: данная статья — треш, и её надо очень долго дорабатывать, чтобы она не обесценивала хабр своим присутствием.
Да будет холивар :)
Вы, очевидно, не сталкивались с большими приложениями. Надо сказать спасибо, что это так. Основное применение java это бизнес приложения. У нас всегда несколько уровней и ошибка должна обрабатываться там, где известно что с ней делать, т.е. гораздно чаще нам и нужно бросить ошибку наверх. И спасибо, что у нас нету «err != nil».
Вот это поворот!
Если вы ловите null pointer, значит проблема в коде, java тут не при чем
Вообще же сама по себе логика, когда при почти любой ошибке прерывается flow и исключения «обрабатываются» где-то высоко, если явно не предусмотрено обратное — ущербна
Вы, очевидно, не сталкивались с большими приложениями. Надо сказать спасибо, что это так. Основное применение java это бизнес приложения. У нас всегда несколько уровней и ошибка должна обрабатываться там, где известно что с ней делать, т.е. гораздно чаще нам и нужно бросить ошибку наверх. И спасибо, что у нас нету «err != nil».
непредусмотренная явно ошибка может привести к непредсказуемым последствиям
Вот это поворот!
Особо приятно ловить в Java null pointer exception.
Если вы ловите null pointer, значит проблема в коде, java тут не при чем
И вообще не стоит называть что-либо ущербным, если заведомо знаете, что это субъективное мнение.
Зато у нас есть другие плюшки, например можем ограничить длину очереди, если не будем успевать её разгрести.Ну так и в Гоу это есть: github.com/bolknote/NarchTools/blob/master/cgodownloader.go#L85 тут она как раз у меня ограничивается.
С обработками ошибок я не понял. В Гоу вы тоже можете их не обрабатывать, программа и сама свалится, а если вы не используете код ошибки, то можно его не забирать. Т.е. вместо
//открытие файла на чтение
hash_file, err := os.OpenFile(HASH_FILE, os.O_RDONLY, 0666)
//открытие файла на запись
hash_file, err := os.OpenFile(HASH_FILE, os.O_APPEND|os.O_CREATE, 0666)
можно написать
//открытие файла на чтение
hash_file, _ := os.OpenFile(HASH_FILE, os.O_RDONLY, 0666)
//открытие файла на запись
hash_file, _ := os.OpenFile(HASH_FILE, os.O_APPEND|os.O_CREATE, 0666)
Java с Go сравнивают не из-за синтаксиса, а из-за того, что Go компилируемый, а компилятор с хорошим оптимизатором. А Java собирается в байт-код и выполняется в VM.
Ну а во-время выполнения байт-код компилируется, и по скорости выполнения проигрыш обычно совсем не значительный, в сравнении со скомпилированным кодом.
Да, где байт-код транслируется в машинный, причем транслятор очень хороший.
Как-то мне try-resource показались значительно хуже defer. Особенно если их будет много да еще и вложенных.
Заменять горутины нитями тоже не то: это как нити заменять процессами.
Заменять горутины нитями тоже не то: это как нити заменять процессами.
Обращу внимание на новые неблокирующие классы для работы с файлами из Java7. Найти из можно в java.nio
Чагоу? В каком месте они, простите, неблокирующие?
java.nio.files.WatchService — хоть бы погуглили сначала
Погуглить надо бы вам :) WatchService, что бы это ни было, обертка вокруг inotify, fsevents и что-там-в-винде или самопальная реализация в отдельном тредике, или и то и другое, не имеет никакого отношения к неблокирующей работе с файлами :)
К неблокирующей работе с файлами можно отнести то, как с ними работает nodejs, erlang (при +A > 0), linux AIO, libeio. И то, все это можно назвать неблокирующей работой с файлами лишь условно :)
К неблокирующей работе с файлами можно отнести то, как с ними работает nodejs, erlang (при +A > 0), linux AIO, libeio. И то, все это можно назвать неблокирующей работой с файлами лишь условно :)
Соглашусь. Вы правы.
Строго говоря, в
java.nio есть классы для асинхронного (с Java7) и неблокирующего на основе селекторов (c Java 1.4) ввода-вывода. С файлами, правда, нельзя работать с помощью селекторов, а с сокетами — ещё как можно.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Java vs Go