например какое-нибудь древо там например которое построено на указателях. Само древо статичное, а узлы древа - нет

не с этим ли мы боремся?!

нет. автор дает возможность иметь иммутабельные данные, а не говорит кому как жить

иначе эту проблему не решить... если тебе нужно вот именно статичное древо на указателях, а Go тебе в ответ: "извини, я так не умею, придётся переосмысливать проблему"... это херово

нет. автор дает возможность иметь иммутабельные данные, а не говорит кому как жить

это кстати может противоречить концепции языка. (я тут не троллю)

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

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

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

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

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

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

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

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

I mean.... "who needs 4 billion IP addresses anyway?..."

Опять же позиция авторов языка проста. Дав что-то забрать это нельзя. Можно посмотреть во что превратился с++. Их задача это предотвратить.

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

Да я только за. И за консты и за тайпклассы. :)

а с моим предложением правило без исключений распространяется на все типы. иммут и мут типы это как Материя и Антиматерия.. они практически одинаковы, за исключением заряда Object это тип []Object это тоже тип const []Object же это исключение тогда, потому-что на самом деле это const [] const Object ибо не понятно кто иммено имутабелен, слайс? или тип в слайсе? я лично против таких исключений из правила, даже ради упрощённого синтаксиса, больше неясности вносит чем символов экономит

Я думаю авторы языка как раз не против. Посмотри на map.

Я думаю авторы языка как раз не против. Посмотри на map.

всмсл?)

всмсл?)

всмысле генерики можно, но не всем.

всмысле генерики можно, но не всем.

у это таки немного другая тема

Есть в c# такой keyword как readonly. Оставлю это здесь)

Есть в c# такой keyword как readonly. Оставлю это здесь)

в Go его не будет, никогда либо const, либо mut с иммутабельностью по умолчанию в Go2 через лет эдак 10

в Go его не будет, никогда либо const, либо mut с иммутабельностью по умолчанию в Go2 через лет эдак 10

ronly, ro.

Просто пища умам.

ronly, ro.

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

Парни, а что гугл за DI выпустил? Кто-нибудь использовал?

мы тут решили как то

что самописный на структуре - the best

🙂

Мы используем fx, но только не прикольно в runtime ловить null pointer. У di гугловского он упадет во время компиляции, если мне изменяет память..)

хм

там кодогенерация?

что-то читал про него

там кодогенерация?

угу

я к тому, что var и const в одной строке объявления переменной - это противоречие

Поэтому нужно ключевое слово immut ясчитаю

mutable shared state - это проблема concurrency, но по идее, решается с помощью мьютексов

Это проблема всего программирования. Мьютексы решают проблему синхронизации, но не решают проблему общего изменяемого состояния.

Это проблема всего программирования. Мьютексы решают проблему синхронизации, но не решают проблему общего изменяемого состояния.

в rust вроде эта проблема решена?

Это проблема всего программирования. Мьютексы решают проблему синхронизации, но не решают проблему общего изменяемого состояния.

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

Но на них никто не пишет

в rust вроде эта проблема решена?

Эту проблему не решить, она лежит на фундаментальном уровне, это проблема вытекает из свойств, которые требуются от ПО. Иммутабельность и прочие решения пытаются лишь её изолировать и упростить поиск ошибок в коде с общим изменяемым состоянием.

Эту проблему не решить, она лежит на фундаментальном уровне, это проблема вытекает из свойств, которые требуются от ПО. Иммутабельность и прочие решения пытаются лишь её изолировать и упростить поиск ошибок в коде с общим изменяемым состоянием.

а про какую фундаментальную проблему вы имеете в виду?

Но на них никто не пишет

Во первых - исторически сложилось, во вторых - пишут.

Мало пишут

Мало пишут

Сейчас каждый первый новый язык что-то тянет из хаскеля или окамла.

Скала, пишут и пишут все активнее. Иммутабельность в языке, большие проекты, serverless энвайроменты.

Сейчас каждый первый новый язык что-то тянет из хаскеля или окамла.

новых языков все больше, а все равно вакансий больше на джаве

