import "sort"
type Person struct {
Name string
Age int
}
func SortPeople(pp []Person) {
sort.Slice(pp, func(i, j int) bool { return pp[i].Age < pp[j].Age })
}
А вообще, если вас интересует выразительность, то да — python более выразительный. На нем можно меньше печатать. Но у меня, например, большая часть времени не набор кода уходит, а на его проектирование. Так go еще и быстрее python работает.
А простота нужна когда приходят новые люди в проект, особенно если они новички. Погружение в код быстрее происходит. (имхо)
За то вызовет обработчик панику или нет, должны отвечать тот кто пишет сам обработчик и тот кто передает обработчик в шину. Так например, для сервера из net/http все обработчики тоже неродные, но никаких recover в нем нет.
Для реальной разработки в go сейчас уходят от go get всех пакетов. Собираются включить dep в стандартный набор утили, когда это будет неизвестно, но его уже сейчас можно использовать. (ну либо аналоги). Все они используют как указатель версии пакета тэги в SemVer. В таком случае калечащие изменения должны выкатываться под новой major версией. А менеджер зависимостей не должен сам major обновления применять.
Горутины являются такими легковесными благодаря тому что известны места, где может произойти смена контекста. Естественно, что прервать её выполнение в любом месте не выйдет. Можно использовать контекст и периодически проверять не отменили ли задачу.
>> Консоль надо купить, комп уже есть практически у всех.
Смартфон есть у всех. А вот стационарный ПК далеко не у всех. Большинству нужно только интернет посерфить, для этого планшеты есть, максимум ноутбуки. А покупать его только для игр, так дешевле консоль купить и работать лучше будет.
1. При отправке сообщения отправляющая рутина зависает только в случае небуферизированного канала. Если же создать канал с заданным рамером, то она может зависнуть только при его переполнении.
2. С помощью библиотеки runtime можно контролировать смену контекста. Ну в зацикливающиемся приложении вина не на языке.
Ниже привели примеры. Если посетить сайты данных проектов, то можно увидеть, какие крупные компании ими пользуются.
Все так говорят, пока проект не погряз в копипасте.
Знаете, за чуть менее чем десяток немалых проектов на Go я копировал только один файл с функциями для логирования и делал я это только потому, что считаю это незаслуженным для отдельного пакета. Возможно, мне повезло.
Давайте потестим, выбирайте поле для битвы :-)
Думаю для проверки эффективности корутин/каналов следует написать что-то такое http://play.golang.org/p/XX9uhAPUB9
Не знаю насколько результаты будут отражать действительность.
В Go есть встроенные решения для unit тестирования и бенчмарков. Не принято создавать пэкэдж для 1 функции.
Просто неясно, почему нужно перейти с Go на D. Корутины в D работают, судя по всему не так хорошо и просто как в go. Неизвестно насколько они дешевы. Могу ли я вместо использования паттерна Worker'ов использовать порождение корутин?
Кстати, есть ли в D какая-то замена кросс-компиляции? Вещь на самом деле удобная и нужная.
Есть ли опыт успешного применения в больших проектах в продакшене?
Да и вообще есть ли большие проекты на D?
Обобщенный код — это, конечно, удобно, но как показала практика не необходимо.
Я не говорил, что это ключевой фактор. Но решив написать на D, я рискую не найти либы для какого-нибудь специфичного протокола, например Diameter. При этом не вижу серьезных причин, почему качество репозиториев на D должно быть лучше.
Как я понял, в D происходит запуск рутины, проверка наличия данных в канале и смена контекста, если нет. В Go рутина при чтении из канала и в случае отсутствия данных в нем добавляется в очередь на чтение из него. И потом, при появлении в канале данных, рутина отправляется в очередь на запуск. Ну и так далее. Select же добавляет в несколько очередей на чтение из каналов. И при отсутствии секции default планировщик запусти рутину только в случае наличия данных в одном из каналов.
То есть Select реализуется простым перебором? Получается, что мы крутим вечный цикл с проверкой не пришло ли нам чего-нибудь?
Как-то много смен контекста может выйти и очень сильно выжирает проц, думаю. В Go же запустить рутину или нет решает планировщик. Что весьма удобно. Выходит, что корутины на D потяжелее горутин.
Идея в том, что бы каждый платил только за свое потребляемое электричество. Те кто пользуются микроволновкой не будут платить за электромобиль другого. Просто владелец электромобиля будет потреблять больше энергии => больше платить.
Эммм. Неообходимость и росскошь. А какое дело властям до того, куда я трачу электроенергию. Это их не должно заботить. Ибо если у меня есть деньги на такую "Росскошь", то я, скорее всего, отвалил неплохой такой подоходный. Такими темпами вообще можно сказать, что включать свет больше часа до и после светового дня — росскошь, ибо спать надо. Смартфон, который ежедневно заряжать надо — росскошь и т.д.
Кстати, передвигаться на работу и с работы — это вполне себе вынужденная вещь и купить для этого электромобиль ничем плохим не является.
Просто нужно построить станции, не производящие CO2, а то нашли способ: не самим развиваться, а возможности людей ужимать.
А вообще, если вас интересует выразительность, то да — python более выразительный. На нем можно меньше печатать. Но у меня, например, большая часть времени не набор кода уходит, а на его проектирование. Так go еще и быстрее python работает.
А простота нужна когда приходят новые люди в проект, особенно если они новички. Погружение в код быстрее происходит. (имхо)
Так же стоит заметить, что recover повсюду не есть хорошая практика.
Смартфон есть у всех. А вот стационарный ПК далеко не у всех. Большинству нужно только интернет посерфить, для этого планшеты есть, максимум ноутбуки. А покупать его только для игр, так дешевле консоль купить и работать лучше будет.
2. С помощью библиотеки runtime можно контролировать смену контекста. Ну в зацикливающиемся приложении вина не на языке.
Ниже привели примеры. Если посетить сайты данных проектов, то можно увидеть, какие крупные компании ими пользуются.
Знаете, за чуть менее чем десяток немалых проектов на Go я копировал только один файл с функциями для логирования и делал я это только потому, что считаю это незаслуженным для отдельного пакета. Возможно, мне повезло.
Думаю для проверки эффективности корутин/каналов следует написать что-то такое http://play.golang.org/p/XX9uhAPUB9
Не знаю насколько результаты будут отражать действительность.
Просто неясно, почему нужно перейти с Go на D. Корутины в D работают, судя по всему не так хорошо и просто как в go. Неизвестно насколько они дешевы. Могу ли я вместо использования паттерна Worker'ов использовать порождение корутин?
Кстати, есть ли в D какая-то замена кросс-компиляции? Вещь на самом деле удобная и нужная.
Есть ли опыт успешного применения в больших проектах в продакшене?
Да и вообще есть ли большие проекты на D?
Обобщенный код — это, конечно, удобно, но как показала практика не необходимо.
Как-то много смен контекста может выйти и очень сильно выжирает проц, думаю. В Go же запустить рутину или нет решает планировщик. Что весьма удобно. Выходит, что корутины на D потяжелее горутин.
Кстати, передвигаться на работу и с работы — это вполне себе вынужденная вещь и купить для этого электромобиль ничем плохим не является.
Просто нужно построить станции, не производящие CO2, а то нашли способ: не самим развиваться, а возможности людей ужимать.