Контейнер
* плохой контейнер
Anonymous
S
curl язык?
Pawel
ни разу нет
Pawel
Rust создан чтобы дрочить на указатели, а не для написания программного обеспечения
S
чую у всех тут жестко наболело)))
Vladislav
Rust создан чтобы дрочить на указатели, а не для написания программного обеспечения
Вот не надо. Rust очень грамотно сделанный язык. Другое дело что порог входа дофига огромный, а профиты пока неясны.
Anonymous
Тушим полыхание от Go при помощи смузи 😄
Alexey 〒.
Alexey 〒.
Вот не надо. Rust очень грамотно сделанный язык. Другое дело что порог входа дофига огромный, а профиты пока неясны.
А не ясны профиты, потому что мало где пока применяется, в основном всякие хипстерские стартапа
Vladislav
А не ясны профиты, потому что мало где пока применяется, в основном всякие хипстерские стартапа
Ну вот нет. Эти как раз на Go.
Daniel
на rust должен был быть написан браузер. и, если бы это и правда произошло - я бы, как минимум, изучил его синтаксис. потому как альтернатива с++ нужна весьма
Daniel
но - пока нет того браузера
Alexey 〒.
на rust должен был быть написан браузер. и, если бы это и правда произошло - я бы, как минимум, изучил его синтаксис. потому как альтернатива с++ нужна весьма
Движек, и наработки уже в firefox переносили
Daniel
между "сделан проект" и "переносят наработки" разница такова, что я про rust пока даже не думаю
Vladislav
И тот в новом, который в бете.
Alexey 〒.
Каких-то несколько легковесных писали
Vladislav
на rust должен был быть написан браузер. и, если бы это и правда произошло - я бы, как минимум, изучил его синтаксис. потому как альтернатива с++ нужна весьма
Там синтаксис несложный. Больше времени уходит на то, чтобы понять как работать с временами жизни.
Givi
Rust, пописав на нём совсем чуток, write only хрень, но это сугубо имхо, никого не хочу обидеть.
Pawel
Вот не надо. Rust очень грамотно сделанный язык. Другое дело что порог входа дофига огромный, а профиты пока неясны.
эдак можно оправдать любую бессмысленную и бесполезную херню - она типа для избранных джедаев, обычные программисты слишком тупы чтобы её асилить и по этому на ней ничего не пишут блаблабла
Artem
народ подскажите, что означает сея конструкция: err.(websocket.HandshakeError) контекст: if _, ok := err.(websocket.HandshakeError); ok {
Oleg
Arch https://tour.golang.org/methods/15
Илья
Vladislav
эдак можно оправдать любую бессмысленную и бесполезную херню - она типа для избранных джедаев, обычные программисты слишком тупы чтобы её асилить и по этому на ней ничего не пишут блаблабла
Ну нет. Там крайне логичная библиотека. Отличные идеи управления памятью. Просто обращаться с тим непросто. Поэтому на нем мало кто пишет.
Artem
спс
Pawel
Ну нет. Там крайне логичная библиотека. Отличные идеи управления памятью. Просто обращаться с тим непросто. Поэтому на нем мало кто пишет.
хороший текст про то, почему раст мертворождённый те-еретический язык. Почти всё что там написано - актуально. http://eax.me/cpp-will-never-die/
Quet
наверное тогда стоит прочитать комментарии к "хорошему тексту"
https://news.ycombinator.com/item?id=9531822
Александр
Зачем вообще спорить о языках программирования? Почему-то большинство забывает о том, что ЯП лишь инструмент и каждый из них хорош для определённых задач и плох для других. И все эти разговоры вокруг "убийц" языков бессмысленны, всё равно что заявлять о том что камеры телефонов заменят профессиональные камеры, ну бред же
Илья
это как о вкусах спорить
Илья
только о них и спорят, обычно
ceiling cat
Почему дискуссии в этом чатике всегда сводятся к тому, что джаваскрипт дерьмо ?
Александр
Как по мне, лучше спорить о более базовых вещах: об архитектуре ПО, методологии разработки и тому подобному, так хотя бы различные приёмы программирования будут использоваться под разные задачи, а не как сейчас, когда ООП для всего подряд используют
Andrey
Как по мне, лучше спорить о более базовых вещах: об архитектуре ПО, методологии разработки и тому подобному, так хотя бы различные приёмы программирования будут использоваться под разные задачи, а не как сейчас, когда ООП для всего подряд используют
Для этого нужно знать больше чем синтаксис 2ух языков :-)
Александр
Понимание особенностей рабочей машины и специфики решаемой задачи важнее синтаксиса языка
Anonymous
Понимание особенностей рабочей машины и специфики решаемой задачи важнее синтаксиса языка
Нет времени понимать особенности рабочей машины. Мы просто пишем код, от нас всё скрыто инкапсуляцией.
Anonymous
Со спецификой пусть работают спецы по ассемблеру.
S
Понимание особенностей рабочей машины и специфики решаемой задачи важнее синтаксиса языка
Согласен, лучше спорить о том как хорошо делать или нет, а не то что на языке писать плохо.
S
У него есть gil, прям рассизмом попахивает))
Александр
Реальный случай: нужно получить пиксель изображения и перерасчитать его цвет в зависимости от результата формулы. Вариант сделанный по типу расчитываем формулу берем пиксель, расчитываем пиклель и дальше работал около 4-5 секунд на изображение. Узким местом была RAM, к которй постоянно производилось обращение. После изменения структуры хранения данных с учётом размера кэша проца удалось сократить время до 1-2 сек
S
Возросшую мощь компьютеров- мы компенсировали фреймворками, а свой непрофессионализм - очередной группой тестировщиков:)
Александр
"Программы становятся медленее быстрее, чем компьютеры быстрее"
Эта цитата на первый взгляд звучит как билеберда, но она отражает всю правду
Dmitry
Реальный случай: нужно получить пиксель изображения и перерасчитать его цвет в зависимости от результата формулы. Вариант сделанный по типу расчитываем формулу берем пиксель, расчитываем пиклель и дальше работал около 4-5 секунд на изображение. Узким местом была RAM, к которй постоянно производилось обращение. После изменения структуры хранения данных с учётом размера кэша проца удалось сократить время до 1-2 сек
> После изменения структуры хранения данных с учётом размера кэша проца
Как вы так сделали? Можно чуть чуть подробностей?
Александр
Дано: изображение []uin8 и коэфициент uint8. Время отдачи и получения из RAM переменной и массива (размер, кт не превышает ширину системной шины) не особо отличаются. Поэтому предварительно разбиваем массив изображения на массив из небольших массивовпри этом битовый размер небольшого массива + битовый размер множителя < размера кэша процессора). В зависимости от размера кэша проца может быть разный прирост
Dmitry
спасибо!
Александр
Что-то читаю только что мною написанное и вроде и понятно, а вроде и не все тонкости раскрыл
Dmitry
Что-то читаю только что мною написанное и вроде и понятно, а вроде и не все тонкости раскрыл
мне этого было достаточно, примерно так и предполагал
Alexey 〒.
хороший текст про то, почему раст мертворождённый те-еретический язык. Почти всё что там написано - актуально. http://eax.me/cpp-will-never-die/
Даже если он мертворожденный, он все равно очень вероятно будет источником идей для нового языка. Сколько языков умерло до Си?)
А значит не так он и бесполезен
Pawel
Даже если он мертворожденный, он все равно очень вероятно будет источником идей для нового языка. Сколько языков умерло до Си?)
А значит не так он и бесполезен
там основной фетиш "make things explicit", и система типов через это весьма паршивая. Не то что хипстерам, даже сишникам не продадут.
Alexey 〒.
Возросшую мощь компьютеров- мы компенсировали фреймворками, а свой непрофессионализм - очередной группой тестировщиков:)
потому что железо докупить дешевле чем оплачивать труд крутых спецов
S
потому что железо докупить дешевле чем оплачивать труд крутых спецов
а тут тянется много проблем других))) лень в развитии, все большая деградация образования и прочее))
Александр
Когда ООП начал набирать популярность, считали его крутым решением, типа памяти много, можно хоть всё как классы обозначать. А сейчас из-за разности производительности ЦП и RAM набирает популярность Data Driven Development
Grigoriy
Всем привет! Пытаюсь разобраться с указателями и ссылками. Подскажите, пожалуйста - первый пример https://play.golang.com/p/5hZQZzewQt должен работать быстрее второго примера https://play.golang.com/p/pmt0Dw02NX, т.к. не происходит ненужного копирования переменной. Правильно ли понимаю?
Artur
Насколько я понял ты с числом работаешь, попробуй тоже самое с огромным массивом, когда он не копируется а по ссылке будет прирост, тут же больше математика грузит чем само число
Александр
Особой разницы не будет. Указатели удобно использовать для изменения чего-либо без необходимости делать return
Из твоего примера:
func mySum(in *int) (out int) {
return *in + 2
}
Можно заменить на
func mySum(in *int) {
*in += 2
}
Grigoriy
Кажется, теперь окончательно понял, спасибо! @Artawower какой массив можно считать огромным? Я для себя чуть пишу, попутно изучаю и снова пишу. Пока самое крупное - 100 с небольшим float64, это явно не подходит под понятие огромного?
Александр
Через указатель удобно работать с типами — улучшается структура и читаемость
Вместо
human = human.GetOlder()
Будет просто это
human.GetOlder()
Artur
Это смотря какая разница во времени тебе нужна:)
Grigoriy
Через указатель удобно работать с типами — улучшается структура и читаемость
Вместо
human = human.GetOlder()
Будет просто это
human.GetOlder()
про читаемость в статьях не встречал, но выглядит действительно лучше, спасибо!
Grigoriy
Это смотря какая разница во времени тебе нужна:)
Я хочу понять причины выбора указателей. Изменение - понял, удобство чтения - понял, а выигрыш скорости вызывает некоторые сложности. Если сейчас -5-10% от времени выполнения роли не сыграет, то завтра может и сыграть. Остается только тестировать каждый случай или профилировать?
Илья
Artur
Пнредаешь копию массива тысячи чисел, каждое из которых копируется на новый адрес, (это долго) пнредаешь указатель на первый элемент массива и работаешь с оригиналом (это быстрее где-то в тысячу раз ;))
Artur
Ну или на тысячу тактов :), а с 1 числом это делать не имеет смысла, потому что по сути его адрес занимает столько же памяти сколько число
Grigoriy
Кажется, дошло)) Еще раз спасибо!
🄽🄸🄺🄸🅃🄰
Товарищи, всем привет.
Подскажите умную мысль.
Есть приложение, которое занимается математическими расчетами. Математика проводится на сущностях (структурах) описанных в коде, данные к которым подтягиваются из бд.
Имеется известное ограниченное n кол-во сущностей, каждая сущность - это конечный известный набор интов (или float64, не важно)
Есть задача, сделать так, чтобы при добавления поля в структуры этих сущностей, или при добавлении новых сущностей, не приходилось коммитить и полностью перезапускать сервис и его контейнер.
Такое с Go вообще делают? ну, тобишь напрашиваются дженерики которых тут нет. Фабрику тут для структур можно, но саму структуру придется описывать для фабрики, и так или иначе работать с сущьностью поинтерфейсу бесконечно нельзя, на каком-то уровне всеж нужна конкретика и тип...
Смотрел в сторону генерации кода с описанием структур из скриптового файлика, который с фронта будет генерироваться, и перекомпилировать, как утилиту работающую в бэкграунде, но эт кажется тяжеловатым..Вдруг кто подобное делал уже
Daniel
при чем тут дженерики вообще?
Daniel
я, кстати, не знаю, как проделать этот фокус с монолитом
Andrey
почему нужно именно структуру создавать, нельзя все в мапу засунуть?
Daniel
с микросервисаами понятно - просто редеплой микросервисов, рутер просто ждет, пока новые версии воспрянут
Ivan
Товарищи, всем привет.
Подскажите умную мысль.
Есть приложение, которое занимается математическими расчетами. Математика проводится на сущностях (структурах) описанных в коде, данные к которым подтягиваются из бд.
Имеется известное ограниченное n кол-во сущностей, каждая сущность - это конечный известный набор интов (или float64, не важно)
Есть задача, сделать так, чтобы при добавления поля в структуры этих сущностей, или при добавлении новых сущностей, не приходилось коммитить и полностью перезапускать сервис и его контейнер.
Такое с Go вообще делают? ну, тобишь напрашиваются дженерики которых тут нет. Фабрику тут для структур можно, но саму структуру придется описывать для фабрики, и так или иначе работать с сущьностью поинтерфейсу бесконечно нельзя, на каком-то уровне всеж нужна конкретика и тип...
Смотрел в сторону генерации кода с описанием структур из скриптового файлика, который с фронта будет генерироваться, и перекомпилировать, как утилиту работающую в бэкграунде, но эт кажется тяжеловатым..Вдруг кто подобное делал уже
Если поменялись сущности, то и код их обработки должен поменяться. Как это сделать с перекомпиляцией и рестартом — так же, как в вебе делают миграции БД и перевыкат. Как это сделать без перекомпиляции — хранить код снаружи, т.е. обработку сделать на скриптовом движке, т.е. встроить в приложение lua, js, python, etc. Поменялись сущности - приложение поняло, обновило скрипты, работает с новой версией сущностей и кода.
🄽🄸🄺🄸🅃🄰
при чем тут дженерики вообще?
Дженерики имеются ввиду, что в php могу сделать переменные с именами из строк, наподобие ${$arr[0]},которые генерятся . В го так нельзя
🄽🄸🄺🄸🅃🄰
И классы так можно..
🄽🄸🄺🄸🅃🄰
почему нужно именно структуру создавать, нельзя все в мапу засунуть?
Есть источники данных, которые выгружаются в какую то заложенную структуру, и в коде записаны формулы работы с этими структурами. Формулы обращаются по ключам структур. Если держать Инты в марте, как обращаться к ним без ошибок, и как хранить формулы
Илья
В php нет дженериков