О, шедевр
— Влияет ли на управление сложностью то, что в программировании сейчас довольно много людей со слабой технической базой?
Конечно. Для таких людей даже специальный язык программирования придумали. Называется Go. Я не шучу. Действительно, целью создания языка Go была попытка вовлечения в написание кода студентов и стажеров Google, которые не могут освоить C++. Python им не подходил по производительности, нужно было что-то иное, и в Google придумали Go. Как оказалось, очень много людей готовы на нем писать, потому что он очень простой. Но какой ценой достигнута эта простота? Нам дают не нормальный язык программирования, а его очень урезанную версию — в нем нет практически никаких сложных концептов by design. Нет дженериков, нет такого понятия, как исключения и т.д. И поклонников такого подхода много.
Отсюда https://habr.com/company/oleg-bunin/blog/424393/
Такое впечатление будто „гуру C++“ не понимают, что одной их мизерной продуктивности не хватает для решения актуальных растущих потребностей к ПО, особенно рассматривая как сильно понижает продуктивность это вечное легаси которое C++ тянет за собой ещё со времён C)))
говорю как бывший плюсер, нынешний гофер и будущий Rust’афарианец))
Roman
Roman
но для systems programming Go, увы, не подходит, поэтому мне придётся некоторые будущие проблемы решать на Rust’е, поскольку в C++ возвращаться - себя не уважать)
Roman
вообще дизайн языка (Rust) весьма продвинутый, Option & Result одни чего стоят, гораздо безопаснее error интерфейса. Trait’ы очень мощный инструмент, правда то что я пишу на Go за 5 минут, на Rust’е занимает час, со временем продуктивность конечно повысится, но.. настолько же насколько и в Go? сложно поверить.
Co(n)stantine👨🔬
Subbotin
типа микроконтролеров
Co(n)stantine👨🔬
мне кажется он проще С++ и Rust, конечно не безопасно, но
Roman
ну в какой-нибудь узкой области вполне может остаться
https://github.com/xrei/prime-numbers-benchmark/tree/master/c
на нём фаново писать только игрушки ИМХО, потому-что мало абстракций и такое ощущение при написании что ты прям по железу скребёшь.
как только начинаешь на нём писать что-то серьёзно начинается лютый гемморой багов и километровые романы для решения тривиальных задач…
C это как завершённая трилогия. Трилогия может быть феерической, но если её продолжать - она навсегда испортит все свои предыдущие достижения.
Roman
C дал миру всё что мог, ему давно пора на пенсию.
Roman
мне кажется он проще С++ и Rust, конечно не безопасно, но
это вам так кажется. Простой синтаксис не делает язык проще, потому-что код очень опасный. Вы больше потратите времени на исправление страшных багов чем на написание новых фич своей софтины
Roman
вообще самый простой язык по синтаксису это бинарный код. Там только однёрка и нолик, но легко ли на нём писать multi-threaded cross platform приложение?
саша
мне кажется он проще С++ и Rust, конечно не безопасно, но
Таки да, а ассемблер проще C. Только вот это не значит, что программы писать проще на ассемблере, чем на C.
Co(n)stantine👨🔬
Таки да, а ассемблер проще C. Только вот это не значит, что программы писать проще на ассемблере, чем на C.
Да ничем он не проще, что вы придумываете😞
Roman
в Go вот есть проблема что если не проверить ошибку и продолжить работать с возвратными данными, то можно жутко выстрелить себе в ногу, спасает только errcheck но и то не всегда.
в Rust функция может вернуть Result<T, T>, где первый T это тип при удаче а второй  Т это тип возможной ошибки и Rust заставит тебя проверить что там вернулось и соответственно отреагировать
Roman
функция возвращает либо тот тип, либо другой, а в Go может вернуться ошибка и мусорные данные, что не очень хорошо с точки зрения безопасности
Диёр
в Go вот есть проблема что если не проверить ошибку и продолжить работать с возвратными данными, то можно жутко выстрелить себе в ногу, спасает только errcheck но и то не всегда.
в Rust функция может вернуть Result<T, T>, где первый T это тип при удаче а второй  Т это тип возможной ошибки и Rust заставит тебя проверить что там вернулось и соответственно отреагировать
А чего раст то? Можно какой-нибудь древний фп язык взять и там почти наверняка будут maybe и either
Roman
А чего раст то? Можно какой-нибудь древний фп язык взять и там почти наверняка будут maybe и either
безопасность, вот почему
Диёр
Так сказал будто в хаскеле either опаснее
Vadim
вообще самый простой язык по синтаксису это бинарный код. Там только однёрка и нолик, но легко ли на нём писать multi-threaded cross platform приложение?
Я бы сказал, что он еще и более примитивный. Надо делать язык не примитивный, но простой
Roman
Я бы сказал, что он еще и более примитивный. Надо делать язык не примитивный, но простой
„simplicity is hard to achieve“
Roman
Вроде го наиболее близок к этому.
не совсем, он одновременно и близко но и очень далеко.
надо судить не только написанию и чтению (в этих аспектах Go силён), но и сложность содержания (bugs, scalability etc.)
Roman
со scalability тоже всё относительно хорошо, есть бенчмаркинг, есть профайлинг, легко работать в команде и т.д.
Roman
но вот безопасность в Go сильно храмает, а это приводит к багам, а баги жрут много времени
Диёр
.
Только не Кернигана
Roman
не люблю советовать книжки, люблю советовать ставить себе цели и решать их с помощью документации, stackoverflow и форумов)
.
Лучше смотреть видео с конференций
Foxcool
со scalability тоже всё относительно хорошо, есть бенчмаркинг, есть профайлинг, легко работать в команде и т.д.
А чем, кстати профилировать?
Foxcool
Флеймграфы бы красивые, вот это все
V
https://github.com/enocom/gopher-reading-list/blob/master/README.md
Savely
https://github.com/enocom/gopher-reading-list/blob/master/README.md
вот тут на русском много
https://t.me/golanglibrary
.
А есть что то типа go trace только в реальном времени?
Artem
Мб pprof раз в секунду подойдёт?
.
Та вот у trace такие графики красивые
.
Хочется такое же
🏁Александр
кмх
🏁Александр
вопрос такой, если у меня есть условно пакет dao только с интерфейсами структурами, долже ли пакет с реализации под конкретную бд использовать его
🏁Александр
вроде у нас утиная типизация, но структуры лежат же тоже в "абстрактном пакете"
.
Пример приведешь?
.
Вроде как понял о чём ты, но хочется убедиться
🏁Александр
dao
----
type User struct {
Family string
}
type UserRepository interface {
FindAll() []User
}
dao_mysql
----
type UserRepositoryMysql struct {
db *db.Conn
}
func (r *UserRepositoryMysql) FindAll() []User {
.....
}
.
Ну да, все ок
🏁Александр
dao_mysql получается должен "инклюдить" dao
🏁Александр
я боюсь как бы циклической не получилось
V
Не должен
V
А, ну хотя если юзер общий на пакеты, то должен
.
Вообще глянь на примеры чистой архитектуры на Го, очень похоже на то, чего ты хочешь добиться
🏁Александр
ну я по ней и делаю
🏁Александр
получается handlers используют интерфейс с пакета dao...
🏁Александр
а реализация кормиться только в main - UserRepositoryMysql
V
Зачем в пакете с моделью интерфейс репозитория?
🏁Александр
https://habr.com/post/271157/
🏁Александр
ну так было в статьи
🏁Александр
они делают абстрактный пакет всего
🏁Александр
а релизация отдельно
.
https://github.com/bxcodec/go-clean-arch
.
Вот тут очень хорошая реализация
.
Советую ее глянуть
V
Я в четыре слоя (= пакета) делаю, проблем пока не было
🏁Александр
думаю может модель в реализацию переместить
🏁Александр
хотя нет
🏁Александр
реализация должна независимо от бд возращать одинаковый результат
.
можно через тэги полей структуры типа
type U struct {
id int `default:"3"`
}
.
а там уже через рефлексию
.
глобальную переменную сделай
.
А вообще лучше конфиг во внешнем файлике в yaml хранить например
Roman
никто случайно не знает плагин для VSC для отображения спец символов дабы „->“ был представлен „→“?
Roman
или „!=“ как „≠“
ℝei
никто случайно не знает плагин для VSC для отображения спец символов дабы „->“ был представлен „→“?
fira code шрифт и лигатуры включи в настройках
Roman
fira code шрифт и лигатуры включи в настройках
https://github.com/tonsky/FiraCode он Rust не поддерживает разве?)
ℝei
https://github.com/tonsky/FiraCode он Rust не поддерживает разве?)
у этого шрифта больше всего лигатур реализовано