Медленные относительно го в принципе, или относительно других языков?

Медленно относительно других языков. В Go нативная имплементация.

Медленные относительно го в принципе, или относительно других языков?

по совокупности обычно выходит быстрее, чем в перле-пхп-питоне

недавно обнаружил, что в vscode c плагином микрософта - внезапно! - можно жить, и весьма комфортно

но сами регулярки - да, помедленнее

зато не зависят от объема входных данных

но сами регулярки - да, помедленнее

А в js?

в js же те же pcre

https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/regexredux.html вот в кратце, если про синтетику

недавно обнаружил, что в vscode c плагином микрософта - внезапно! - можно жить, и весьма комфортно

Лучше LITEIDE?

помоему, все лучше liteide

Сегодня днем мне посоветовали storm заместо sqlite, вообщем результат такой на 5200 идентичных данных размер базы в 8 раз больше у storm однако скорость чтения на треть выше

Это я так мало ли кому интересно

Идентичных записей*

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

Diasko: Народ подскажите на счёт либо для клиента WSDL/SOAP, на гидхабе нашел надо тестить, может кто работает с ними

есть ли кодогенератор для монги?

Сегодня днем мне посоветовали storm заместо sqlite, вообщем результат такой на 5200 идентичных данных размер базы в 8 раз больше у storm однако скорость чтения на треть выше

это еще с учетом, что storm весьма криво написан

Diasko: Народ подскажите на счёт либо для клиента WSDL/SOAP, на гидхабе нашел надо тестить, может кто работает с ними

ничего не понятно. если нужна тулза, чтобы дернуть SOAP-сервис - скачайте SOAP UI. если нужен кодогенератор , чтобы сделать клиента по готовой всдл - ну погуглите. вот, сходу https://github.com/hooklift/gowsdl

https://blog.golang.org/package-names Все другие статьи, которые затрагивают правила хорошего тона именования пактов, в целом тоже сводятся к тому, что нужно выбирать короткие лаконичные имена, не использовать under_score или camelCase. Да, вроде бы и всё верно, но до сих пор никак не могу смириться с этим положением дел. Мне одному так сложно порой придумывать имена, которые должны в одно слово действительно передавать всю суть пакета? В вопосах по этой теме на stackoverflow, все отвечающие гордо объясняют, что, мол, если у вас не выходит назвать лаконично одним словом пакет, то у вас плохая архитектура и вообще... Вот только ощущение, что никто из них не пробовал поддерживать проекты, где количество пакетов исчисляется не десятками.

Вот, скажем, в книжке Донована и Кернигана The Go Programming Langugage, в одном из примеров, пакет именуют "tempconv". Говорится, что temperature - слишком длинное имя, не дающее понимание, что делает пакет. //Ок, пожалуй, так и есть Также объясняется, что "temp" всё-таки очень плохой вариант: слишком короткое и неочевидное имя. //Да неужели??? Имена из рода ~temperatureConverter даже не рассматриваются (оно и понятно, camelCase "нельзя", а без него, полностью нижним регистром, конечно же, будет нечитабельно). В итоге останавливаются на tempconv. Мол, и ясно что делает пакет, и короткое имя. Да, в рамках примера всё круто, и сперва кажется, что tempconv - отличное имя для пакета. Вот только вся эта лаконичность с лихвой аукается в проектах (или группе проектов), где количество пакетов близится к сотне. И тогда хочется иметь старые, добрые, "тупые java-имена" и "плохую архитектуру".

Довольно часто появляются мысли о том, как удобно было бы вот сейчас взять и таким-то camelCase-именем озаглавить пакет, их не отогнать просто. Понимаю, что underscore используется длля сборки под определенную архитектуру, ОС. Хорошо, нет проблем. Но дико, неистово интересно, что именно подтолкнуло к запрещению camelCase-имен? Технически, как понимаю, никаких преград ведь не было?

стремление к единообразию наверно

единоужасию

Вот, скажем, в книжке Донована и Кернигана The Go Programming Langugage, в одном из примеров, пакет именуют "tempconv". Говорится, что temperature - слишком длинное имя, не дающее понимание, что делает пакет. //Ок, пожалуй, так и есть Также объясняется, что "temp" всё-таки очень плохой вариант: слишком короткое и неочевидное имя. //Да неужели??? Имена из рода ~temperatureConverter даже не рассматриваются (оно и понятно, camelCase "нельзя", а без него, полностью нижним регистром, конечно же, будет нечитабельно). В итоге останавливаются на tempconv. Мол, и ясно что делает пакет, и короткое имя. Да, в рамках примера всё круто, и сперва кажется, что tempconv - отличное имя для пакета. Вот только вся эта лаконичность с лихвой аукается в проектах (или группе проектов), где количество пакетов близится к сотне. И тогда хочется иметь старые, добрые, "тупые java-имена" и "плохую архитектуру".

