В Go есть ООП, а в C нет?

Меня кстати бесят, когда в проекте притащено 2-3 парсера json, а с библиотеками это частая ситуация.
Хотя я вплне понимаю, что в крупном проекте могут быть разные несвязанные между собой модули или другие библиотеки, каждая из которых с json'ом работает по своему и пересадить всех на один парсер не всегда возможно.
В винде есть стандартный парсер ini и он и был долгое время стандартом для текстовых конфигов. А в юниксах такого не было, потому сначала конфиги стали в xml пистать, что жутко не удобно, потом уже пошли json/yaml/toml. Из них более-менее удобный toml, но спецификация у него такая жирная и сложная, что я у себя просто ini запилил.

Я не «сварщик», но если бы подключился к проекту, то поинтересовался бы, какие библиотеки используются и почему.

Это называется «богатая библиотека».

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

И размером бинарников как делфи.

А писал бы я на Go, надо было бы всего лишь написать

import «encoding/json»

и дело в шляпе

Наивное летнее дитя 😂 Вот например: https://github.com/coder/websocket Одна из самых популярных библиотек для работы с вебсокетами использует свой парсер json, потому что «It will reuse buffers in between calls to avoid allocations».

И таких примеров не один и не два.

На перфокартах экономишь? ;)

Прикола ради, решил глянуть, как кол-во строк влияет на размер бинарника. Благо есть набор микро-копролитов для эксперимента. Итого:

+--------+------+
|    LoC | Size |
+--------+------+
| 112049 | 48M  |
|  64283 | 42M  |
|  49091 | 49M  |
|  37038 | 34M  |
|  28688 | 41M  |
|  13855 | 30M  |
|  12799 | 51M  |
|  12756 | 45M  |
|   9661 | 19M  |
|   4681 | 38M  |
|   2566 | 24M  |
|   2337 | 20M  |
|    795 | 18M  |
|    789 | 27M  | 
+--------+------+

Это всё очень примерно и не учитывает внешние зависимости. Но тренд вполне ясен.

Дрочить в присядку никто не запрещал. Но в 99.99% случаев import "encoding/json" более чем достаточно.

В винде есть стандартный парсер ini и он и был долгое время стандартом для текстовых конфигов. А в юниксах такого не было, потому сначала конфиги стали в xml пистать, что жутко не удобно, потом уже пошли json/yaml/toml.

Qt/KDE поддерживают .ini. Но со своими выподвывертами. Например, заголовки у секций могут быть многозначными: [Mouse][Xiaomi][evdev]

Обычные .ini парсеры на этом валятся, поэтому утилита tapper, написанная одним из участников ЛОР (не помню ник), под KDE не работает. Я попытался пофиксить, но быстро плюнул, ибо времени вообще нет, и не хочется изобретать велосипед, в условиях, когда времени не хватает на базовые потребности.

Я к тому, что какой-то непонятный тренд «всё своё ношу с собой, завишу только от ядра».

Rust вроде как тоже в том же направлении пошёл.

в С для вас вообще ничего нет, а ну кыш отседова!
ходют и ходют…

Чтобы переносимость была

Интересно услышать твое мнение, по поводу моего примера с исключениями.

Вы где настолько оторвано от жизни живёте и работаете?

В мире линукса где каждая вторая программа на С?

Если дрочить на локи и вес, то тогда будем честны, ставь tinygo и научись его готовить

В мире линукса где каждая вторая программа на С?

Во-первых, не уверен насчёт каждой второй.

Во-вторых, в мире линукса нет дедлайнов, необходимости срочно подстраиваться под какие-то политические или экономические требования, быстро меняющуюся конъюнктуру. Берешь себе и пилишь, сколько душе угодно. Хоть десятилетие cat полируй.

Твой комментарий подталкивает к идее что Go выгоден только гонщикам, а если ты хочешь сделать хорошую программу, то нужно уходить в монастырь с С. Да и чем пользуются эти гонщики? openssh, postgresql, vim, redis, итд. Как будто проблема не в С, а в системе которая не дает делать хорошее ПО.

