В 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! Фишка Го в том, что он простой как полено. Какая там жава и т.п., это слишком сложно всё.

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

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