Ну чего там с языками программирования и технологиями?

Ну и пиши себе на баше.

 

так сколько строк полчуилось бы у тебя? ну хотя бы прикидочно?

а ведь ту функцию edit_xml_file_by_xpath вполне можно написать, и это сильно много труда у разрабов стдлиба к тому "новому языку" не отняло бы.

 

Нисколько. Я такой херней не занимаюсь.
Но если бы понадобилось - будет 1 строка аналогичная твоей, после написания аналогичной функции. + овердохуя строк различных библиотек для того что бы сам экзешник собрался.

Напиши, выложи в опенсурс. Если будет больше 100 юзеров - расскажешь.

Твои подъебки сейчас на уровне: я могу вантузом прочистить сортир с 1-го "качка". А за сколько у тебя это выйдет с помощью 6-координатного станка с ЧПУ?

Не надо без объективной необходимости на станке делать вещи которые и так можно решить с помощью вантуза. Это не эффективно.

Да, можно написать ПО к станку, и он будет круче вантуза, но нахуя, если уже есть вантуз?

 

ну, судя по примерам, в _стандартной_ либе гошечки предлагается расфуфыриться на ~20-30 строках - открывать файл (как положено), создавать объект xml, получить структуру, принять xml, получить первый узел, потом делать обход узлов, сравнивать текущий "тот ли это?", ну и если тот- отредактировать структурку (узел). потом закрыть старый файл, чтобы открыть его для записи, ну и вписать туда изменённую структуру.

есть, конечно, стороння либа!
которая делает более-менее кратко (и то не совсем).
но... в том-то и вопрос - почему этот "ктото" смог ЗАБЕСПЛАТНО выложить целую либу, а разрабы стдлиба гошечки, которым это было сделать на "раз плюнуть" - не делают?

одну функцию? да кому она (одна!) нужна?
нужна либа, в которой есть много чего полезного.
я не настолько ещё опытен в го/русте, чтобы фигачить либы с приемлемым быстродействием и качеством.

 

Посмотри на исходники grep и awk и ты примерно поймешь, сколько строк кода надо будет написать.

 

мои? подъёбки?
(нормально вроде вёл дискуссию)

 

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

вот тут наверное довольно быстро должно быть. не проверял.
https://github.com/ericlagergren/go-coreutils/blob/master/cat/cat.go
исходный код на С:
https://github.com/coreutils/coreutils/blob/master/src/cat.c

 

Именно так это для меня и выглядит.

Я могу с помощью winrar упаковать каталог в архивы с разбитием на тома нужного размера с помощью 1-й строки в консоли.

Так сколько строк получилось бы у тебя на Go? Ну хотя бы прикидочно? (c)

А еще я могу с помощью одной команды поиграть в контру. А вот если контру начать писать на go то строк наверно будет больше...

Ну ты понял.

 

у меня так :
split -b $SIZE <(tar c DIR1 DIR2)

или даже вот так:
split -b $SIZE <( find DIR1 DIR2 -type f -a_lot_of_options_to_filter | xargs -r tar c )

И на го я бы хотел такой воркфлоу: получить списочек файликов в массив или и вовсе куда-нить в буффер, чтобы потом io.Reader'ом каким-нить его посчитать и отправить в другую функцию, которая уже б tar сделала в виде Stream, который в свою очередь отдал бы функции, которая принимает поток и херачит файлики со страшной силой, как это делает split.

 

Для контры тоже процесс распиши.

 

Удачи вам в редактировании гигабайтных xml Коллега с поточной загрузкой в БД (только загрузкой) xml-ек ФИАС развлекается. Много мата

 

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

 

Вырубили свет?

 

К сожалению нет Да и не 404 - промгенератор есть. Вопрос в количестве "чего"

 

Ну это только как текст ручками парсить. Громко матерясь.

Хотя страдальцы небось уже и парсер написали, который даже эту красоту может отпарсить.

 

Все?

 

Ага, пришлось. Причём чуваку каждый раз надо новый писать %) Там несколько взаимосвязанных справочников надо грузить, причём данные каждый раз целостностью не грешат

 

Дадада!!! Третью неделю хуярим без выходных...

 

Этот момент тоже обговаривался с местными погромистами. И я специально указывал в дискуссии, что обработка больших xml, или быстрая обработка xml (обрабатывать их большое количесто) - это чуть-чуть другая задача, нежели "лениво открыть маленький одинокий xml-чик".
Они (воти здесь тоже) постоянно скатывались в дискуссии на тему "тогда напиши сам". Но если "напиши сам", то тогда и вообще ВСЮ стдлиб тоже можно было бы "написать самому"!
Хороших профессионалов-умельцев ведь менее четверти от общего количества погромистов (а то и меньше десятины). Остальные - середнячки или нубы. Вот для них-то и важны эти включения в стдлиб, чтобы они не задумывались над тем как записать в xml без лишнего геморра (да-да, на первом этапе им эта часть - лишняя), а ваяли бизнес-логику своего кода. Мы ведь уже не пользуемся абстрагированием при обращении к БД, а раньше тоже приходилось "задумываться", в итоге - много сил уходило на обработку коннекций к базе, чем собственно на написание основной части своей проги.
Вот то же и с xml/json/yaml мне хотелось бы видеть.
И с копированием файлов, и с поиском файлов.

Сделать аналог grep - несложно, даже мне.
Есть ведь regexp.FindString, и прописать функцию, которая открывает файл, деферит тут же закрытие, читает построчно, вызывает эту FindString и возвращает найденное - ну, 10-15 строк отсилы.
Что, места много бы заняло в стдлибе это? Или много сил/времени бы отняло у профессионалов-разрабов-языка?
Нафига мне (и ещё нескольким сотням "бывших сисадминов") изобретать свои собственные велосипеды и писать непременно свой код?

 

Такова идея прогресса использовать унифицированные компоненты вместо сделанных по индивидуальному заказу.
Тоже я думаю было в машиностроении. Когда вместо того чтобы вытачивать болты и гайки на своем заводе, под нужный размер приводили все к стандартным хоть и менее подходящим. Зато имели меньше затрат на болты и гайки, и упрощение ремонта и обслуживания. Тоже и в программировании использовать по максимуму уже готовые отлаженные унифицированные решения, вместо самописных.
Да порой самописные дают выигрыш какой то в конкретном случае. Но нужно взвешивать стоит ли оно того? Ведь самописные нужно написать, отладить, но самое главное поддерживать потом. А это бывает чаще всего куда важней как показывает мой опыт чем какой то прирост производительности.
Ну и программист сейчас становится массовой профессией, а значит средний уровень неизбежно снижается. Так что это тоже имеет значение.