Это уже зависит от прямоты рук Android-разработчиков. На Nexus 4 вроде работает Ok. Возможно, они тестировали на малом количестве устройств.
К фронтенду и другие претензии есть. Например, совершенно неочевидный способ менять яркость и размытость фона. И неочевидность перехода в настройки. Скорее всего, поправят в будущем. В целом, минимализм радует.
Не знаю, выглядит сомнительно. Нет отзывов у продавца, вес посылки вообще 1 кг написан. Тем более что другие продают по обычным ценам. Скорее всего развод.
В Китае, кстати, полно таких велосипедов на дороге:
Скрытый текст
Стоят от 5 до 10 тыс. руб.
Причем, ездят на них, в основном, рабочие — перевозят что-нибудь.
А еще много таких штук продают:
Но на дороге видел такое только один раз в Шанхае.
Scrooser, конечно стильная вещь, но Zumaround Kick Scooter кажется более удобным в использовании. Если бы складывался, было бы еще лучше. В таких вещах важно соотношение дальность хода-компактность.
Сомневаюсь, что человек в должности Sr Software Architect, который написал книгу о Ruby (изд. O’Reilly), активный участник Ruby-сообщества, контрибьютор, и спикер на различных конференциях, «фигово» пишет на Ruby.
Хоть язык и задумывался как замена C/C++, но на него стали переходить люди с Python, Ruby. Прежде всего, с ними и сравниваю. По удобству разработки и порогу входжения они сравнимы, но Go дает дополнительные преимущества.
По поводу поиска языка, советую искать «Golang».
Действительно C многое напоминает. Вот, например, описание пакета fmt:
Package fmt implements formatted I/O with functions analogous
to C's printf and scanf.
По поводу маленькой и большой буквы (main / Println), тут есть объяснение. То, что с большой буквы — экспортируется. См. объяснение в тексте статьи.
По поводу кавычек в импортируемом пакете. Точно не уверен, но возможно это связано с тем, что можно делать алиасы к пакетам. Написать, например, так import myfmt "fmt" и использовать в коде вместо fmt — myfmt.
Приведенный пример с NewField очень простой. Если немного набить руку, все читается просто, там применяются стандартные вещи и сокращения.
Сборщик мусора накладывает некоторые ограничения на сферы использование языка. В частности, в приложениях реального времени его использовать не стоит.
Go, конечно, не быстрее C (может только чуть-чуть и только в особых случаях). Но в реальных веб-приложениях порядки такие. Скорость генерации веб-страницы будет в разы/десятки быстрее. Но, опять же, смотря с чем сравнивать.
Вот человек переписал с Ruby на Go свой API и получил 50-кратный прирост — My simple web API is 50X faster....
Посмотрите мой пример с ошибкой ApiError. Я реализую метод .Error(), что автоматически означает, что ApiError соответствует стандартному интерфейсу error. И там, где ожидается error, я могу передать свою ApiError.
Да, многие решения были приняты как раз исходя из малого размера проекта. Возможно, для более крупных проектов и есть смысл использовать фреймворк. Либо какое-либо внутреннее соглашение о структуре кода и т. п.
По поводу замечаний.
1. Да, язык системный и служит для разных целей. Можно придерживаться best practice или соглашений.
2. Пакеты подключаются в любом файле. Решил использовать роуты и все что к ним относится в main из-за небольшого размера проекта.
3. То же самое, проект небольшой.
4. а) Да, тоже думал над этим. Можно было для контроллеров сдлеать middleware который бы автоматически подключался и отключался от бызы, но хотелось бы чтобы модели были независимы от контроллеров.
По поводу пункта б. Не могли бы пояснить что вы имели ввиду? Создание нового поста отдельной функцией models.NewPost()? Если да, то это принятый в языке способ.
в) Опять же, в силу малого размера проекта, валидация простая. Часть валидации берет на себя структура данных, т.е. вы не сможете сохранить стоку в поле с типом int. Часть критичной валидации (без которой пост не сохранится, например не передали id) проверяется в модели, возвращая ошибку. Остальное, если нужно проверяется в контролере. Но этих проверок мало. С одной стороны кажется что все разбросано по разным местам, но определенная логика в этом есть. Методы модели, например, можно использовать не только из контроллеров, а отдельно внутри (для тех же тестов, например). В более серьезных проектах правила валидации задаются тегами в структуре данных. Несомненно, это более правильный подход.
К фронтенду и другие претензии есть. Например, совершенно неочевидный способ менять яркость и размытость фона. И неочевидность перехода в настройки. Скорее всего, поправят в будущем. В целом, минимализм радует.
Стоят от 5 до 10 тыс. руб.
Причем, ездят на них, в основном, рабочие — перевозят что-нибудь.
А еще много таких штук продают:
Но на дороге видел такое только один раз в Шанхае.
По поводу поиска языка, советую искать «Golang».
Действительно C многое напоминает. Вот, например, описание пакета fmt:
По поводу маленькой и большой буквы (main / Println), тут есть объяснение. То, что с большой буквы — экспортируется. См. объяснение в тексте статьи.
По поводу кавычек в импортируемом пакете. Точно не уверен, но возможно это связано с тем, что можно делать алиасы к пакетам. Написать, например, так
import myfmt "fmt"и использовать в коде вместо fmt — myfmt.Приведенный пример с NewField очень простой. Если немного набить руку, все читается просто, там применяются стандартные вещи и сокращения.
Go, конечно, не быстрее C (может только чуть-чуть и только в особых случаях). Но в реальных веб-приложениях порядки такие. Скорость генерации веб-страницы будет в разы/десятки быстрее. Но, опять же, смотря с чем сравнивать.
Вот человек переписал с Ruby на Go свой API и получил 50-кратный прирост — My simple web API is 50X faster....
По поводу замечаний.
1. Да, язык системный и служит для разных целей. Можно придерживаться best practice или соглашений.
2. Пакеты подключаются в любом файле. Решил использовать роуты и все что к ним относится в main из-за небольшого размера проекта.
3. То же самое, проект небольшой.
4. а) Да, тоже думал над этим. Можно было для контроллеров сдлеать middleware который бы автоматически подключался и отключался от бызы, но хотелось бы чтобы модели были независимы от контроллеров.
По поводу пункта б. Не могли бы пояснить что вы имели ввиду? Создание нового поста отдельной функцией models.NewPost()? Если да, то это принятый в языке способ.
в) Опять же, в силу малого размера проекта, валидация простая. Часть валидации берет на себя структура данных, т.е. вы не сможете сохранить стоку в поле с типом int. Часть критичной валидации (без которой пост не сохранится, например не передали id) проверяется в модели, возвращая ошибку. Остальное, если нужно проверяется в контролере. Но этих проверок мало. С одной стороны кажется что все разбросано по разным местам, но определенная логика в этом есть. Методы модели, например, можно использовать не только из контроллеров, а отдельно внутри (для тех же тестов, например). В более серьезных проектах правила валидации задаются тегами в структуре данных. Несомненно, это более правильный подход.