Это к другим. Я только показал, что это без разницы. Есть какой-то минимальный overhead, а дальше оно слишком сильно не растёт.

это к «все свое ношу с собой» ортогонально. вон zig тоже все носит - helloworld весит 10 килобайт (статически скомпилированный)

какой-то непонятный тренд

Да всё там понятно. Shared libraries – это костыль древнющих времён, когда и места было мало, и компьютеры были с холодильник.

Вот мнение Линуса, Пайк, Керниган и дугие с ним согласны.

Shared libraries – это костыль древнющих времён, когда и места было мало, и компьютеры были с холодильник.

Мне нравится что моя система без данных весит 10 гб, а не 100 гб, или 150 гб. Цифры получены из сравнения веса нативных пакетов, и всяких AppImage и msi.

Ну ладно, 150 гб на диске не жалко, пусть и NVMe. Но оно же обновляться будет, у меня нету возможности подключить больше 100 мб. Игры уже весят прилично, и каждый запуск Windows сопровождается тем, что я не могу поиграть пока не скачаются гигабайты обновлений, а если так будет еще и с обычным ПО?

Линус пишет про разделение clang и llvm, мне такое тоже не нравится. В Slackware этого нету, это хороший подход, нужно знать меру.

Встречаю такое утверждение, что в Go есть ООП, просто через структуры.

Выдают желаемое за действительное. Полноценный ООП есть в С++, Java и других языках. Вся идея существования Go - это чистый маркетинг. У других языков в их основоположении была какая-то концепция. Концепция Golang-а - исправление фатального недостатка у других языков. При этом нужно было умудриться придумать язык хуже PHP (который потом стал лучше). Почему, скажем, Kotlin-у не дают такого же кол-ва внимания - мне не понятно. Уже давно даже Java научились в нативный код собирать. Смысл в Golang-е около нулевой.

гораздо проще выстрелить себе в ногу

нет GC из коробки

Java или Rust

нет автоматического управления ресурсами вообще (аналога defer)

Который как будто специально сделали плохо, что нужно гадать нужен ли этот defer для определённого ресурса. В Java и Python сделали как надо через try with resources и with.

нет управления зависимостями из коробки (и не из коробки тоже)

Убогая билд система без поддержки кастомных таргетов и абсолютная катастрофа в плане безопасности. Клоним вирусню в зависимостях без какой либо проверки. Здорово.

На ini в отличие от toml нет спецификации. Но в toml полезли куда-то не туда и сделали избыточнвю спецификацию со всяеими массивами и т.д. в итоге реализации toml обязаны быть сильно сложнее ini, иначе они неполные

Java или Rust

В Rust сложное ручное управление памятью. Делать структуры с кучей ссылок замучаешься.

Здесь явно неправильно был понят мой пост.

Я не люблю Go, хотя иногда пишу на нём вынужденно (потому что до меня было принято решение в компании писать на Go, потому что хочется кушать, а вакансий на Go много и становится всё больше).

Но если выбирать между C и Go, я бы выбрал однозначно Go (если речь не о разработке ядра).

Вся идея существования Go - это чистый маркетинг. У других языков в их основоположении была какая-то концепция. Концепция Golang-а - исправление фатального недостатка у других языков. При этом нужно было умудриться придумать язык хуже PHP (который потом стал лучше)

(голосом Николая Дроздова) а вот перед вами товарищ, который гонит на wayland и заявляет, что будет поддерживать иксы только за деньги. Обратите внимание на высокий технический уровень его экспертных заключений :)

Java

Копролит.

Который как будто специально сделали плохо, что нужно гадать нужен ли этот defer для определённого ресурса.

Что там гадать? Когда сделать close? А Java бросает ошибку компиляции?

Специально плохой механизм — это try-finally. Именно он, кажется, был мотивацией добавить try with resources.

Убогая билд система без поддержки кастомных таргетов

Что такое кастомный таргет?

И в чём убогость заключается? В том, что это не CMake?

Клоним вирусню в зависимостях без какой либо проверки.

В чём проблема запустить govulncheck?

Полноценный ООП есть в С++, Java и других языках.

Просто интересно, в чём заключается полноценность.

Просто интересно, в чём заключается полноценность.

