German Jet

но код, особенно после C++, не вызывает каких-то положительных эмоций.

А у меня не вызывает положительных эмоций код на C++. Да и код разный бывает. 90% кода на PHP у меня так же не вызывают положительных эмоций, но писать на нем нормально более чем можно.

1) под фразой "php умирает" позразумевает его модель работы. После каждого запроса он умирает, то есть воркер отчищается и запускается по сути заного. Это существенно упрощает работу (у вас хоть сегфлоты могут быть всеравно весь сервак не умрет), а так же масштабирование (за счет отсутствия у самого PHP состояния между запросами, сессии мы не берем в расчет), но существенно бьет по производительности. К счастью с PHP 5.3 писать демоны на PHP не так уж страшно.

Если же посмотреть рынок и динамику развития сообщества - PHP живее всех живых.

2) PHP не такой уж стремный язык. Я не считаю "не консистентные названия функций" таким уж прям фактором влияющим на выбор языка. С моей точки зрения Ruby уродливая отрыжка, попытка сделать объектно-ориентированный перл (это лично мое мнение, мне не приятно работать с ruby, пусть меня за это простят), но за счет того, насколько сообщество ruby-разработчиков ценит и понимает цели бизнеса, насколько уважает тестирование своих решений и т.д... словом PHP комьюнити в этом плане еще расти и расти. Но прогресс виден.

Да у языка есть просчеты, но их потихоньку сглаживают и устраняют проблемы.

3) нет. Шансов на нормальном уровне с нуля изучить еще один язык программирования и к тому же фреймворк - почти нет. Да и в этом нет смысла.

4) судя по вопросу вы уже определились для себя. Дальнейшая дискуссия не имеет смысла. Разбирайтесь. Но если брать шаред хостинги то PHP это пожалуй единственный адекватный вариант на сегодняшний день (если не брать в расчет что шаред хостинги как таковые это не очень адекватный вариант).

5) все зависит от вас. Хорошие разработчики зарабатывают примерно одинаково вне зависимости на каком языке программирования они работают. Они просто хорошие разработчики и таких всегда мало.

6) как хотите.

И так...

Язык программирования - это лишь инструмент для решения задач. Фреймворки - это так же просто инструменты для решения задач. Что важно - уметь задачи решать. И решать эффективно. Понимать что кривыми решениями вы увеличиваете риски для бизнеса.

Изучение языка программирование - это лишь десятая часть того, чем нужно владеть. При должном опыте вы сможете найти общие концепции, переносить знания с платформы на платформу, абстрагироваться от конкретных реализаций в контретных фреймворках и т.д.

Ruby например бизнес (и стартапы в особенности) выбирает не потому что это хороший язык, а потому что Ruby комьюнити в среднем больше приспособлено для эффективного решения задач бизнеса. Что говорить когда у них любовь тестирования прививают с первых дней знакомства с языком?

Не учите язык программирования. Учитесь разработке с применением этого языка. И тогда все будет намного проще.

p.s. Haters gonna hate

Как это работает, чтобы понимали. Я опишу истинно правильный путь, но долгий: (как подсказал pygame , по бенчмаркам https://gist.github.com/hgfischer/7965620 всё же нативный хттп сервер в Go быстрее, чем nginx с fcgi, т.к. у Go гавняная реализация fcgi, поэтому вместо fcgi быстрее будет обычный http proxy_pass).

1) Ставится веб-сервер нормальный, а не тот, который есть в самом Go. То есть, ставим nginx. Настраиваем ему все url маршруты, настраиваем отдачу статики.

2) За динамикой nginx будет обращаться к нашему Go демону. По протоколу fast-cgi. Именно по нему, потому что nginx его умеет и вообще он хорош (upd: но не в Go). Это короч бинарный протокол по которому nginx передаёт в нашу Go программу HTTP заголовки запроса от браузера и получает обратно HTTP ответ. Для этого ставим простейшую обёртку для fast-cgi под названием spawn-fcgi, она будет преднастраивать и запускать нашу Go программу, готовую для общения по протоколу fast-cgi.

3) На случай, если наша Go программа падает. Либо уже у нас есть система, которая следит за демонами и поднимает их в случае падения (systemd, upstart), тогда конфигурируем её, либо ставим таковую и тоже конфигурируем.

Привожу пример как это всё сделано у меня (самый популярный стек технологий) на Debian:

1) nginx

server {
	server_name otboi.****;
	listen 80;
	include fastcgi_params;
...
	
	location / {
		fastcgi_pass unix:/var/run/otboinik.sock;
	}

2) systemd конфиг, который стартует нашу Go программу, завёрнутую в spawn-fcgi

[Unit]
Description=Otboinik

[Service]
Restart=always
Environment=OTBOINIK_BIN=/opt/гыы/otboinik/bin/otboinik
Environment=OTBOINIK_PID=/var/run/otboinik.pid
Environment=OTBOINIK_USER=гыыыы
Environment=OTBOINIK_SOCKET=/var/run/otboinik.sock
Environment=OTBOINIK_SOCKET_USER=гыыыыы
Environment=OTBOINIK_SOCKET_MODE=0666
ExecStart=/usr/bin/spawn-fcgi -s $OTBOINIK_SOCKET -M $OTBOINIK_SOCKET_MODE -n -P $OTBOINIK_PID -u $OTBOINIK_USER -U $OTBOINIK_SOCKET_USER -G $OTBOINIK_SOCKET_USER $OTBOINIK_BIN

