Ну хоть что-то там хорошо)))

Доступ к полям структуры может быть получен через указатель на структуру. Чтобы получить поле X структуры, когда у нас есть указатель на структуру p, мы можем написать (*p).X. Однако такая запись громоздка, поэтому язык позволяет нам просто писать p.X, без явного разыменования.

Прикольно. А я всё время писал (*p).X и недоумевал почему нет p->X

Так и в Ди тоже не нужно разыменовывать

Кстати ещё одна проблема го - это очень много повторяющегося кода. Нет тернарных операций

Го это не для дачников, а для колхозников

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

Го - это си с гц, горутинами, объектами и интерфейсами. Чего еще желать можно? Охуенно же.

Беттерси говно, нужно использовать нормальную дишечку.

Го - это си с гц, горутинами, объектами и интерфейсами. Чего еще желать можно? Охуенно же.

Готов отказаться от такого счастья после года возни с ним?

Го - это си с гц, горутинами, объектами и интерфейсами. Чего еще желать можно? Охуенно же.

смысл от си с гц? ты даже не можешь сказать что у тебя на стеке будет, а что в куче

смысл от си с гц? ты даже не можешь сказать что у тебя на стеке будет, а что в куче

Но дык фишка в том, что знать и не надо. Правда - зачем это может быть нужно? Но вообще условно можно прикинуть, если объект не покидает функции, то он на стеке, если же референс на него может быть после завершения функции/он очень большой - то в куче.

а в Go разработчик не знает, где находится переменная?

а в Go разработчик не знает, где находится переменная?

Компилятор лучше знает

Го - это си с гц, горутинами, объектами и интерфейсами. Чего еще желать можно? Охуенно же.

ну и объектов там нет

ну что значит, лучше?

почему лучше

типа, где хочет, там и зарезервирует память?

не, мне го в принципе нравится ) но там очень странные идеи на мой взгляд. типа дженериков нет, но есть range\map

типа, где хочет, там и зарезервирует память?

How do I know whether a variable is allocated on the heap or the stack? From a correctness standpoint, you don't need to know. Each variable in Go exists as long as there are references to it. The storage location chosen by the implementation is irrelevant to the semantics of the language. The storage location does have an effect on writing efficient programs. When possible, the Go compilers will allocate variables that are local to a function in that function's stack frame. However, if the compiler cannot prove that the variable is not referenced after the function returns, then the compiler must allocate the variable on the garbage-collected heap to avoid dangling pointer errors. Also, if a local variable is very large, it might make more sense to store it on the heap rather than the stack. In the current compilers, if a variable has its address taken, that variable is a candidate for allocation on the heap. However, a basic escape analysis recognizes some cases when such variables will not live past the return from the function and can reside on the stack.

есть кодогенерация

ну и допустим ничего не мешало хотя бы перегрузку функций сделать

не, мне го в принципе нравится ) но там очень странные идеи на мой взгляд. типа дженериков нет, но есть range\map

Да будут там дженерики

Я был на гоконфе - Фицпатрик

говорил, что вся команда го - оче хочет дженерики

How do I know whether a variable is allocated on the heap or the stack? From a correctness standpoint, you don't need to know. Each variable in Go exists as long as there are references to it. The storage location chosen by the implementation is irrelevant to the semantics of the language. The storage location does have an effect on writing efficient programs. When possible, the Go compilers will allocate variables that are local to a function in that function's stack frame. However, if the compiler cannot prove that the variable is not referenced after the function returns, then the compiler must allocate the variable on the garbage-collected heap to avoid dangling pointer errors. Also, if a local variable is very large, it might make more sense to store it on the heap rather than the stack. In the current compilers, if a variable has its address taken, that variable is a candidate for allocation on the heap. However, a basic escape analysis recognizes some cases when such variables will not live past the return from the function and can reside on the stack.

вот это поворот)

Просто уже 8 разных реализаций сделала и все им не понравились. В Go2 завезут я думаю.

ну и допустим ничего не мешало хотя бы перегрузку функций сделать

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

Дескать когда видишь функцию - однозначно знаешь какая и с чем она вызвана

как будто язык для овощей делали)

как будто язык для овощей делали)

Для джунов гугла)

нет ексепшнов, но есть panic \ recover

на этом фоне даже похапе столпом программирования выглядит)

как будто язык для овощей делали)

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

