Ещё раз, разговор не о том, что все обязаны перерабатывать, ночевать и все выходные на работе проводить да ещё бесплатно. И не в том, что конкретный работник уходит ровно. А в том, что десяток человек не могут быть вашими клонами и вести себя одинаково.
Я эту часть упустил в ветке.
Мой ответ тогда лучше воспринимать как субъективное мнение, не сильно привязанное ко всем вашим высказываниям.
У человека дома даже без семьи могут быть задачки поинтереснее, в том числе интеллектуальные, в том числе в программировании. Не знаю как у других, у меня задачек меньше, чем на несколько часов или дней почти не бывает. С такими обычно даже на час задерживаться смысла мало, корректность важнее, а для неё нужно быть свободным от желания переключиться.
Даже интересная работа под конец дня может вызвать желание переключиться (обычно это гораздо чаще одного раза в день происходит, просто 18 часов выглядят отметкой, которая удобна для переключения). Это нормально.
И вообще, тут виновато расписание «с 9 до 18».
Вводим понятие «важен результат, а не уйти в 18», но при этом есть чёткий график.
Я могу и в 16, условно, уже на сегодня всё сделать, а оставшиеся часы планировать дальнейшие дни и недели, и тут вполне удобно оторваться от рабочего компьютера ровно по расписанию. Это тоже часть работы, но задерживаться ради неё смысла нет.
А ещё у человека может быть депрессия и ему хочется поскорее домой, потому что он не ищет компании.
Меня очень расстраивает, когда весь коллектив задерживается а тех, кто уходит вовремя (и приходит вовремя), порицают.
Расписываюсь, что в курсе холиварности этой темы. Тут куча простора для недопонимания и альтернативных точек зрения.
А выгорание едва ли начнётся, если к домашнему опенсорсу относиться как к хобби.
Очень любопытно стало, а вам свойственно доводить хобби проекты «до конца»?
Ваш опыт может отличаться, но по моим наблюдениям в какой-то момент основной интерес и элегантность проекта улетучивается и чтобы продолжать нужно больше сил, чем при старте.
Большое количество покинутых проектов меня сильно демотивирует.
В крайних случаях может сопутствовать выгоранию.
Возможно мне действительно не хватит знаний продолжить диалог, но стало любопытно: а если член структуры является полиморфным типом, разве компилятор сможет в каких-то случаях избежать перерасхода памяти?
Про спекулятивную девиртуализацию поищу.
Anyway, в Go можно явно сказать: «Тут мне полиморфный тип, а тут просто структру T».
В C++ же полиморфность является свойством самого типа T. Right?
Возможно проблема в том, что у Go нет своего pip.
Go build и то, что близ него — это довольно низкоуровневые вещи.
Мне не очевидно, насколько github.com/constabulary/gb юзабелен, но скорее всего со временем появится хороший project-based тул, который станет тем самым pip для Go.
Я хотел бы заметить, что в случае C++ добавив в класс [тип T] виртуальный метод, у вас каждый экземпляр типа T будет содержать таблицу виртуальных методов.
В случае Go сам тип T, реализующий интерфейсы, таблицы виртаульных методов не содержит никогда, поэтому когда мы не используем полиморфное поведение, не будет лишнего жира. Когда T передаётся как интерфейсный тип, вот там уже будет боксинг с аллокацией.
Насколько это хорошо или плохо — не хочу полемизировать, но подчеркнуть, что это не «Как в C++», всё-таки захотелось.
Через Go ассемблер можно использовать и SSE, и AVX, а MMX я бы просто не рекомендовал использовать. :)
И это добро реально используют при оптимизации, например, стандартной библиотеки Go.
Можете либо уточнить, что имели в виду, а ещё лучше, предоставить сслыку, если там какой-то разбор фатального недостатка, пожалуйста?
Или всё довольно банально и `std::async` просто откладывался несколько раз?
и ещё одна путаница, и уже другого стиля (!) Итого — два разных стиля.
Это способ описания указателей на функции без надобности запоминать странные правила их определения.
Не уверен, что понял, о какой «путаннице» вы говорили.
С этим макросом стиль определения будет чем-то похож на тот, что в Go:
Спорить с тем, что в C не самый удачный синтаксис для указателей на функции и тем, что рядом с ними, никто не будет.
Я хотел ответить здесь чтобы любой, кто прочтёт ваш комментарий, не был введён в заблуждение. Нет «ограничения» данной нотации в плане функциональности.
Вы определили fun1, а не fun2. Похоже, это опечатка — если написать fun2, то получится то, что ожидается (?)
Да, получится то, что вы описывали.
Это, кстати, не самый удивляющий пример.
Без typedef определить функцию, возвращающую функцию, которая возвращает и принимает функцию — вот тут в скобочках и звёздочках нормальные люди начнут «плавать».
`unsafe.Pointer` и `uintptr` в совокупности с возможностью преобразовывать их друг в друга дадут возможность читать по указателю со смещением.
Это может быть полезно при работе, например, с сишными библиотеками.
Point в том, что там, где реально нужно использовать арифметику указателей, делать это можно. Тезис «людям не нравится адресная арифметика» не обоснован,
корректнее сказать: «большинству не нравится адресная арифметика там, где можно было обойтись без неё».
Можете поправить, если я не прав, но за деструкторами может захотеться «семантики перемещения» (move semantics).
По-моему опыт C++ и Rust показывает, что без этого не очень хорошо живётся.
Моё мнение не отражает мнение авторов/сообщества Go, но «Вирусные» возможности языков программирования выглядят менее вероятными кандидатами.
Не знаю, чем это `goa`, `gol`, `goc` так понравились «коммандеру».
Хотя...
В том же Plan9, мимо которого Rob Pike не прошёл мимо, какая-то странная манера именования прослеживается:
asm0 — MIPS
asm5 — ARM
asm6 — AMD64
asm9 — PPC64
У «go» как названия скорее кучу недостатков можно найти, а не «оправданий», начиная от того, что у поисковиков с «go» не так всё гладко (недавно ещё и «Android Go» появился, который никак с Go не связан), заканчивая тем, что это название уже было занято другим языком программирования.
«golang» в запросах и тегах помогает отбросить неоднозначность, но это костыль.
Proposal для Go 2 написали? :)
Возможно такой уже есть, надо искать.
Если хорошо расписать, то какой-то минимальный шанс на значения по умолчанию для структур есть.
Насчёт параметров функций по умолчанию не уверен. Не упаковывал бы
это всё в один proposal.
Я эту часть упустил в ветке.
Мой ответ тогда лучше воспринимать как субъективное мнение, не сильно привязанное ко всем вашим высказываниям.
Даже интересная работа под конец дня может вызвать желание переключиться (обычно это гораздо чаще одного раза в день происходит, просто 18 часов выглядят отметкой, которая удобна для переключения). Это нормально.
И вообще, тут виновато расписание «с 9 до 18».
Вводим понятие «важен результат, а не уйти в 18», но при этом есть чёткий график.
Я могу и в 16, условно, уже на сегодня всё сделать, а оставшиеся часы планировать дальнейшие дни и недели, и тут вполне удобно оторваться от рабочего компьютера ровно по расписанию. Это тоже часть работы, но задерживаться ради неё смысла нет.
А ещё у человека может быть депрессия и ему хочется поскорее домой, потому что он не ищет компании.
Меня очень расстраивает, когда весь коллектив задерживается а тех, кто уходит вовремя (и приходит вовремя), порицают.
Расписываюсь, что в курсе холиварности этой темы. Тут куча простора для недопонимания и альтернативных точек зрения.
[Картинка «This is fine», всё в огне]
Спасибо.
По мне так наоборот, пусть живёт и процветает.
Первый CL из этой серии уже улетел на go-review.
Возможно в Go 1.11 будет новый x86.csv. И ещё кое-что полезное…
Очень любопытно стало, а вам свойственно доводить хобби проекты «до конца»?
Ваш опыт может отличаться, но по моим наблюдениям в какой-то момент основной интерес и элегантность проекта улетучивается и чтобы продолжать нужно больше сил, чем при старте.
Большое количество покинутых проектов меня сильно демотивирует.
В крайних случаях может сопутствовать выгоранию.
Про спекулятивную девиртуализацию поищу.
Anyway, в Go можно явно сказать: «Тут мне полиморфный тип, а тут просто структру T».
В C++ же полиморфность является свойством самого типа T. Right?
Go build и то, что близ него — это довольно низкоуровневые вещи.
Мне не очевидно, насколько github.com/constabulary/gb юзабелен, но скорее всего со временем появится хороший project-based тул, который станет тем самым pip для Go.
В случае Go сам тип T, реализующий интерфейсы, таблицы виртаульных методов не содержит никогда, поэтому когда мы не используем полиморфное поведение, не будет лишнего жира. Когда T передаётся как интерфейсный тип, вот там уже будет боксинг с аллокацией.
Насколько это хорошо или плохо — не хочу полемизировать, но подчеркнуть, что это не «Как в C++», всё-таки захотелось.
И это добро реально используют при оптимизации, например, стандартной библиотеки Go.
Можете либо уточнить, что имели в виду, а ещё лучше, предоставить сслыку, если там какой-то разбор фатального недостатка, пожалуйста?
Или всё довольно банально и `std::async` просто откладывался несколько раз?
Это способ описания указателей на функции без надобности запоминать странные правила их определения.
Не уверен, что понял, о какой «путаннице» вы говорили.
С этим макросом стиль определения будет чем-то похож на тот, что в Go:
FN((int), int)
=
func(int) int
FN(FN((int, string), float), FN(int) int)
=
func(func(int, string) float) func(int) int
Если я допущу здесь какую-то опечатку или пропущу запятую — не вижу в этом катастрофы. Описана идея, а не исполняемые сниппеты.
Я хотел ответить здесь чтобы любой, кто прочтёт ваш комментарий, не был введён в заблуждение. Нет «ограничения» данной нотации в плане функциональности.
Да, получится то, что вы описывали.
Это, кстати, не самый удивляющий пример.
Без typedef определить функцию, возвращающую функцию, которая возвращает и принимает функцию — вот тут в скобочках и звёздочках нормальные люди начнут «плавать».
Компилятор как раз осилит, а вот мы, люди, такое можем в голове и не удержать. :)
typedef int (*(*fun1)(int))(int);Вот здесь дан очень хороший ответ:
stackoverflow.com/questions/10758811/c-syntax-for-functions-returning-function-pointers
От себя добавлю, что очень помогает
typeof, если он определён компилятором:typedef typeof(typeof(int(*)(int)) (*)(int)) fn2;
// Если нет аллергии на макросы:
#define FN(PARAMS, RET) typeof(RET(*) PARAMS)
typedef FN((int), FN((int), int)) fn3;
Это может быть полезно при работе, например, с сишными библиотеками.
Point в том, что там, где реально нужно использовать арифметику указателей, делать это можно. Тезис «людям не нравится адресная арифметика» не обоснован,
корректнее сказать: «большинству не нравится адресная арифметика там, где можно было обойтись без неё».
P.S. — если кто-то этим воспользуется, стоит мониторить
proposal: spec: disallow T<->uintptr conversion for type T unsafe.Pointer
Это будет выглядеть примерно как в Rust, или, если позволите, «не как в Си».
Вы ведь не придерживаетесь мнения, что для высокоуровневого кода арифметика указателей полезна?
runtime: working with small maps is 4x-10x slower than in nodejs.
По-моему опыт C++ и Rust показывает, что без этого не очень хорошо живётся.
Моё мнение не отражает мнение авторов/сообщества Go, но «Вирусные» возможности языков программирования выглядят менее вероятными кандидатами.
asm0 — MIPS
asm5 — ARM
asm6 — AMD64
asm9 — PPC64
У «go» как названия скорее кучу недостатков можно найти, а не «оправданий», начиная от того, что у поисковиков с «go» не так всё гладко (недавно ещё и «Android Go» появился, который никак с Go не связан), заканчивая тем, что это название уже было занято другим языком программирования.
«golang» в запросах и тегах помогает отбросить неоднозначность, но это костыль.
Возможно такой уже есть, надо искать.
Если хорошо расписать, то какой-то минимальный шанс на значения по умолчанию для структур есть.
Насчёт параметров функций по умолчанию не уверен. Не упаковывал бы
это всё в один proposal.