Вероятно, в том, что открывая любой проект на Java, видишь бесконечные километры бойлерплейта:

class A {
  private Integer foo;

  void setFoo(Integer bar) {
    foo = bar;
  }

  Integer getFoo() {
    return foo;
  }

  // Ещё несколько тысяч строк такого же кода для каждого атрибута класса
}

Многие считают, что это и есть признак настоящего ООП и написание такого бойлерплейта и есть программирование.

Если только так:

CONST KindCircle = 1
CONST KindSquare = 2

TYPE Shape
    kind AS INTEGER
    x AS INTEGER
    y AS INTEGER
END TYPE

DIM ci AS Shape
DIM sq AS Shape

ci.kind = KindCircle
ci.x = 2
ci.y = 3

sq.kind = KindSquare
sq.x = 4
sq.y = 5

ShapeDraw ci
ShapeDraw sq

END

SUB ShapeDraw (s AS Shape)
    SELECT CASE s.kind
        CASE KindCircle
            CircleDraw s
        CASE KindSquare
            SquareDraw s
    END SELECT
END SUB

SUB CircleDraw (s AS Shape)
    PRINT "Circle in ("; s.x; ", "; s.y; ")"
END SUB


SUB SquareDraw (s AS Shape)
    PRINT "Square in ("; s.x; ", "; s.y; ")"
END SUB

Копролит.

Go - это корполит. Им удалось изобрести язык где фичи на уровне 70-х годов. Java и Kotlin в сто раз круче Go.

Специально плохой механизм — это try-finally. Именно он, кажется, был мотивацией добавить try with resources.

Мда, разницу вы не понимаете, ну ладно…

Что такое кастомный таргет?

Сразу видно опытного программиста. /sarcasm

Вот нужно мне условно пакет с приложением собрать. Или в систему поставить.

И в чём убогость заключается? В том, что это не CMake?

Им хотя бы до уровня Makefile дотянуть.

В чём проблема запустить govulncheck?

Ну всё. Пошло поехало - прикручиваем костыли сбоку. Ну, слава богу хоть такое есть.

Просто интересно, в чём заключается полноценность.

Поюзайте glib, а потом ООП в C++ - поймете почему важен полноценный ООП. Там много разных факторов - читаемость кода, удобство, отсутствие необходимости делать костыли, чтобы воспроизвести полноценный ООП и т.д. «У нас есть ООП, просто оно на структурах» - это быть подключенным к «copium» аппарату.

который гонит на wayland и заявляет, что будет поддерживать иксы только за деньги

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

Вероятно, в том, что открывая любой проект на Java, видишь бесконечные километры бойлерплейта:

Ухх, в современной Java так уже никто не делает даже. Есть такая вещь как аннотации, в Python, например, похожий механизм - называется декораторами.

class A {
  @Getter @Setter
  private Integer foo;
}

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

Чтобы «продать» го народу, приходится говорить, что в нём есть ООП. Си никому продавать не надо, поэтому таких утверждений никто и не делает.

Да ладно. Go хорошо продаётся и так. О причинах можно гадать. В основном, думаю, то, что пушится большой известной корпорацией.

Например, если завтра МордоКнига придумает язык Run, то каким бы он ни был плохим или хорошим, значимый процент людей всё равно начнёт им пользоваться. Что-то из разряда «ещё никого не увольняли за покупку IBM» (а стоило бы!).

Но и всё же. Если я сяду разрабатывать веб-сервис, пусть даже крохотный, и выбор только между C и Go, то выберу Go. Как и 95% разработчиков, почти уверен в этом.

Есть такая вещь как аннотации, в Python, например, похожий механизм - называется декораторами.

Вообще ничего общего.

По теме: https://go.dev/doc/faq#Is_Go_an_object-oriented_language

Почему, скажем, Kotlin-у не дают такого же кол-ва внимания - мне не понятно. Уже давно даже Java научились в нативный код собирать. Смысл в Golang-е около нулевой.

Котлину как раз дают, он даже свою нишу занял. Так что требую финансирования для Crystal! Фишка Го в том, что он простой как полено. Какая там жава и т.п., это слишком сложно всё.

