тут не все однозначно, понятно что если человек senior например на PHP то он и на Ruby худо-бедно, но например сайт напишет, а вот сможет ли он на C драйверы писать это уже вопрос
То есть по сути он будет в написании драйверов ничем не лучше хорошего джуна (его также придется учить), а вот багаж привычек из другой области может и мешать
что-то я видимо не понял примера, у вас оба типа в одном пакете, вы делаете тип usersList, реализация которого выполняется генерацией кода из шаблона который в пакете list получается файлик users_list_gen.go который сохраняется в вашем пакете user. То есть это тоже самое что вы бы сделали usersList с 0, только вам код не пришлось писать
сейчас никто не мешает использовать кодогенерацию для разного рода рутины (например для сериализации/десериализации) и т.п., шаблоны в Go можно делать также, далее абстрактный пример:
в библиотеке объявляете свой тип и в методах его принимаете/возвращаете, там где нужно использовать пишите:
// `template:"github.com/user/mylib.type"`
type myType ...
запускаете генерацию получаете файлик с суфиксом _gen и все работает.
это я не правильно написал — в Rust это try! (статья в тему habrahabr.ru/post/242269/)
ifError в Go у нас было в паре проектов, но так как это не макрос там как раз вариант с panic
в Rust также нет исключений, из плюсов там есть макрос ifError, тоесть
// вместо
if err != nil {
return err
}
// такое
ifError(err)
и я бы не сказал что обработка ошибок в go уж так плоха, у нее есть свои плюсы, если например кто-то наплевал на обработку ошибки, это будет видно во многих случаях. (ну и методы в которых можно ожидать ошибку тоже видно)
а по поводу interface{} — если не секрет, что вы делали что ощутили «не шустрость»?,
в моих кейсах например вместо container/list сделать свой (с указателем вместо Value interface{}) то выигрыш от отказа от интерфейса получается порядка 10-7 на операцию вставки (на получении чуть меньше). т.е. на 10кк элементах выигрыш 1 секунда.
java (dalvik) это платформонезависимый байт код, который выполнится на любом устройстве, в Go нет виртуальной машины и придется создавать исполняемые файл под все платформы (процессоры). Уже есть много софта который написан на java. Ну и грузить все ядра на мобильнике — это только для игрушек и бенчмарков. Так что Go и Java для разного, а вот рассматривать Go как язык для 3D игр очень даже. По сути по скорости он проигрывает C в обработке бинарных данных (например декодирование изображений 2-3 раза) из-за того что все операции в GO проверяются (границы массива и т.п.) и если вы в это упретесь всегда можно написать часть кода на C
опередили с новинками в 1.4
если позволите пару комментариев и дополнений:
— не многопоточный, а параллельно выполняющийся, он планируется в 1 потоке, также для этого в 1.4 запись всех указателей сделали через внутреннюю функцию, которая может эту самую запись блокировать по желанию GC
— Большая часть runtime была переписана на Go, это позволило уменьшить размер кучи от 10% до 30% за счет работы сборщика мусора, а для каждой горутины в 4 раза уменьшить начальный размер стека (с 8192 до 2048 байт), правда к релизу это значение может быть установлено в 4096 байт (имхо так и будет, все таки размер страницы памяти на большинстве систем по умолчанию именно такой)
— приватные пакеты — теперь можно создать пакет который не будет являться частью публичного api, например пакет src/mypkg/internal/foo будет доступен только для пакета src/mypkg. Пока это изменение доступно только для стандартной библиотеки языка, а для сторонних пакетов обещают включить в 1.5
— для стандартизации кодогенерации добавлена команда go generate. При помощи специальных комментариев вы можете указать какие команды необходимо запускать. Но делать как и раньше это придется руками и сохранять созданные файлы в репозиторий пакета (отсутствие автоматического запуска сделано намеренно)
— каноническое название пакета, теперь с помощью комментария рядом с названием пакета можно указать правильный вариант импорта пакета, это поможет избегать дублирования если пакеты импортируются с разными путями (например github.com/my/pkg и my/pkg)
Если вы про iBeacon то нет, он спроектирован чтобы транслировать свой айди, если он будет вещать случайные последовательности байт то какой в нем смысл?
внутри что-то очень напоминающее iBeacon, значит я могу просто ходить с совместимым приложением. Ну и если это так, то проблем идентификации вообще никаких, так как это устройство которое by design транслирует свой уникальный идентификатор
Я правильно понимаю что злоумышленник теперь может найти ребенка из обеспеченной семьи (браслеты я думаю не дешевые) просто пройдя по улицам со смартфоном, и после небольшого наблюдения идентифицировать его в радиусе действия вашего браслета?
А вы судя по разрешениям в android приложении можете определить мой email (аккаунт google), мое местоположение, получать данные о звонках и звонить, читать и писать файлы, менять настройки, записывать звук с микрофона и видео с камеры.
Для меня привычнее когда время на сервере соответствует времени которое я как его администратор вижу на своем компьютере
При этом в приложении пользователь может сам выбрать тайм зону которая привычна ему.
А по поводу смещение со стороны клиента — это еще хуже (уже не 2 места где надо обновлять tzdata, а столько сколько клиентов)
На примере — на телефоне у меня нет обновления для tzdata и системное время я руками ставлю правильное, я создаю на нем напоминание на 10:00 (-4) потом открываю это же напоминание на компьютере и вижу 9:00 (+3)…
ну да только закончилось все тем что браузеры теперь вообще все отрисовывают с помощью gpu. А на тот момент другого способа кроме DirectX задействовать видеокарту не было
не знал, спасибо, интересно тут больше не само удаление, а то что они обещают поставлять базу для всех локалей, но пока компонента Intl все также не дает создать IntlDateFormatter c отличной от «en» локалью.
Из плюсов ситуация как с java здесь получится не должна (хотя кто знает, я уже и не удивлюсь если они скажут что и tzdata будут поставлять с симфони)
То есть по сути он будет в написании драйверов ничем не лучше хорошего джуна (его также придется учить), а вот багаж привычек из другой области может и мешать
в библиотеке объявляете свой тип и в методах его принимаете/возвращаете, там где нужно использовать пишите:
запускаете генерацию получаете файлик с суфиксом _gen и все работает.
вот пример подобного github.com/clipperhouse/gen
ifError в Go у нас было в паре проектов, но так как это не макрос там как раз вариант с panic
и я бы не сказал что обработка ошибок в go уж так плоха, у нее есть свои плюсы, если например кто-то наплевал на обработку ошибки, это будет видно во многих случаях. (ну и методы в которых можно ожидать ошибку тоже видно)
а по поводу interface{} — если не секрет, что вы делали что ощутили «не шустрость»?,
в моих кейсах например вместо container/list сделать свой (с указателем вместо Value interface{}) то выигрыш от отказа от интерфейса получается порядка 10-7 на операцию вставки (на получении чуть меньше). т.е. на 10кк элементах выигрыш 1 секунда.
если позволите пару комментариев и дополнений:
— не многопоточный, а параллельно выполняющийся, он планируется в 1 потоке, также для этого в 1.4 запись всех указателей сделали через внутреннюю функцию, которая может эту самую запись блокировать по желанию GC
— Большая часть runtime была переписана на Go, это позволило уменьшить размер кучи от 10% до 30% за счет работы сборщика мусора, а для каждой горутины в 4 раза уменьшить начальный размер стека (с 8192 до 2048 байт), правда к релизу это значение может быть установлено в 4096 байт (имхо так и будет, все таки размер страницы памяти на большинстве систем по умолчанию именно такой)
— приватные пакеты — теперь можно создать пакет который не будет являться частью публичного api, например пакет src/mypkg/internal/foo будет доступен только для пакета src/mypkg. Пока это изменение доступно только для стандартной библиотеки языка, а для сторонних пакетов обещают включить в 1.5
— для стандартизации кодогенерации добавлена команда go generate. При помощи специальных комментариев вы можете указать какие команды необходимо запускать. Но делать как и раньше это придется руками и сохранять созданные файлы в репозиторий пакета (отсутствие автоматического запуска сделано намеренно)
— каноническое название пакета, теперь с помощью комментария рядом с названием пакета можно указать правильный вариант импорта пакета, это поможет избегать дублирования если пакеты импортируются с разными путями (например github.com/my/pkg и my/pkg)
+ несколько изменений поменьше, подробнее Go 1.4 Release Notes (англ.)
внутри что-то очень напоминающее iBeacon, значит я могу просто ходить с совместимым приложением. Ну и если это так, то проблем идентификации вообще никаких, так как это устройство которое by design транслирует свой уникальный идентификатор
А вы судя по разрешениям в android приложении можете определить мой email (аккаунт google), мое местоположение, получать данные о звонках и звонить, читать и писать файлы, менять настройки, записывать звук с микрофона и видео с камеры.
При этом в приложении пользователь может сам выбрать тайм зону которая привычна ему.
А по поводу смещение со стороны клиента — это еще хуже (уже не 2 места где надо обновлять tzdata, а столько сколько клиентов)
На примере — на телефоне у меня нет обновления для tzdata и системное время я руками ставлю правильное, я создаю на нем напоминание на 10:00 (-4) потом открываю это же напоминание на компьютере и вижу 9:00 (+3)…
Из плюсов ситуация как с java здесь получится не должна (хотя кто знает, я уже и не удивлюсь если они скажут что и tzdata будут поставлять с симфони)