Навiщо? O_O
ps. Я розумiю ще в основну базу, але в редис?
Нічого.
БудуТо який сенс у цьому?
Я взагалі не розумію, який сенс порівнювати Go і PHP — абсолютно різні задачі виконують, зі своїми плюсами і мінусами.Який сенс порiвнювати уазик i тойоту, вони ж для рiзних задач. Одни для їзди по бездоріжжi, а iншi по мiсту. Тому потрiбно завжди їздити на уазiку. Плювати на безпеку чи комфорт. Плювати на те що усi використовують їх для їзди по мiсту)
якщо знайшов щось на ґітхабі з десятком зірочок — вже щастя
Та невже:
goo.gl/Q5V8Iy
goo.gl/YqHc5P
Щось рiзниця не дуже вражає, може порахувати проекти з >1000 зiрочок?
goo.gl/1lbbUB
goo.gl/R7BuEi
Круто, нiчого, що ваш фiльтр блума помре пiсля завершення роботи скрипта? Будете робити searilize i писати в базу? Пiдключайте, використовуйте. Я знаю, що в php МОЖНА. Багато що можна. Але для цього потрiбно робити нетривiальнi речi. Вiзьмiмо такий код в node.js або go:
var i = 0 // visitor counter
function requestHandler() {i++}
Покажiть тривiальний спосiб зробити це на php.
В мене капають сльозки.
Ви правi, наступного разу, коли менi потрiбно буде працювати з xml обов’язково згадаю про php.
То ви звичайне трололо, а я даремно марную свiй час. Бувайте здоровi!
Якась дивна у нас з вами розмова. Хiба я порiвнював Go з C (пишу i на тому i на тому)? Чи може запитував на чому написана github.com/...
Знаю, працював на php десь
З libxml2 посміявсь. Це ж бібліотека на С.Смiйтеся далi, адже go може використовувати
Бла-бла-бла без аргументации. А чем подкреплены ваши слова? Может это у вас ложь, простите.
Ну чесно кажучи, в мене iнша специфiка, тому з цими iнструментами я не знайомий i навряд чи зможу оцiнити „нормальнiсть” нагуглених пакетiв.
github.com/lestrrat/go-libxml2
godoc.org/launchpad.net/xmlpath
godoc.org/...
godoc.org/...
godoc.org/gopkg.in/xmlpath.v2
golanglibs.com/top?q=xsd
Ну, я не знаю ваших потреб в роботі з XML. Мене повністю задовольняє вбудована encoding/xml
Писати можна на будь-якiй мовi, i причини в кожного свої. Мiй комент про php — якщо порiвнювати з ним — то переваги Go — строга типізація, синтаксис, якiй попереджує виникнення рiзноманiтних прихованих помилок — бiльшiсть з них будуть виявленi на этапi компiляцiї, бiльша продуктивність завдяки компiляцiї, в програмi на go значно простiше органiзувати яке-небудь кешування, фільтр Блума, hyperLogLog і багато інших речей, які допомагають взагалі не робити запити в базу при кожному зверненні. Для цього йому не потрiбнi редиси, memcached i т.п
Напишіть кілька сервісів на Go або ScalaI забудьте про iснування PHP) Не бачу причин, знаючи хоч той же Go, продовжувати писати на PHP, ну крiм хiба що якоїсь закоханностi в цю мову.
Пожалуй не буду давать развернутый ответ. Кое-что я уловил, в чем-то остался при своем мнении. Но времени на широкую дискуссию на данный момент практически нет) В любом случае каждый инструмент должен использоваться в свой момент и в своей ситуации. Если грести все под одну гребенку, то и получаться будет одинаково посредственно.
upd.
И ещё интересно, как Вы попытались вывернуть против меня мои примерыК сожалению не читал, не было времени листать весь тред) Я отвечал лишь на комментарий про чёрный список теми примерами, которые пришли на ум)
Мой первый комментарий основан на том, что показывает практика — я возьму произвольную ф-ю любого из моих подчиненных, и с вероятностью в 50% смогу ее повалить «неожиданными» аргументами, при том, что их тесты отрабатывают без ошибок. Все их тесты пишутся для отчета, а не для реальных проверок.
А проверять собственный результат разработчик не то, что должен, он обязан. Но и проверить работу модуля можно без написания файлов-скриптов юнит-тестов и периодической проверки по крону.
Если я пишу функцию для деления двух чисел, то сначала продумаю ее интерфейс и возможные ошибки, дальше после написания кода, я вызываю ее вручную для проверки обработки всех вероятных критических моментов и валидности результата (например деление на ноль). JS позволяет провести все тесты прямо в консоли. Функция возвращает ожидаемые результаты — ок, документирую. Если же валится или результат не верен — занимаюсь поиском ошибки. Считайте это юнит-тестами в ручном режиме. Также проверяю выполнение пошагово в дебаг-режиме и замечаю вероятную ошибку, даже если модуль будет проходить тест. После этого, в моем случае приложение в обязательном порядке проходит тестирование более высокого уровня. Если же ф-я имеет достаточно сложный интерфейс, что делает практически не реальным проведение синтетических тестов (тесты будут сложнее самого модуля), то только это и спасает.
При этом уверен, что где-то написание файлов юнит-тестов полезно и даже необходимо.
Оу, у вас есть черный список тех, кто считает, что разработкой и тестированием должны заниматься разные люди?
Такого еще не происходило за последние пять лет. Хорошо, есть ф-я, на входе объект данных юзера, на выходе — появляется запись в БД, происходит обращение по API и т.п. Какие тесты будете писать?
Що, похапе погано працює з сучасними форматами даних?