а можно увидеть примеры пакетов где ты не можешь выбрать название ?

Вот, скажем, в книжке Донована и Кернигана The Go Programming Langugage, в одном из примеров, пакет именуют "tempconv". Говорится, что temperature - слишком длинное имя, не дающее понимание, что делает пакет. //Ок, пожалуй, так и есть Также объясняется, что "temp" всё-таки очень плохой вариант: слишком короткое и неочевидное имя. //Да неужели??? Имена из рода ~temperatureConverter даже не рассматриваются (оно и понятно, camelCase "нельзя", а без него, полностью нижним регистром, конечно же, будет нечитабельно). В итоге останавливаются на tempconv. Мол, и ясно что делает пакет, и короткое имя. Да, в рамках примера всё круто, и сперва кажется, что tempconv - отличное имя для пакета. Вот только вся эта лаконичность с лихвой аукается в проектах (или группе проектов), где количество пакетов близится к сотне. И тогда хочется иметь старые, добрые, "тупые java-имена" и "плохую архитектуру".

AbstractUserInfromationInterfaceFactoryFactory?

Да так-то называю "правильно", но всё-таки порой кажется, что куда лучше называть где-то camelCase, так как без сокращений всё-таки меньше вероятность как-то не так понять что делает пакет, меньше искать нужный пакет нужно.

AbstractUserInfromationInterfaceFactoryFactory?

пакет из одного интерфейса?

Да так-то называю "правильно", но всё-таки порой кажется, что куда лучше называть где-то camelCase, так как без сокращений всё-таки меньше вероятность как-то не так понять что делает пакет, меньше искать нужный пакет нужно.

так каждый раз ты решаешь

пакет из одного интерфейса?

Фабрики фабрик интерфейсов!

uinfofty

следующий

Да тот же tempconv из книжки. Никогда нельзя случано не так понять, что делает пакет "temperatureConverter", а tempconv - можно воспринять иначе, сложнее найти в списке пакетов нужный глазами. Особенно это всё проявляется с именами, где есть созвучие или скрытый другой смысл (вроде tmp, temp). Скажем, вот сейчас натыкался на сервис для генерации/редактирования определенного вида моков для API. Пакет с именем "mock" можно воспринять не совсем так, как нужно. //Думаю, всем понятно. В итоге mockgen или mocked вроде как "правильные" имена. Но мне вот не жалко было бы дописать 4 символа, чтобы получить предельно понятное всем, сразу, в любом контексте "mockEditor".

а почему бы не snake_case?

а почему бы не snake_case?

Читайте первые сообщения. > https://blog.golang.org/package-names Ни camelCase, ни snake_case не рекомендуются. Но snake_case хотя бы понятно почему (используются суффиксы определенные в именах, вроде _linux, _arm64 и так далее, для сборки под соответствующую платформу), а вот с camelCase что мешает - неясно.

Да тот же tempconv из книжки. Никогда нельзя случано не так понять, что делает пакет "temperatureConverter", а tempconv - можно воспринять иначе, сложнее найти в списке пакетов нужный глазами. Особенно это всё проявляется с именами, где есть созвучие или скрытый другой смысл (вроде tmp, temp). Скажем, вот сейчас натыкался на сервис для генерации/редактирования определенного вида моков для API. Пакет с именем "mock" можно воспринять не совсем так, как нужно. //Думаю, всем понятно. В итоге mockgen или mocked вроде как "правильные" имена. Но мне вот не жалко было бы дописать 4 символа, чтобы получить предельно понятное всем, сразу, в любом контексте "mockEditor".

ну tempconv мне тоже кажется неудачным

> Ни camelCase, ни snake_case не рекомендуются да это-то понятно, я просто предлагаю > суффиксы определенные в именах, вроде _linux, _arm64 (да, я знаю, что это так, но..) звучит сомнительно, как будто не смогли другого способа резолвить платформы

> а вот с camelCase что мешает - неясно. очевидно же! — слишком похоже на с++

Ну, по-моему тут без разницы, camelCase или snake_case. Лишь бы можно было хотя бы два слова полных поставить рядом. А ни то ни другое - нельзя. И куда податься? :(

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

If you cannot avoid a bad name, it is very likely that there is a problem with your overall structure and code organization.

If you cannot avoid a bad name, it is very likely that there is a problem with your overall structure and code organization.

temporary_convolution

temporary_convolution

и что же делает этот пакет?

я знал, что ты спросишь!

Временно сворачивает?

а package types не напрягает, не? :)

но допустим пакет будет называться temporal_convolution и будет вычислять эту темпоральную конволюцию

Временно сворачивает?

да

но допустим пакет будет называться temporal_convolution и будет вычислять эту темпоральную конволюцию

temporalutil

ммм, как классно читается

temporalutil

"времЕнные утилиты"

но допустим пакет будет называться temporal_convolution и будет вычислять эту темпоральную конволюцию