То есть у вас разработчики должны за бесплатно работать?

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

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

Самый умный что-ли? То что вейланд - кал уже задокументировали. То что корпы убивали иксы намеренно - тоже задокументировано.

Относительно Golang - он буквально заслужил отдельную страницу в списках плохо спроектированных языков. В других языках тоже есть недостатки - но они как-то нивелируются и размазаны. У Go же всё это объясняется «simplicity»™ и тем что «программисты Go - слишком тупые». При этом за годы почти ничего не было исправлено - я никаких улучшений и подвижек к этому не увидел.

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

Встречаю такое утверждение, что в Go есть ООП, просто через структуры. Но в C тоже есть структуры, но почему-то говорят что там нет ООП, почему? Или в Go поверх структур еще много чего, чем C не может похвастаться?

ООП - это парадигма, которая не зависит от языка программирования и больше относится к архитектуре программы (выделению объектов, их атрибутов и методов), можно делать хоть на ассемблере.

Вероятно, так говорят потому что в Go синтаксис языка и комплексные операции (синтаксический сахар) позволяют получить меньше строк кода и написать сам код быстрее, не задумываясь об архитектуре процессора, памяти, указателях и прочих нативных «прелестей».

Тоже самое можно сказать и про JAVA и про C# и про другие языки.

В Си, всё «мясом наружу» – сначала конструируешь атомы, потом молекулы и потом из этого уже объекты и всю программу.

бесконечные километры бойлерплейта:

Чья бы корова мычала, а Go-шная — промолчала.

Oberon-2 ООП во все поля, кстати, не говоря уже о более поздних вариантах.

Меня последнее время одолевает одна мысль:

Появление языков, в которых ни черта нет, напоминает мне «мартышка тут с досады и с печали о камень так хватила их, что только брызги засверкали».

Индустрия периодически подкидывает дурачкам серебряные пули.

Взять тот же ООП: в 90х все ломанулись в него не разбирая дороги, пихали наследование где надо и где не надо, фигачили «16 паттернов в 32 строках кода» – а в результате закономерно получался типичный кошмар.

Потому что сама идея серебряной пули в принципе порочна, т.к. подразумевает, что думать будет не надо.

Продолжая тему ООП-шных языков, такой же (если не хуже) кошмар с исключениями. Ни на одной работе не видел, чтобы исключениями умели пользоваться. В пределе – тупо создают по новому подклассу Exception на каждый throw, пилят килотонны бессмысленных и беспощадных catch-rethrow в каждом методе, причём работает всё это в удивительную раскоряку, ошибки сыпятся как попало какие попало, в результате логи засраны длиннющими (spring же ж) стек-трейсами с многократными повторениями (т.к. в каждый catch-rethrow обязательно впиливают логирование), а морда либо глотает ошибки, либо показывает их так, что лучше бы не показывала.

Умный человек, набив некоторое критическое количество шишек, остановится, подумает, решит, что всё хорошо в меру, и выработает и формализует для себя какие-то сбалансированные подходы.

А дурак будет «хватать о камни». И появляются лозунги, что наследование не нужно, достаточно интерфейсов; и появляются языки, в которых ни ООП, ни исключений. Все знают, о каких языках речь. ;)

Сюда же NoSQL (этот хайп уже вроде давно утих), чистое ФП (судя по hh, на подъёме), и на моё ИМХО самая мерзотная серебряная пуля из ныне здравствующих – микросервисы.

(язвительно) Вот, сижу жду, когда маятник качнётся взад в монолиты.

При том, что, если подумать, то в каждой конкретной системе и для NoSQL можно место найти; и ФП-шные паттерны чрезвычайно упрощают жизнь – безо всякого чисто-ФП-шного фанатизма; и без сервисов (не «микро», мать вашу) ни одна серьёзная система не обойдётся.