нет ексепшнов, но есть panic \ recover

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

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

> ошибки через них не обрабатывают. обрабатывают

только называют их по-другому

и пишут руками

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

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

все эти кортежи компилируются ровно в тот же код что эксепшены

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

и SQL

а в итоге теперь приходится программистам это всё расхлебывать

глядишь, лет через 15 появится новая профессия: легаси программист на го за сто миллионо денег

все эти кортежи компилируются ровно в тот же код что эксепшены

Ничерта. Я писал плюсовый ABI для работы с исключениями - это пиздец. К каждой функции дописать таблицу с метаинформацией, 2 раза побегать по стеку в случае исключения и анализировать эти таблицы. Просто жесть. Тут больше на сишные ретерн-коды похоже и это правильно и быстро. В расте примерно также, но там аналоги хаскельных Maybe (Result на расте или Optional на плюсах).

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

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

я не хейчу) просто мне кажется странным идеология некоторых вещей

мне наоборот нравится что всякий http, json, go routines есть всё из коробки

я не хейчу) просто мне кажется странным идеология некоторых вещей

Ну за большинством таких штук есть аргументация. Например, if err != nil - самой команде го тоже не нравится, сейчас думают, как устранить эту копипасту в go2.

Го это по сути компилируемый питон специализированный на серверный продакшн. Не скажу почему хейчу, но причину переход на D уже говорил выше

Ничерта. Я писал плюсовый ABI для работы с исключениями - это пиздец. К каждой функции дописать таблицу с метаинформацией, 2 раза побегать по стеку в случае исключения и анализировать эти таблицы. Просто жесть. Тут больше на сишные ретерн-коды похоже и это правильно и быстро. В расте примерно также, но там аналоги хаскельных Maybe (Result на расте или Optional на плюсах).

И чем это отличается от возврата кортежа с возможной ошибкой?

Го это по сути компилируемый питон специализированный на серверный продакшн. Не скажу почему хейчу, но причину переход на D уже говорил выше

ну не. там всё таки многопоточность

статическая типизация

кароч ни разу не питон )

И чем это отличается от возврата кортежа с возможной ошибкой?

Размер бинаря распухает, производительность падает (2 раза по стеку пройтись вместо одного), проход по стеку опять же не просто ретерн, а вызов персональной функции для таблицы кэтчей. Исключения оче медленны.

Размер бинаря распухает, производительность падает (2 раза по стеку пройтись вместо одного), проход по стеку опять же не просто ретерн, а вызов персональной функции для таблицы кэтчей. Исключения оче медленны.

ну требуйте final switch тогда

правда, от него везде отказались

Только многопоточность внеконкуренции

правда, от него везде отказались

Всм? В расте все только и говорят match с его паттерн-матчингом

ну поебутся как яваёбы поебались - увидят

если бы всё было так просто оно бы уже давно везде было

В питоне сахару побольше) что никакая статика рядом не стояла) одной строчкой можно написать то что на го в 50 строк например

ну поебутся как яваёбы поебались - увидят

Ну сам по себе final switch - такое себе, а вот если паттерн-матчинг, как в хаскеле/расте - то это уже может быть даже очень интересно.

а там по названию эксепшена типа поиск?

а там по названию эксепшена типа поиск?

Где?

ну ты говоришь паттерн матчинг

кого оно там матчит?

ERROR: S client not available

кого оно там матчит?

Возвращаем enum Result, который может быть или Err или Ok c объеками, самое главное еще можно во внутренностях Err или Ok покопаться сразу при получении и разные действия предпринять, при этом гаранируется, что копаясь во внутренностях мы все варианты предусмотрим

Pattern Matching в Rust - это swith + tryVisit для Algebraic

не, просто visit кажется

поэтому и удобно

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

Так это не та простота которая нам нужна. Это простота реализации, а нам нужна простота пользования. Исключения позволяют отделить логику кода от уровней обработки ошибок. return коды - нет. Параметры по умолчанию позволяют не менять параметр в 100500 местах если он изменился. Дженерики позволяют абстрагироваться от реализации хранилища. И так во всем.

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

Так это не та простота которая нам нужна. Это простота реализации, а нам нужна простота пользования. Исключения позволяют отделить логику кода от уровней обработки ошибок. return коды - нет. Параметры по умолчанию позволяют не менять параметр в 100500 местах если он изменился. Дженерики позволяют абстрагироваться от реализации хранилища. И так во всем.