я к тому, что tempconv осмысленности не прибавит

придумывая абстрактные имена вы получаете абстрактные короткие имена

давайте рассматривать реальные примеры

давайте рассматривать реальные примеры

Ну, mockEditor тот же, выше писал. "Правильное" имя тут явно проигрывает в информативности.

Ну, mockEditor тот же, выше писал. "Правильное" имя тут явно проигрывает в информативности.

а что за mockeditor ? мне вот непонятно - это действительно редактор ? а что он делает в пакетах ?

//Ну, если быть точным, mockgen - пакет, mocked - редактор, приложуха отдельная.

ну он имеет отношение к мокам или это рандомное название ?

Всё имеет. Ну, там mockgen/mocked нормальные названия, просто к тому, что два слова читаются и воспринимаются легче одного с сокращениями. Особенно когда кто-то со стороны заглядывает.

Кстати, по поводу именования директорий: её имя же всегда совпадает в итоге с именем пакета. Делать другие - сопоставления нужно тогда держать в голове. Делать те же - неудобно просматривать структуры проектов, больно уж лаконично могут называться некоторые.

окей я понял. но описание того что делает пакет полностью в имени - это не есть гуд. для этого есть документация

Насколько хорошо массовое разъезжание между именами пакетов и именами директорий иметь? :)

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

думаю это очеь плохо

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

людям придется держать в памяти и названия директорий и названия пакетов

ERROR: S client not available

Всё так. Но вот куда податься-то теперь? БТВ, довольно часто встречаются большие проекты, которые забивают на всё и используют несколько слов в именах директорий. После этого как-то и самому не стыдно станвоится. ;)

окей я понял. но описание того что делает пакет полностью в имени - это не есть гуд. для этого есть документация

Верно! поэтому нужно назвать не mocked, а mockvim! (чтобы не путать с linux's `ed`)

ed не настолько популярен чтобы путать с ним

и что то мне подсказывает что слово editor в пакете не есть правильно. это больше название для готового приложения а не для пакета

Всё так, я же писал выше, ed - собирается в приложуху, а переиспользуемый пакет, он с gen.

Но если использовать именование директорий в стиле пакетов, там та же проблема. Если нет - проблемы нет, но уже и соблазн на какие-то пакеты "неправильные" имена директорий распространить. Так и происходит в итоге. :)

ну для готового приложения мне кажежтся можно использовать и MockEditor

ага, теперь я понял

да есть неясность в этом плане.

но вот смотри https://github.com/golang-standards/project-layout/tree/master/cmd здесь запросто используют подчеркивания

routes.PathPrefix("/dist").Handler(http.FileServer(http.Dir(CONF.WorkDir + "status/"))) ребзя

есть такой движ

как сделать что бы файл с status/dist/build.js был доступен по assets228/build.js

Но если использовать именование директорий в стиле пакетов, там та же проблема. Если нет - проблемы нет, но уже и соблазн на какие-то пакеты "неправильные" имена директорий распространить. Так и происходит в итоге. :)

https://github.com/influxdata/influxdb/tree/master/cmd

как видишь все юзают _ в названии директорий исполняемых файлов. так что mock_edtor это хорошее название

но вот смотри https://github.com/golang-standards/project-layout/tree/master/cmd здесь запросто используют подчеркивания

У influx ещё есть два варианта наименований директорий, в отличие от других из примеров. Если честно, не совсем понимаю, по какому принципу они выбирают подчеркивание использовать или дефис (influx-tools, influx_inspect).

У influx ещё есть два варианта наименований директорий, в отличие от других из примеров. Если честно, не совсем понимаю, по какому принципу они выбирают подчеркивание использовать или дефис (influx-tools, influx_inspect).

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

наверняка стоит избегать - в названии - потому что может быть принято за флаг

Не, за флаг не будет принято. :)

почему нет? при быстром взгляде трудно заметить есть там пробел перед дефисом или нет . сравни (influx-tools) и (influx -tools) при взгляде со стороны пользователя

пользователь не знает про флаги

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

пользователь не знает про флаги

и?

и?

он не будет воспринимать, есть там пробел, или нет ему пофигу

коллегия, 1) что думаете про фреймворки? https://blog.usejournal.com/top-6-web-frameworks-for-go-as-of-2017-23270e059c4b 2) юзаете ли какие-либо не-веб фреймворки?

он не будет воспринимать, есть там пробел, или нет ему пофигу

пользователь сам не будет писать никакие флаги

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

это не пакеты, не путай. это имена приложений.

пакет там main

пользователь сам не будет писать никакие флаги

да ладно ? а если я пишу флаги я уже не пользователь ?

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

да ладно ? а если я пишу флаги я уже не пользователь ?

у пользователей, которые сами пишут флаги, уже набит глаз на пробелы

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

нет, они не лежат в этой же иерархии