Интересное замечание. В этом как раз вся суть — на С можно великолепно разруливать ошибки, равно как и в любом другом языке, и любым другим способом. Те же исключения — уверен, что какая-то часть читателей статьи напишут «да вы просто не умеете работать с исключениями».
Но в этом и соль — если с одним инструментом, для того чтобы «делать правильно» нужно набраться опыта в течении 5-ти лет и прочитать 3 талмуда от зубров computer science, а с другим — достаточно просто взять и начать пользоваться инструментом — то второй вариант будет эффективнее в долгосрочной перспективе.
Попробую иначе сформулировать — научиться можно всему, любой технике любой сложности. Но в общем случае, люди будут выбирать более простой путь и более простые инструменты. Go позволяет не читая талмуды писать качественный и надежный в плане обработки ошибок код. Не инвестируя дополнительных усилий именно в этот аспект.
Нет-нет, не так. Исключение — это не «ошибка в Java» — это метод сообщить вышестоящей функции о том, что вызываемая функция завершилась с ошибкой. Важно не путать обработку ошибок и их передачу.
Для *исключительных* ситуаций — когда вот точно все, капец наступил и программа дальше продолжаться не может, есть механизм panic()/recover() — blog.golang.org/defer-panic-and-recover. Его можно использовать как замену исключениям, но так почти никто не делает — это плохая практика.
Да, это как раз тот единственный случай, когда исключения дают более читабельный код.
Но на практике такой код (особенно если речь идет о более чем 3-х повторениях) встречается редко, и если уж и встречается — то это повод для рефакторинга — вот тут как раз недавно Роб Пайк на эту тему написал, как можно такие ситуации красиво разруливать: blog.golang.org/errors-are-values.
Важно понимать, что в Go исключений нет не потому, что авторы считают, что «исключение — это зло в высшей инстанции», а потому что не видят способа, как можно добавить исключения и не сделать язык более сложным и более подверженным неправильному использованию обработки ошибок с их помощью.
Ну и вот есть имплементация Try() Catch() Finally() для Go — но вряд ли ей кто-то будет пользоваться. Чисто proof-of-concept эксперимент: github.com/manucorporat/try
«Влепить» — да, но это бросается в глаза и создает дискомфорт. К примеру, «не проверить код возврата в С» — не создает дискомфорта и не бросается в глаза — потому и используется повсевместно :)
Про «лучше уж» — это уже кому-как. У меня нет возможности на большинстве серверов, с которыми приходится работать, поднимать OpenVPN. Подозрений в том, что SSP протокол тайно взломан, и есть кто-то, кто перехватит мои соединения и будет смотреть, как я пишу код на удаленном сервере — тоже пока что нет ) Поэтому для меня лично пока что вариант «запустить mosh и получить 100500 плюшек» выигрывает в сравнении с «устанавливать на сервер стек решений, хаков, учить новые комбинации клавиш, тюнить сервера и получить 100500/10 плюшек».
Но согласен, что кому-то это может быть более релевантно и решение VPN/screen/ssh будет более правильным.
Господа, а вот что вы сейчас пытаетесь доказать? Что авторы mosh — тупые, не поняли, что могли бы просто screen использовать и, как тут замечательно написали, «вдумчиво работать в консоли»? )
Mosh — сохраняет соединение (и, как следствие — сессию и контекст), screen — только сессию, и все равно вынуждает переподключаться (да, можно ставить бесконечные keepalive на каждом SSH-сервере, тюнить и все такое — но в какой-то момент вам надоесть каждый раз под себя тюнить все сервера, особенно если они не ваши и тюнить там нельзя ничего).
Mosh — решает еще несколько проблем юзабилити remote shell, screen — нет.
По какой причине я, как пользователь remote shell, должен захотеть поменять удобный all-in-one mosh-solution, на стек решений и хаков screen/tmux/vpn/ssh-tuning/etc? При прочих равных всегда выигрывает решение, требующее меньшего количества телодвижений, не так ли?
«имплементацию Find у string» — это поиск подстроки, я так понимаю? Операций на строках достаточно много и они вынесены в стандартную библиотеку, в package strings: golang.org/pkg/strings
Find в данном случае вам нужно или Contains (содержит или нет) или Index (позиция, с которой содержит).
А можно где-то просветить неграмотных — чем те или иные лучше? (ключи меньше — как-то не катит на весомый аргумент). Просто академический интерес или есть реальные преимущества?
stdlib sort использует reflection, что медленно и велосипед
В каком месте и для чего sort использует reflection? Желательно прямо строчку кода укажите :)
godoc.org/bitbucket.org/santucco/btree построен на encoding/binary, то есть не typesafe, а скорее untyped
нет, encoding/binary используется исключительно для чтения/записи в с storage (io.ReadWriter) — это задача сериализации/десереализации данных. Сам же b-tree алгоритм построен исключительно на использовании интерфейсов.
Поймите, generics — это написание алгоритмов в type-независимой манере. Go дает возможность это делать с помощью интерфейсов — ваш тип должен реализовать методы, необходимые для работы алгоритма — и наслаждайтесь. В С++ эту проблему решили иначе — темплейтами, в Java — еще иначе — и везде за счет потерь в скорости, читаемости и/или эффективности. И люди, привыкшие к тем или иным решениям, просто чувствуют себя без них неудобно в новом языке — отсюда и эти «Пайк, спаси, введи темплейты». Но это неправильно.
Или вот еще — когда для каких-то особых случаев людям советуют использовать reflect или interface{} с кастингом — они начинают рассказывать про «это медленно» и вообще, мы хоть это за zero costs получить. Блин, конечно медленно — а в в других языках, generics, думаете бесплатно получается?
В конце-концов да, тем кто прямо без темплейтов жить не может — (уже почти) есть go generate и были какие-то ужасные (как по мне) решения вроде gonerics.
Вобщем я все еще в поиске реальных use-кейсов, где Go без имплементации C++/Java-style generics не справляется красиво.
Ну, тогда еще не было goimports :)
Кстати, я им немного попользовался и вернулся обратно на go fmt (при сохранении всмісле) — во-первых, как-то уже привык добавлять импорты сам перед тем, как использовать какие-то вещи из них — не добавив, банально автодополнение не сработает, а удалять через :GoDrop легче простого, не сходя с нужной строки. А во-вторых, там есть баг, до которого у меня руки не дошли разобраться — но imports в некоторых случаях, неверно угадывает путь и вставляет неправльные import-ы.
Люди, как правило, просто хотят решать задачу тем же путем, которым они привыкли в прошлых языках.
Посмотрите, как реализован stdlib-овский sort, или приведенный выше B-Tree.
Это просто другой подход к проблеме. Можно спорить о том, какие минусы и какие плюсы этого подхода, и даже спорить — а считать ли этот подходит тоже как вид generics, но уж точно на «Go тут фейлится» не подходит.
Подпишусь. Сколько нервов и споров уходило в других языках на «как надо расставлять скобочки», и сколько на маты, когда смотришь код людей, которые класть хотели на форматирование.
В Go в итоге 99.9% кода гарантированно читабельно и аккуратно.
Но в этом и соль — если с одним инструментом, для того чтобы «делать правильно» нужно набраться опыта в течении 5-ти лет и прочитать 3 талмуда от зубров computer science, а с другим — достаточно просто взять и начать пользоваться инструментом — то второй вариант будет эффективнее в долгосрочной перспективе.
Попробую иначе сформулировать — научиться можно всему, любой технике любой сложности. Но в общем случае, люди будут выбирать более простой путь и более простые инструменты. Go позволяет не читая талмуды писать качественный и надежный в плане обработки ошибок код. Не инвестируя дополнительных усилий именно в этот аспект.
Для *исключительных* ситуаций — когда вот точно все, капец наступил и программа дальше продолжаться не может, есть механизм panic()/recover() — blog.golang.org/defer-panic-and-recover. Его можно использовать как замену исключениям, но так почти никто не делает — это плохая практика.
Но на практике такой код (особенно если речь идет о более чем 3-х повторениях) встречается редко, и если уж и встречается — то это повод для рефакторинга — вот тут как раз недавно Роб Пайк на эту тему написал, как можно такие ситуации красиво разруливать: blog.golang.org/errors-are-values.
Важно понимать, что в Go исключений нет не потому, что авторы считают, что «исключение — это зло в высшей инстанции», а потому что не видят способа, как можно добавить исключения и не сделать язык более сложным и более подверженным неправильному использованию обработки ошибок с их помощью.
Ну и вот есть имплементация Try() Catch() Finally() для Go — но вряд ли ей кто-то будет пользоваться. Чисто proof-of-concept эксперимент: github.com/manucorporat/try
Но со screen у меня не исчезает надобность реконнекта, не так-ли?
Про «лучше уж» — это уже кому-как. У меня нет возможности на большинстве серверов, с которыми приходится работать, поднимать OpenVPN. Подозрений в том, что SSP протокол тайно взломан, и есть кто-то, кто перехватит мои соединения и будет смотреть, как я пишу код на удаленном сервере — тоже пока что нет ) Поэтому для меня лично пока что вариант «запустить mosh и получить 100500 плюшек» выигрывает в сравнении с «устанавливать на сервер стек решений, хаков, учить новые комбинации клавиш, тюнить сервера и получить 100500/10 плюшек».
Но согласен, что кому-то это может быть более релевантно и решение VPN/screen/ssh будет более правильным.
Но вообще немного weird дизайн. Я такого использования не встречал, это калька с class-oriented языков.
Mosh — сохраняет соединение (и, как следствие — сессию и контекст), screen — только сессию, и все равно вынуждает переподключаться (да, можно ставить бесконечные keepalive на каждом SSH-сервере, тюнить и все такое — но в какой-то момент вам надоесть каждый раз под себя тюнить все сервера, особенно если они не ваши и тюнить там нельзя ничего).
Mosh — решает еще несколько проблем юзабилити remote shell, screen — нет.
По какой причине я, как пользователь remote shell, должен захотеть поменять удобный all-in-one mosh-solution, на стек решений и хаков screen/tmux/vpn/ssh-tuning/etc? При прочих равных всегда выигрывает решение, требующее меньшего количества телодвижений, не так ли?
Find в данном случае вам нужно или Contains (содержит или нет) или Index (позиция, с которой содержит).
В каком месте и для чего sort использует reflection? Желательно прямо строчку кода укажите :)
нет, encoding/binary используется исключительно для чтения/записи в с storage (io.ReadWriter) — это задача сериализации/десереализации данных. Сам же b-tree алгоритм построен исключительно на использовании интерфейсов.
Поймите, generics — это написание алгоритмов в type-независимой манере. Go дает возможность это делать с помощью интерфейсов — ваш тип должен реализовать методы, необходимые для работы алгоритма — и наслаждайтесь. В С++ эту проблему решили иначе — темплейтами, в Java — еще иначе — и везде за счет потерь в скорости, читаемости и/или эффективности. И люди, привыкшие к тем или иным решениям, просто чувствуют себя без них неудобно в новом языке — отсюда и эти «Пайк, спаси, введи темплейты». Но это неправильно.
Или вот еще — когда для каких-то особых случаев людям советуют использовать reflect или interface{} с кастингом — они начинают рассказывать про «это медленно» и вообще, мы хоть это за zero costs получить. Блин, конечно медленно — а в в других языках, generics, думаете бесплатно получается?
В конце-концов да, тем кто прямо без темплейтов жить не может — (уже почти) есть go generate и были какие-то ужасные (как по мне) решения вроде gonerics.
Вобщем я все еще в поиске реальных use-кейсов, где Go без имплементации C++/Java-style generics не справляется красиво.
Кстати, я им немного попользовался и вернулся обратно на go fmt (при сохранении всмісле) — во-первых, как-то уже привык добавлять импорты сам перед тем, как использовать какие-то вещи из них — не добавив, банально автодополнение не сработает, а удалять через :GoDrop легче простого, не сходя с нужной строки. А во-вторых, там есть баг, до которого у меня руки не дошли разобраться — но imports в некоторых случаях, неверно угадывает путь и вставляет неправльные import-ы.
Это хорошо ))) Разнесли в пух и прах mosh.)
Плюсану вам в карму за это)
Посмотрите, как реализован stdlib-овский sort, или приведенный выше B-Tree.
Это просто другой подход к проблеме. Можно спорить о том, какие минусы и какие плюсы этого подхода, и даже спорить — а считать ли этот подходит тоже как вид generics, но уж точно на «Go тут фейлится» не подходит.
В Go в итоге 99.9% кода гарантированно читабельно и аккуратно.