Ну, где использовать Rust и я не знаю (ибо он до сих пор не стабилен). А Go хорош тем, что у него отличная инфраструктура (система пакетов и так далее), искаропки он отлично работает с сетью в том числе с http и всякими вебсокетами, он легко интегрируется с Си (то есть он понимает сишные хедеры сам и не нужно биндинг писать совсем), у него хорошая скаробочная система сборки ну и он все же статически типизирован.
Соответственно мы в нашем проекте его используем на серверах для написания различных сервисов/демонов которые что-то там общаются по сети, пережевывают данные (частично пережевывание делается сишной либой) и шлют куда-то дальше. Демоны мелкие получаются в плане объема исходников — единицы тысяч строк кода, ну может быть десяток.
В результате это все пишется довольно легко и быстро (сетевое взаимодействие так вообще очень приятно писать), если что-то где-то шлепается, то шлепается с осмысленной диагностикой. Утечек памяти нет. Да, ну и до кучи в качестве бонуса имеем отличную кроссплатформенность — написанное работает и под линуксами, и под OS X и под виндой. Иногда бывает очень полезно иметь возможность развернуть систему на том что есть под рукой, локально. Да, и работает оно тоже весьма быстро и не тащит за собой какие-то там интерпретаторы да виртуальные машины.
Естественно если писать что-то большое (сотни тысяч строк кода) и требовательное к ресурсам, то, на мой взгляд, нужно брать какой-нибудь С++ (просто потому что на таких объемах работ мелкие геморрои вроде систем сборки, сборки сторонних либ руками под данный дистр и так далее уже не играют какой-то особой роли, а вот вопросы производительности (в том числе полный контроль за менеджментом памяти) и наличие тех же шаблонов — уже будут играть).
map еще. Массивы то ладно, а вот map (на самом деле это аналог unordered_map) штука не тривиальная и её тем не менее пришлось зашить прямо в язык. При этом если нужен аналог обычного С++ map, то нужно уже лепить руками контейнер с динамической типизацией (interface{}), что весьма неудобно.
Ну оно так и было :-) До версии 1.5 (ака J2SE 5.0).
Причем это было не так и давно — 2004 год. Напомню что java вышла в 1995 году. То есть 9 лет язык был без дженериков или чего-то подобного. 9 лет так вот страдали с Object'ами в коллекциях.
Сторонняя реализация java с дженериками (называлась Generic Java) была создана в 1998 году. Подробней об этом здесь: en.wikipedia.org/wiki/Generics_in_Java
Хотя, помимо соображений скорости, я не сильно вижу, чем решение с реализацией интерфейсов (как в btree, к примеру) явно лучше шаблонов.
Ну вот и я не вижу чем решение с реализацией интерфейсов явно лучше шаблонов :-) Будем считать что у нас тут консенсус, и решение с шаблонами будет полюбому лучше :-)
Просто давайте откровенно — реализация generics — это всегда slowdown либо компилятора, либо рантайма
Эмм… Нет. То есть если шаблоны разворачиваются на этапе компиляции, то да, компилятору нужно будет делать дополнительную работу в случае если шаблоны используются (если не используются, то скорость будет та же). Если не разворачивать на этапе компиляции (как это в java сделано), то в рантайме накладных расходов дополнительных тоже не будет — то есть их будет не больше чем при ручном приведении и проверки типов.
Ну и да — из личного опыта — мне не приходилось упираться в «отсутствие generics». Вообще. Никогда. Объясните, что я делаю не так? Какой тип софта я должен начать писать, чтобы упереться в это? Без сарказма вопрос.
Похоже что у нас сейчас неявно идет (или вот-вот начнется) спор на тему динамическая типизация VS статическая типизация. Со всеми стандартными аргументами с обоих сторон. Поэтому предлагаю не повторяться, а просто нагуглить один из подобных споров и насладиться чтением :-)
Поэтому я не буду далее говорить о преимуществах и недостатках той или иной типизации, в конце концов про это неоднократно говорилось.
Дженерики и шаблоны — это статическая типизация, interface{} — динамическая. Вот и все. Если активно используется interface{} и нет от этого никакого дискомфорта, то данный проект с тем же успехом данный программист может писать и на питоне (но, видимо, не на js — в Go таки даже для interface{} типизация строгая (равно как и в питоне), а на js — слабая).
В Go имеем некое половинчатое решение, для встроенных типов (типа того же map) имеем статическую типизацию, а для рукописных типов контейнеров (типа того же btree) — только динамическую. Что вызывает некий когнетивный диссонанс при использовании и не добавляет концептуальной целостности языку. В общем, как в том анекдоте «вы или крестик снимите, или трусы наденьте».
Если бы я хотел писать данный проект на динамически типизированном языке, я бы взял python. А Go был выбран, кроме всего прочего, в том числе из за статической типизации (и дело тут не в скорости исполнения приложения).
PS. На самом деле Go это как минимум третий язык который на стадии своего развития проходит через фазу «работаем пока без шаблонов/дженериков» — вначале в java не было дженериков, затем в C#, но все современные статически типизированные языки общего назначения так или иначе дженериками все же обзаводятся (в том или ином виде — у java и C# они сильно разные).
PPS. Если не секрет, а на чем вы писали до Go? Какими еще языками пользуетесь?
Ну, прежде всего конечно же не хватает возможности использовать (и создавать!) нормальные типизированные контейнеры. То есть без этого настолько неудобно, что просто ой. Кроме того, довольно глупо тратить время во время работы приложения на проверку типов элементов в контейнере, если мы на этапе компиляции и так знаем что там все будет однотипно. То есть тут шаблоны бы еще и ускорили работу приложения.
А еще, если бы в Go была бы не только RTTI, но и CTTI… То всякие сериализации работали бы просто на порядок быстрее… Эх, мечты, мечты… :-)
Ну, о чем я собственно и написал (например тот же llvm это умеет, но это не значит что llvm тебе дает даром GC — нет там GC, GC надо писать отдельно). Но это все сильно проще чем собственно сам GC.
И, насколько я помню, у Go был (в версии 1.0 что ли) как раз консервативный сборщик мусора. Сейчас сборщик уже другой.
Кстати, сборщик мусора это ж не часть компилятора, а часть рантайма языка (да, для некоторых типов сборщика мусора нужна некая минимальная поддержка со стороны компилятора, но это мелочи). Соответственно каким боком реализация GC и рантайма имеет отношение к тому на каком языке компилятор писан?
И правильно ли я понимаю, что теперь и рантайм Go будет полностью на самом Go, что приведет к еще бОльшей просадки производительности приложений относительно приложений на Си?
PS. Посмотрел в changelog — бОльшую часть рантайма на Go переписали уже в 1.4:
As mentioned above, much of the runtime was translated to Go from C, which led to some reduction in heap sizes. It also improved performance slightly because the Go compiler is better at optimization, due to things like inlining, than the C compiler used to build the runtime.
видимо они рантайм собирали каким-то уж совсем диким Сишным компилятором (у них там вроде бы есть свой компилятор Си), который не умеет нормальную оптимизацию.
В общем вывод — если хочется скорости, то gccgo наше всё!
Ну, вообще с этим Bluetooth 4 полная путаница. Ну например в спеках на смартфоны с Win 8 давным давно светится что оно держит Bluetooth 4.0, при этом они естественно никакого BLE не умеют (просто потому, что винда мобильная научилась с BLE работать только с версии 8.1). С андроидами долгое время была та же песня (то есть чип унутре то может и умел что-то с BLE, но вот операционка ничего не могла, и соответственно пользователю, равно как и разработчику, ничего доступно не было).
Большая часть чипов умеют и то и это. Более того, многие чипы умеют одновременно работать и с ble устройствами и с bluetooth (например в iPhone стоит такой — он может и с гарнитурой работать и одновременно с ble устройством). Но понятно что одно и то же соединение одновременно не может быть и ble и обычным.
Чтобы была понятна область применимости ble: типичная пиковая пропускная способность у ble в реальной жизни порядка 1 килобайта в секунду (8 кбит). Например для гарнитуры, для передачи голоса во вменяемом качестве, этого уже не хватит.
BLE это отдельная штука, не совместимая с «обычным» Bluetooth, там в общем то и не поддерживаются обычные Bluetooth профили и так далее. Писать приложение под BLE нужно отдельно и иначе, железяку делать соответственно тоже.
То есть BLE это не опция для экономии энергии, это отдельная технология передачи данных сильно отличающаяся от традиционного Bluetooth.
ну, у TI их CC2541 вроде как умеет таки по воздуху обновляться (то есть bluetooth стек можно обновить. в теории). Другое дело насколько этот чип и эти возможности задействованы в конечных устройствах, ну и будет ли вообще Bluetooth 4.2 для этого самого CC2541.
Самое время привести основную мысль статьи. Примитивным стандартным типам не место в интерфейсах реальной системы. Такие типы — просто строительные блоки, из которых нужно именно строить, а не пытаться жить внутри.
Да, и в Аде с этим (созданием пользовательских типов на базе примитивных типов) все значительно лучше чем в С++, поэтому они там повсеместно используются, и базовых типов обычно действительно в интерфейсах пакетов не видно. Просто потому, что создать свой тип — это одна-две строчки. Ну и вообще, не принято там использовать базовый Integer какой-нибудь.
И это то, чего в С++ действительно не хватает. Хотя можно конечно извратиться, и попробовать сделать аналог на шаблонах. Будет более громоздко конечно, но хоть как-то.
Человек, который прошёл игру на easy, как правило, совершенно не приспособлен к сетевой игре. У него такая хорошая выученная беспомощность — 8-12 часов игры научили его совершенно не тому, что нужно в «реальном» бою с живыми игроками. Никаких попыток подумать — просто напролом и всё.
Это не выученная беспомощность, это отсутствие навыков.
А выученную беспомощность можно заработать как раз играя на уровне сложности hardcore или выше. Особенно если эти уровни сложности не проработаны как надо. Вот что такое выученная беспомощность: asena.livejournal.com/575273.html
Выученная беспомощность — это вот что. Вот у вас есть собака, которую вы сажаете за загородку и бьете там электрическим током. Нормальная собака рано или поздно догадывается, что через загородку можно перепрыгнуть, чтобы ток прекратился. А вот собака, которую до этого уже били током в таких условиях, когда ей было некуда выпрыгнуть, даже не попытается это сделать. Она ляжет на пол и будет скулить.
Проблема не в токе. Проблема в неконтролируемости среды. В отсутствии логической связи между твоими действиями и реакцией окружающего мира. Если реакция всегда положительная, это тоже деморализует. Те, кто привык к неконтролируемости среды, довольно быстро оставляют всякие попытки на нее влиять. Людей в экспериментах обычно током не бьют, им просто дают заведомо нерешаемую головоломку — после того, как они какое-то время над ней побьются, у них резко снижается способность справляться с решаемыми головоломками.
Соответственно мы в нашем проекте его используем на серверах для написания различных сервисов/демонов которые что-то там общаются по сети, пережевывают данные (частично пережевывание делается сишной либой) и шлют куда-то дальше. Демоны мелкие получаются в плане объема исходников — единицы тысяч строк кода, ну может быть десяток.
В результате это все пишется довольно легко и быстро (сетевое взаимодействие так вообще очень приятно писать), если что-то где-то шлепается, то шлепается с осмысленной диагностикой. Утечек памяти нет. Да, ну и до кучи в качестве бонуса имеем отличную кроссплатформенность — написанное работает и под линуксами, и под OS X и под виндой. Иногда бывает очень полезно иметь возможность развернуть систему на том что есть под рукой, локально. Да, и работает оно тоже весьма быстро и не тащит за собой какие-то там интерпретаторы да виртуальные машины.
Естественно если писать что-то большое (сотни тысяч строк кода) и требовательное к ресурсам, то, на мой взгляд, нужно брать какой-нибудь С++ (просто потому что на таких объемах работ мелкие геморрои вроде систем сборки, сборки сторонних либ руками под данный дистр и так далее уже не играют какой-то особой роли, а вот вопросы производительности (в том числе полный контроль за менеджментом памяти) и наличие тех же шаблонов — уже будут играть).
Причем это было не так и давно — 2004 год. Напомню что java вышла в 1995 году. То есть 9 лет язык был без дженериков или чего-то подобного. 9 лет так вот страдали с Object'ами в коллекциях.
Сторонняя реализация java с дженериками (называлась Generic Java) была создана в 1998 году. Подробней об этом здесь: en.wikipedia.org/wiki/Generics_in_Java
Ну вот и я не вижу чем решение с реализацией интерфейсов явно лучше шаблонов :-) Будем считать что у нас тут консенсус, и решение с шаблонами будет полюбому лучше :-)
Эмм… Нет. То есть если шаблоны разворачиваются на этапе компиляции, то да, компилятору нужно будет делать дополнительную работу в случае если шаблоны используются (если не используются, то скорость будет та же). Если не разворачивать на этапе компиляции (как это в java сделано), то в рантайме накладных расходов дополнительных тоже не будет — то есть их будет не больше чем при ручном приведении и проверки типов.
Похоже что у нас сейчас неявно идет (или вот-вот начнется) спор на тему динамическая типизация VS статическая типизация. Со всеми стандартными аргументами с обоих сторон. Поэтому предлагаю не повторяться, а просто нагуглить один из подобных споров и насладиться чтением :-)
Поэтому я не буду далее говорить о преимуществах и недостатках той или иной типизации, в конце концов про это неоднократно говорилось.
Дженерики и шаблоны — это статическая типизация, interface{} — динамическая. Вот и все. Если активно используется interface{} и нет от этого никакого дискомфорта, то данный проект с тем же успехом данный программист может писать и на питоне (но, видимо, не на js — в Go таки даже для interface{} типизация строгая (равно как и в питоне), а на js — слабая).
В Go имеем некое половинчатое решение, для встроенных типов (типа того же map) имеем статическую типизацию, а для рукописных типов контейнеров (типа того же btree) — только динамическую. Что вызывает некий когнетивный диссонанс при использовании и не добавляет концептуальной целостности языку. В общем, как в том анекдоте «вы или крестик снимите, или трусы наденьте».
Если бы я хотел писать данный проект на динамически типизированном языке, я бы взял python. А Go был выбран, кроме всего прочего, в том числе из за статической типизации (и дело тут не в скорости исполнения приложения).
PS. На самом деле Go это как минимум третий язык который на стадии своего развития проходит через фазу «работаем пока без шаблонов/дженериков» — вначале в java не было дженериков, затем в C#, но все современные статически типизированные языки общего назначения так или иначе дженериками все же обзаводятся (в том или ином виде — у java и C# они сильно разные).
PPS. Если не секрет, а на чем вы писали до Go? Какими еще языками пользуетесь?
А еще, если бы в Go была бы не только RTTI, но и CTTI… То всякие сериализации работали бы просто на порядок быстрее… Эх, мечты, мечты… :-)
И, насколько я помню, у Go был (в версии 1.0 что ли) как раз консервативный сборщик мусора. Сейчас сборщик уже другой.
И правильно ли я понимаю, что теперь и рантайм Go будет полностью на самом Go, что приведет к еще бОльшей просадки производительности приложений относительно приложений на Си?
PS. Посмотрел в changelog — бОльшую часть рантайма на Go переписали уже в 1.4:
видимо они рантайм собирали каким-то уж совсем диким Сишным компилятором (у них там вроде бы есть свой компилятор Си), который не умеет нормальную оптимизацию.
В общем вывод — если хочется скорости, то gccgo наше всё!
Вот тут есть списочек оборудование которое точно работает через BLE: www.bluetooth.com/Pages/Bluetooth-Smart-Devices-List.aspx
А вот тут описание что же это за значки такие загадочные «Bluetooth smart» и «Bluetooth smart ready»: www.bluetooth.com/Pages/Bluetooth-Brand.aspx
Собственно вот на эти значки, по хорошему, и нужно смотреть при покупке дивайсины.
Чтобы была понятна область применимости ble: типичная пиковая пропускная способность у ble в реальной жизни порядка 1 килобайта в секунду (8 кбит). Например для гарнитуры, для передачи голоса во вменяемом качестве, этого уже не хватит.
То есть BLE это не опция для экономии энергии, это отдельная технология передачи данных сильно отличающаяся от традиционного Bluetooth.
Да, и в Аде с этим (созданием пользовательских типов на базе примитивных типов) все значительно лучше чем в С++, поэтому они там повсеместно используются, и базовых типов обычно действительно в интерфейсах пакетов не видно. Просто потому, что создать свой тип — это одна-две строчки. Ну и вообще, не принято там использовать базовый Integer какой-нибудь.
И это то, чего в С++ действительно не хватает. Хотя можно конечно извратиться, и попробовать сделать аналог на шаблонах. Будет более громоздко конечно, но хоть как-то.
Это не выученная беспомощность, это отсутствие навыков.
А выученную беспомощность можно заработать как раз играя на уровне сложности hardcore или выше. Особенно если эти уровни сложности не проработаны как надо. Вот что такое выученная беспомощность: asena.livejournal.com/575273.html