[Install]
WantedBy=multi-user.target

3) Сам Go код

import (
	"net/http"
	"net/http/fcgi"
)

type Server struct {
}

func (s Server) ServeHTTP(w http.ResponseWriter, r *http.Request) {
       // чиста пример
        jsonblob := r.FormValue("events")
	if jsonblob == "" {
		w.WriteHeader(http.StatusNotAcceptable)
		return
	}
}

func main() {
	server := Server{}

	func() {
		fcgi.Serve(nil, server)
	}()

	waitchan := make(chan int, 1)
	<-waitchan
}

Не важен путь, который выберете вы. Важно то, как вы его пройдете.
Самообразование - ключ к любой профессии. Никто и никогда вас не станет ничему учить. Забудьте об этом, все только сами.
Как, по-вашему люди из самых запдрыпанных мест становятся великими? Трудом.
Учитесь тому, что интересно. Хотите GameDev? Без проблем. Сейчас осень, впереди зима и весна. Садитесь за Java или Swift. Напишите к лету приложение и разместите его в магазине. Будет настоящий незаменимый опыт. Потом еще и еще. Не сразу, но начнете на этом зарабатывать. Было бы желание, остальное приложится.
И к экзаменам тоже можно подготовиться. И сдать их на отлично самому. Не смотрите на ленивцев вокруг. Они вас кормить не станут. Они так и дальше будут сосать пиво из бутылочки и сидеть на шее у родителей до последнего.
Или вы тоже хотите пойти на стройку, чтобы зарабатывать на пиво? Тогда вперед.

При явном указании города нет смысла фильтровать по стране и штату, при явном указании штата нет смысла фильтровать по сране. Код может выглядеть примерно так (у меня, понятно, нет возможности проверить):

location = form.cleaned_data
city, state, country = location['city'], location['state'], location['country']
kwargs = ({'city': city} if city
   else ({'state': state} if state
   else {'country': country} if country))
data = Model.objects.filter(**kwargs)

Все это не отменяет необходимости на клиенте фильтровать список городов при выборе страны/штата.

Самое сложное во фрилансе, не языки и технологии.

• Умение продавать себя в толпе конкурентов. Это самое сложное. Есть много высококлассных специалистов, сидящих на среднем окладе. Они тупо не могут себя продать даже в другую компанию, а не редко и боятся менять привычное место.
  
• Умение грамотно составить или согласовать ТЗ. Так что бы проблема заказчика решалась в оговоренные сроки и бюджет. А не перерастала в вечнострой с кучей доделок и переделок с базовым бюджетом. Когда обе стороны уже ненавидят друг друга. Ибо работая в офисе разработчиком, всё это ведут менеджеры и тим лиды, а вам спускают конкретные задачи. Вам же придётся научиться понимать, что хочет клиент, не разбирающийся в программировании, говоря то или это. Научиться понимать и предлагать те решения, которые будут ему актуальны с учётом технологий и отказывать в том, что сделать не реально. Находить компромиссы, но опять же, объясняя почему так или иначе.
  

Самое лучшее для фрилансера, да и любого разработчика. Это большие и долгие проекты. Когда можно постоянно заниматься одним. А не вникать каждый раз по новой, не привыкать к новому заказчику. Да, тут есть шанс отупения и застоя в развитии, но это лечится средними своими проектами или доп работой небольшой. Хотя, если проект живой и развивающейся, руководство ищет способы развития бизнеса и само заинтересованно в росте. Тогда можно и на текущем проекте развиваться, пробуя новые технологии, службы, стеки. Это будет рост как специалиста.

А технологии, языки. Это уже второстепенно. Главное развиваться. Ибо в попсовом PHP можно делать большие проекты и быть специалистом с большой стоимостью часа или на редком python/java сидеть и быдлокодить мелочь за копейки. Главное не метаться, а развиваться и расти, беря более сложные и более длинные проекты. И брать их не с "поддержкой", а с возможностью постоянного развития. Задачи "в стол", не интересны. А вот задачи на перспективу, на развитие. Это уже интересно. Ибо "в стол" это как правило теория(придумали, сделали, забыли). А развивающиеся, это практика на реальных условиях, когда в процессе приходится много менять (менять бизнес модель, менять архитектуру из-за возросших нагрузок, менять технологии).

Я рекомендую изучать JS примерно таким путем:
– чтение learn.javascript.ru (чтение и, естественно, практика);
– параллельное прохождение модулей по JS на codeschool;
– держите перед глазами актуальные вопросы для собеседования JS-разработчика (habrahabr.ru/post/239065/), стараясь на них ответить;
– читайте хороших авторов: Дуглас Крокфорд, Джон Рейзиг, Стоян Стефанов;
– найдите на GitHub людей, которые согласятся ревьюить Ваш код, я серьезно!