А потом все лагает как в j***script

Во-первых не лагает, во-вторых не все, в третьих не как в javasript. Сразу 3 ложных утверждения ))

го сам лагает по сравнению с си

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

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

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

Во-первых не лагает, во-вторых не все, в третьих не как в javasript. Сразу 3 ложных утверждения ))

Утрирую. Всегда есть перекос в сторону удобства, в отличии от скорости.

Утрирую. Всегда есть перекос в сторону удобства, в отличии от скорости.

Есть но это удобство компенсирует более медленную работу. В итоге продукты все равно получаются круче и поддерживать их проще.

Только надо больше мозга иметь и разобраться.

Есть но это удобство компенсирует более медленную работу. В итоге продукты все равно получаются круче и поддерживать их проще.

Пока что это компенсируется растущей мощностью

Я кстати щас пишу на TS под ангуляр, с удовольствием говнокожу ) Не использую хешмапы, обхожу массивы квадратичной сложностью для сортировки, копирую данные по 100 раз. Пользователь будет страдать ?

Я кстати щас пишу на TS под ангуляр, с удовольствием говнокожу ) Не использую хешмапы, обхожу массивы квадратичной сложностью для сортировки, копирую данные по 100 раз. Пользователь будет страдать ?

Квадратичная? А почему не факториальная?

Потому что там надо выбрать максимальные элементы в группах.

Квадрата хватает

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

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

Я кстати щас пишу на TS под ангуляр, с удовольствием говнокожу ) Не использую хешмапы, обхожу массивы квадратичной сложностью для сортировки, копирую данные по 100 раз. Пользователь будет страдать ?

не смешно же ((

и так бравзеры ползают

Так это не та простота которая нам нужна. Это простота реализации, а нам нужна простота пользования. Исключения позволяют отделить логику кода от уровней обработки ошибок. return коды - нет. Параметры по умолчанию позволяют не менять параметр в 100500 местах если он изменился. Дженерики позволяют абстрагироваться от реализации хранилища. И так во всем.

Ну дык в некоторых приложениях (которые по сети ходят или по файловой системе) - ошибки это ничерта не исключение, а норма, поэтому должна обрабатываться не каким-то тяжелым и сложным механизмом, а реакция на ошибку должна быть непосредственно вплетена в логику. Рефлексия, кодогенерация и интерфейсы позволяют абстрагироваться (да и завезут в го дженерики). Мне просто не нравится этот подход. Есть механизм исключений - у него много плюсов и много минусов. В язык не стали добавлять именно этот механизм из-за того, что показалось, что в стандартном юзкейсе минусы будут перевешивать. Внедрили другой механизм, который опять же имеет плюсы, минусы, но для стандартного юзкейса плюсы наоборот будут перевешивать. И все кричат ФУ ПОЧЕМУ НЕТ МЕХАНИЗМА A? ВЕДЬ МЕХАНИЗМ Б - ПРИМИТИВ!

это, например, какие ошибки — норма?

Ну дык в некоторых приложениях (которые по сети ходят или по файловой системе) - ошибки это ничерта не исключение, а норма, поэтому должна обрабатываться не каким-то тяжелым и сложным механизмом, а реакция на ошибку должна быть непосредственно вплетена в логику. Рефлексия, кодогенерация и интерфейсы позволяют абстрагироваться (да и завезут в го дженерики). Мне просто не нравится этот подход. Есть механизм исключений - у него много плюсов и много минусов. В язык не стали добавлять именно этот механизм из-за того, что показалось, что в стандартном юзкейсе минусы будут перевешивать. Внедрили другой механизм, который опять же имеет плюсы, минусы, но для стандартного юзкейса плюсы наоборот будут перевешивать. И все кричат ФУ ПОЧЕМУ НЕТ МЕХАНИЗМА A? ВЕДЬ МЕХАНИЗМ Б - ПРИМИТИВ!

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

это, например, какие ошибки — норма?

Обрывы соединений и таймауты - это норма

Впринципе да, если писать работу с сетью, то там все сущности проникают друг в друга, особо ниче не инкапсулируешь.

Обрывы соединений и таймауты - это норма

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

логика исключений проста — их нужно бросать, когда не знаешь что еще делать

например, идешь в базу читать объект по ключу, а таких нету, возвращаешь null-object