новых языков все больше, а все равно вакансий больше на джаве

а что плохого в яве ? ну и можно быть крутым спецом и найти вакансию хоть на common lisp

а что плохого в яве ? ну и можно быть крутым спецом и найти вакансию хоть на common lisp

Сама ява)

Сама ява)

язык != плафторма. jvm отличная платформа. а язык не очень тупо потому что ему больше 20 лет и есть священная корова в виде обратной совместимости

Спорить можно долго, но чотбы продукт получился хорошим на яве - уровень разраба должен быть бог. Иначе то память, то поставьте в крон на рестарт каждые 2 дня...

Спорить можно долго, но чотбы продукт получился хорошим на яве - уровень разраба должен быть бог. Иначе то память, то поставьте в крон на рестарт каждые 2 дня...

вы не понимаете что все более-менее серьезные продукты разрабатываются командой? и что в команде не могут быть все разрабы "уровня бога". Именно это и дает появления JVM языков типа Scala, где командная разработка "защищена" от side-эффектов на уровне языка. Если хочешь делать mutable код, переменную и т.д., то этот кусок будет подвергнуть тщательному изучению, потому что на уровне рекомендаций разработки на Scala - var переменные "несколько хуже", чем val переменные, т.е. bad practiсe. Но если нужно и разраб "уровня бог", понимает последствия и может их устранить - то можно использовать var для внутренних нужд.

Как деплойт go на vps ?

Помог

Помог

Ите

Походу никто не знает да

Просто все отдыхают.

Как деплойт go на vps ?

вы про это? https://stackoverflow.com/questions/27518407/upload-and-deploy-golang-application-to-vps

https://blog.golang.org/docker

Как деплойт go на vps ?

Lol

Google: golang deploy on linux server

golang deploy in docker

Подскажите чем можно заменить exec.Cmd для поторных использование. P.S. https://www.programming-books.io/essential/go/178-os-exec-gotchas

https://about.sourcegraph.com/go/gophercon-2018-5-mistakes-c-c-devs-make-writing-go

Коллеги, нужен совет. Есть некий сервис, который ходит по сторонним апи и собирает данные. Он написан на го. Появилась админка, написана на пхп, и через нее добавляются уже новые задачи, что когда обновлять. Как правильнее объединить сие чудо? Сходу задумался о rabbitmq, но там довольно много разных моментов может быть - запускать каждый час, раз в сутки и пр. Никто похожего планировщика не делал? Все это хранится в бд

Я делал подобное, сервис и php смотрят в одну базу, при старте сервис считывает данные в свою структуру, если на php делаются какие-то действия, то через redis отправляется событие и id записи, сервис из базы обновляет свои данные

Пробую постгрее в сравнении с монгой. Это нормально что операция инсерт выполняется около 5мс в то время как в монге около 0.5мс? Можно ли как-то оптимизировать?

Пробую постгрее в сравнении с монгой. Это нормально что операция инсерт выполняется около 5мс в то время как в монге около 0.5мс? Можно ли как-то оптимизировать?

в монге это фича же. быстрый инсерт

в монге это фича же. быстрый инсерт

За счёт чего такая разница?

Пробую постгрее в сравнении с монгой. Это нормально что операция инсерт выполняется около 5мс в то время как в монге около 0.5мс? Можно ли как-то оптимизировать?

Зато попробуй замерить скорость выборки 😀

За счёт чего такая разница?

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

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

А если у нас нет foreign keys?

Убит

Вы совсем страх потеряли

не дочитал (

эххх такой срач загубили((((

Вы совсем страх потеряли

+

Ээ, я же ответить хотел (

Не надо

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

эххх такой срач загубили((((

Пиши на чем хочешь

ну да ладно, для меня главный плюс гоу это компилятор а не интерпретатор(вм) собственно вопрос был не к тому чтобы поднять срач, а к тому, чтобы продолжая тему поинтересоваться юзает ли кто то нектар(компилятор для жиэса) если пишет на node.js к примеру

потому что, сюрприз, js теперь тоже компилируется во что хочешь, даже в ассемблер