Там референс к примеру из статьи, в которой есть фраза «I frequently use in ClojureScript code tricks like» и вообще, Качаев знатный функциональщик, и часто ругает Go, за то что в нём нельзя делать то, что можно в функциональных языках
все же ее наиболее популярный продукт — vagrant, написан на руби, и это не мешает ему «осуществлять революции в серверах»
С vagrant-а начался Hashicorp, Go тогда был ещё в зародыше и Хашимото выбрал наиболее подходящий на тот момент инструмент. Про будущее руби отдельно можно писать, но в целом утверждение «на руби тоже есть клевые серверный софт» никак не противоречит статье :)
Все так, но это источник труднодиагностируемых проблем — к примеру, если в project/ у вас более новая версия пакаджа и вы подразумеваете, что работаете с ним, а на самом деле он берется из первого GOPATH. Или, новый разработчик в тиме, забыл/не понял установить два GOPATH и собирает проект, а код берется не завендоренный, а из его GOPATH. Там много всего может быть, поэтому множественный GOPATH и не рекомендуют в общем случае.
При всём моем (молчаливом) непринятии Rust, вот такие статьи его выставляют только в лучшем свете. Хотя, может, так и предполагалось? Многоходовочка, однако :)
В стандартном expvar, к сожалению, нет uptime, а на кастомные переменные пользователя полагаться и вводить свои стандарты/требования не очень хорошая идея. Хотя, возможно, конечно, добавить эвристику и угадывать по имени «uptime».
Но я хотел максимально простое решение, чтобы даже не переключаться на браузер, не думать какой порт выбрать и так далее. Ну и да — UI там в виде интерфейса сделано, с небольшими усилиями можно и веб-морду сделать — главное фронтенд красивый и аккуратный нарисовать, а это не совсем мое. :)
Собственно, проблема в терминологии здесь в том, что когда говорят «замена C++», подразумевают такой язык, который способен заменить C++ именно в тех областях, где ему пока нет конкурентов — в низкоуровневом программировании
Соглашусь, хотя под «низкоуровневостью» тут имеется ввиду, наверное, контроль памяти? Все таки одна из главных претензий к С++ была именно в том, что слишком большая часть дизайна языка посвящена именно контролю памяти.
Мой же поинт в том, что «драйвера» и по-настоящему «низкоуровневый код» — это достаточно узкая сфера и сводить к ней «нишу С++» не совсем корректно. Прикладной серверный/сетевой софт, который еще 5 лет назад, действительно почти без вариантов стоило писать только на С++, сейчас гораздо эффективнее писать на Go.
Именно поэтому, кстати, практически все новые проекты в SaaS/PaaS маркете пишутся именно на нём.
Я отталкиваюсь от двух вещей, когда говорю про Go как замену С++:
1) Чисто исторический факт, описанный в официальном блоге Golang — язык Go решили создать именно из-за недовольства С++, после внутренней презентации С++0Х.
2) Для меня лично Go стал именно заменой С++. Там где нужна работа с «системой» и производительность — раньше я использовал С++, просто потому что не было приемлимой альтернативы. Go заменил мне С++ полностью: я бы использовал C++ только в продуктах, где необходимо выжимать каждую наносекунду и это в намного большем приоритете, чем скорость разработки или читабельность кода. Во всех остальных случаях, причин писать новые проекты на С++, а не на Go я не вижу.
Поэтому да, с вашим определением «системного языка» как «языка без рантайма» я не согласен.
Весьма распространено заблуждение о том, что Go — это замена C++, в каждом обсуждении Rust кто-нибудь такое говорит. Go — не язык для системного программирования, у них с C/C++ и Rust совершенно разные нишы.
Это не заблуждение. Go родился именно из-за проблем С++ и как замена C++.
Ниши у Rust и Go не абсолютно одинаковые, но во многом пересекающиеся. Подходы разные — Go вырос из практических соображений и опыта, Rust — аккумулирует теоретические достижения PLT.
Вот тут Russ Cox рассказывает про Hindley-Milner, почему это не есть так гуд, как это кажется в теории:
To take one example, Hindley-Milner type inference is very well understood and I think generally accepted in the programming language community as a good feature. But new ML programmers inevitably hit the situation where changing one part of a program causes a mysterious type error in a seemingly unrelated part. The solution is that in practice one writes type signatures for most functions. Hindley-Milner type inference is beautiful research, but it’s not as beautiful in practice. In Go, the only type inference is that if you say var x = e, the type of x comes from e. This rule is simple and predictable and doesn’t suffer from the kinds of “spooky action at a distance” of more complex type inference algorithms. I miss having more complex inference sometimes, but Go’s simple rule handles at least 90% of the cases you care about, with none of the unpredictability or mystery.
Там референс к примеру из статьи, в которой есть фраза «I frequently use in ClojureScript code tricks like» и вообще, Качаев знатный функциональщик, и часто ругает Go, за то что в нём нельзя делать то, что можно в функциональных языках
С vagrant-а начался Hashicorp, Go тогда был ещё в зародыше и Хашимото выбрал наиболее подходящий на тот момент инструмент. Про будущее руби отдельно можно писать, но в целом утверждение «на руби тоже есть клевые серверный софт» никак не противоречит статье :)
Никакого ностальгирования тут нет и в помине.
Но я хотел максимально простое решение, чтобы даже не переключаться на браузер, не думать какой порт выбрать и так далее. Ну и да — UI там в виде интерфейса сделано, с небольшими усилиями можно и веб-морду сделать — главное фронтенд красивый и аккуратный нарисовать, а это не совсем мое. :)
Ваши примеры будут равны:
и
Соглашусь, хотя под «низкоуровневостью» тут имеется ввиду, наверное, контроль памяти? Все таки одна из главных претензий к С++ была именно в том, что слишком большая часть дизайна языка посвящена именно контролю памяти.
Мой же поинт в том, что «драйвера» и по-настоящему «низкоуровневый код» — это достаточно узкая сфера и сводить к ней «нишу С++» не совсем корректно. Прикладной серверный/сетевой софт, который еще 5 лет назад, действительно почти без вариантов стоило писать только на С++, сейчас гораздо эффективнее писать на Go.
Именно поэтому, кстати, практически все новые проекты в SaaS/PaaS маркете пишутся именно на нём.
1) Чисто исторический факт, описанный в официальном блоге Golang — язык Go решили создать именно из-за недовольства С++, после внутренней презентации С++0Х.
2) Для меня лично Go стал именно заменой С++. Там где нужна работа с «системой» и производительность — раньше я использовал С++, просто потому что не было приемлимой альтернативы. Go заменил мне С++ полностью: я бы использовал C++ только в продуктах, где необходимо выжимать каждую наносекунду и это в намного большем приоритете, чем скорость разработки или читабельность кода. Во всех остальных случаях, причин писать новые проекты на С++, а не на Go я не вижу.
Поэтому да, с вашим определением «системного языка» как «языка без рантайма» я не согласен.
Это не заблуждение. Go родился именно из-за проблем С++ и как замена C++.
Ниши у Rust и Go не абсолютно одинаковые, но во многом пересекающиеся. Подходы разные — Go вырос из практических соображений и опыта, Rust — аккумулирует теоретические достижения PLT.