Ну и не забывайте: чем чаще Вы пишите код, тем лучше получается; чем сильнее стараетесь разобраться в основах языка, тем легче будут даваться в освоении фреймворки и паттерны.

Желаю успеха!

Вообще первое, что я посоветую - забыть на время про программирование и учить английский. Для понимания большинства книг тебе будет достаточно уровня Intermediate (B1, словарный запас 2-3 тысячи слов + общее понимание грамматики). Ибо все равно без английского ты достаточно быстро замучаешься. Точнее скажу, ты замучаешься при первой попытке погуглить любое нетривиальное решение возникшей проблемы (ибо многие подходящие решения будут объяснены по-английски на StackOverflow и подобных сайтах). Ну и при возникновении ошибок в ходе выполнения программы интерпретатор тоже будет "ругаться" по-английски. Если ты никогда не учил английский, пару лет на это уйдет, если заниматься не слишком интенсивно. Если взяться интенсивно, можно и за год, в принципе, достичь этого. Это не совсем просто. Но оно того стоит, 100%.

После этого можно идти на coursera и записываться на курс для новичков по интересующему тебя ЯП. Например, для питона это что-то такое. Ну необязательно, конечно, coursera, есть и другие образовательные сайты (пример) - тут уже гугл тебе в руки.

Просто без знания английского ты всегда будешь позади на пару лет: книги пишутся и переводятся на русский небыстро. Ну и как я уже сказал выше, уже средние знания английского сильно облегчат твою дальнейшую жизнь в смысле поиска решений в Сети. Это не зависит от выбранных технологий - такая же ситуация будет и с Java, Ruby, Go и любыми другими ЯП.

Разумеется, можно параллельно учить английский и читать книги по питону. На этот случай тебе уже присоветовали книги. Я бы рекомендовал начать с Доусона. Книга Лутца, конечно, более универсальная, но уж очень она подробная для начала: можно и запутаться в таком объеме информации (хотя ничего действительно сложного там нет). Еще для быстрого старта подойдет эта книга. Но английский все равно в первую очередь учить, без него беда.

Ну и в качестве лирического отступления. Я бы лично задумался на твоем месте: а нужно ли мне вообще программирование (безотносительно к питону)? Ибо если тебе быстро становится скучно уже во время изучения основ и хочется убыстрить процесс обучения... Ну вряд ли дальнейшее обучение будет в радость. Программирование вообще-то не самый веселый и разнообразный процесс. Особенно нудно проходит отладка, вылавливание ошибок в программах. Я сам, хоть и не программист по образованию, неоднократно тратил долгие часы и дни в поиске трудноуловимых ошибок в уже написанной программе. Нередко бывало, что процесс тестирования программы занимал в разы больше времени, чем, собственно, написание кода. И это вполне типичная ситуация, независимо от ЯП. А уж когда ты выучишь, наконец, более-менее синтаксис любого языка и начнешь углубляться в алгоритмы - тут уже веселья вообще будет минимум. А вот внимательности, педантичности и настойчивости потребуется немало.

Поэтому если уж ни в какую не хочется тратить долгие месяцы на изучение английского и одновременное изучение синтаксиса языка программирования, введения в алгоритмы и т.п. - займись чем-то другим.

CapeRatel:

Сообщество живое русское есть где нибудь?

Язык программирования Go
Русскоязычный подкаст о Go

Я честно говоря его пока не вижу, этого "будущего мэйнстрима".
Ясно что Ruby on Rails потихоньку устаревает.
Почти весь мэйнстримный вспомогательный инструментарий сейчас разрабатывается под Node.js: gulp, bower, babel, postcss (ещё не мэйнстрим но видимо будет). Опять же почти весь вспомогательный инструментарий RoR, который когда-то был либо мэйнстримом (SCSS, Compass), либо задавал тон в индустрии (Sporckets, Coffeescript) сейчас начинают выглядеть анахронизмом на фоне тех же gulp, postcss и babel + ES6. То есть по части инструментария однозначно рулит Node.js. Но это инструментарий.
В ту же копилку вэбсокеты, по части которых нода - эаталон, а RoR всё никак их толком не внедрит (вроде в 5 версии хотят). Есть Faye, штука неплохая, но слишком заметно что чужеродная для RoR.
Ещё один плюс ноды - возможность изоморфного рендернига контента для SPA. Но тут уже вопрос в языке, понятно что ни на чём другом кроме JS это не реализуешь.
В общем RoR конечно большинство основных новых веяний в индустрии благополучно прозевал и постепенно превращается в резервацию со своей атмосферой. Нода на передовой НО только по всякой вспомогательной части, сопоставимого по масштабу фреймворка на ней как не было, так и нет.
Всё остальное (Go и т.д.) ещё настолько сыро, что даже обсуждать по-моему нечего.

Всё про расширение модели пользователя - https://docs.djangoproject.com/en/1.8/topics/auth/...
Тут как сделать такой же виджет как в админке для m2m поля www.dangtrinh.com/2014/01/django-use-django-admin-...