А вот, например, на моей нынешней работе сервисы создаются не по принципу «когда нужно», а по принципу «когда можно». Каждую новую мелочь в новый сервис заворачивают. Видимо уже не способны думать о декомпозиции в других терминах – в maven-модулях, packages, да хотя бы банальных классах. И в результате непрерывно трахаются с непрерывно отваливающимся деплойментом (каждый сервис в отдельном контейнере, ага, с хорошо если всего парой десятков env-ов). При этом вся система сильно связана, и являются нормой ситуации с длинными, в т.ч. даже рекурсивными цепочками вызовов между сервисами; и многие сценарии на порядок менее эффективны, чем могли бы быть.

Встречаю такое утверждение, что в Go есть ООП

В Go нет ООП, т.к. нет инкапсуляции и наследования.

Почему не использовать для тех же задач C вместо Go? Go юзают из за низкого порога входа или чего?

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

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

3. В Go богатая стандартная библиотека, что позволяет писать программы быстро и без возни с зависимостями

4. В Go встроен неплохой набор инструментов, что, опять же, позволяет писать программы быстрей. Есть система сборки, есть система управления зависимостями, есть встроенная система форматирования.

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

не ошибается только тот, кто вообще ничего не пишет. хотя я бы не сказала, что ООП - это что-то сверхсложное.

более того, я вроде даже где-то видела подобные библиотеки на Си на просторах интернетов. всё уже написано до нас. вопрос в том, нужно ли оно. в Си довольно неплохо прижились функторы, коллбэки, списки функций и прочее такое. это чисто утилитарные вещи, они растут из практики программирования. но ООП в полном объёме, а не просто «Си с классами» - это просто никому не требуется в разработке. поэтому и нет ажиотажа.

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

за этот пост зело плюсую.

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

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

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

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

У меня, к сожалению, не было опыта работы со Smalltalk, но это была целая система, написанная в ОО-стиле. Вполне себе демонстрация того, что операционные системы возможно писать без уровня языка C.

Или взять Erlang — язык, прямо сейчас питающий высоконагруженные системы. В нём абстракции ещё дальше от железа, чем в общепринятых ОО-языках Java/C++/итд.

Что до моего личного мнения относительно ООП, я тоже считаю, что оно переоценено. Важное понятие — не ООП, а абстракция. У уже как она будет достигаться — типами, замыканиями или per-process namespaces — детали реализации.

есть теория ради теории и код, который её демонстрирует. это вот Smalltalk. это демонстрация для студентов, а не реальный пример из жизни.

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

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

И появляются лозунги, что наследование не нужно, достаточно интерфейсов; и появляются языки, в которых ни ООП, ни исключений. Все знают, о каких языках речь. ;)

Соглашаясь с вашим тезисом о том, что нельзя опровергать наследование только потому, что оно в нескольких случаях плохо себя показало, обращу внимание на то, что некоторые идеи неизбежно конфликтуют друг с другом и приходится выбирать что-то одно. В куртке осенью удобно ходить, но не так формально, как в пальто. Так и с наследованием: добавляя его в язык, мы неизбежно поощряем его использование. Тогда как авторами возлагались другие цели на язык, а именно:

Object-oriented programming provides a powerful insight: that the behavior of data can be generalized independently of the representation of that data. The model works best when the behavior (method set) is fixed, but once you subclass a type and add a method, the behaviors are no longer identical. If instead the set of behaviors is fixed, such as in Go’s statically defined interfaces, the uniformity of behavior enables data and programs to be composed uniformly, orthogonally, and safely.

…

… The hierarchy must be designed early, often as the first step of designing the program, and early decisions can be difficult to change once the program is written… .

Go at Google

Что в двух словах выражается: «пишите абстрактный код, а не привязывайте конкретику к разветвлённой иерархии типов». Go, вопреки беспрецедентному элитизму со стороны евангелистов мета-программирования, заставляет писать более абстрактный код.

Наследование имеет место быть — для написания других программ на других языках. А интерфейсы лучше выполняют возложенную цель. И, кстати, они сделаны уникальным образом, отличающимся от современных реализаций: сочетание гибкости питона и гарантии статической проверки в одном флаконе.

Аналогично и с обработкой ошибок и с исключениями. Есть причины. А объяснять поступки людей глупостью, что люди что-то делают по незнанию — это удобный шорткат, которым, кстати, пользуются обе стороны любого конфликта.