German Jet

Сайт буду просматривать пользователи, и делать всякое разное. он должен быть максимально быстрым.

должен быть максимально быстрым.

Насколько именно быстрым? Не очень понятно чем обуславливаются такие требования. Не исключено что вы занимаетесь преждевременной оптимизацией.

С начала начал писать так:
Сайт на PHP - на который заходили пользователи
Api на С# - который принимал запросы от сайта и отвечал ему.
Но если честно мне в самом начале эта связка не понравилась, не знаю почему.

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

Вообщем я бы писал бы на том языке/фреймворке с которым больше опыта и тут довольно равнозначны php, python, ruby, etc... и может какие-то другие новые вроде Go иди node.js, не суть.

Если хотите скорости то делаете части вашего приложения горизонтально масштабируемыми (то есть например можно запустить 10 копий вашего приложения на разных серверах и архитектура его будет такова что все будет работать нормально).
Плюс как писали тут думать больше не о языке, а об оптимизации базы данных и взаимодействий с ней, кешированием в нужных местах, обычно там самые узкие места.

Сайт буду просматривать пользователи, и делать всякое разное. он должен быть максимально быстрым.

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

Api будет выполнять ресурсоёмкие задания: вычисления, запись из бд в файл и наоборот, и прочие функции которые не выдержит сайт.

API не делает задания. А вычисления и запись из бд в файл - не являются ресурскоемкими операциями в общем случае. Да и сайт их обычно тоже не производит. В таком контексте сайт - это, скорее, фронтенд. А вычисления будут производиться на сервере.

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

Тут вообще не понял. Многопоточность зависит от типа и настроек вебсервера (например, который стоит на nginx-ом). Чем не угодила асинхронность - тоже не понятно. И как она зависит с возможностью обрабатывать много и сразу - так же неясно. Очень упрощенно можно сказать, что с помощью асинхронности можно создать у пользователя впечатление, что сайт реагирует мгновенно (работает очень быстро)

Возможно, это все потому что 3 (4) часа ночи и вы переварили очень большой объем информации. Тогда попробуйте конкретизировать.

Если по существу:
1. Неважно, какой язык выбирать. Тот - который лучше всего знаешь. На любом языке можно реализовать что угодно. Большинство "производительности" достигается не за счет быстродействия стандартной библиотеки языка, а за счет кеширования, оптимизации sql запросов, настройки веб-сервера и базы данных и использования очередей.
2. Видимо, для вас важен вопрос: "Стоит ли разносить API сервера и клиент приложения на разные приложения, языки, инстансы?". Здесь ответить сразу не получится, потому что все зависит от задачи. Смотря как вы будете использовать свои инстансы. Какие вычисления будут проводиться и т.д. - больше конкретики по предметной области.

Инструмент не имеет значения. Главное — уметь решать им задачи. Если бы на ассемблере можно было успешно создавать веб-приложения, то на нём бы их и создавали.
Свои плюсы и минусы есть и у ПХП, и у Питона, и у Руби, и у Go, и у вообще всего. В любом языке программирования можно найти людей, которые скажут, что этот язык полное говно, и даже приведут вполне весомые аргументы. Также можно найти людей, которые скажут, что это идеальный язык, и тоже приведут аргументы. Ну и что с того? Какой толк о того, что говорят другие?
Попробуйте всё, на что хватит времени, и выберете то, что ВАМ больше всего понравится. Ведь это именно ВАМ в будущем целыми днями писать на этом языке код. Если вы решили серьезно этим заниматься, то потратите на это не один год. А зачем тратить время на нелюбимую деятельность?

ПС Те, кто советуют ему начать "с основ", с C и Java, — вы сошли с ума :)

Так быть может стоит взять фреймоврк поменьше? Быть может глянуть в сторону Flask или Bottle они не настолько круты как джанго, но умеют многое :)
Попробуйте и некоторые вещи станут понятными, потом продолжите :)

Laravel, Yii, Phalcon , Symfony - Первые 3 проще изучить. Фалкон самый быстрый пхп фреймворк, в последнее время много заказов на нем. Laravel - пожалуй самый перспективный, но в РФ пока не особо популярен (но это временно) .

Имхо, такой скрипт нужно написать самому.

В PHP все ORM разделяются на 2 класса. Разнятся они основным шаблоном проектирования, взятым за основу, а именно

1. DataMapper (Doctrine ORM (Symfony2), Spot ORM)
2. ActiveRecord (Propel ORM, Eloquent ORM(Laravel), Yii Active Record, Gas ORM, PHPixie)

1 - Sport ORM, Doctrine ORM основаны на Doctrine DBAL который так же можно юзать отдельно, без самой ORM. Doctrine ORM дает немного больше возможности где развернуться и является более сложным и соответственно тяжелым решением, использовать которое для небольших сайтов не имеет особого смысла. ORM такого тип отлично подходят для средних и почти больших сайтов :D

2 - Всё что с ActiveRecord на борту за частую является немного проще как архитектурно так и в обращении. Отлично подходят ORM такого типа для небольших и средних сайтов. При работе с ними любая манипуляция с сущностью это работа с записью в таблице.
ActiveRecord ORM отлично подходит для небольших сайтов.

Для крупных же порталов/сайтов/сервисов на мой взгляд подходит только Plain SQL без большинства наворотов предоставляемых ORM'ками, т.к на них уходит много ресурсов, появляются лишние запросы, много уходит на гидрацию в объекты и т.д.

Для начала - очереди, resque, delayed job, sidekiq

Антон ! Если вы смотрели видеоуроки, читали официальную документацию и вам показалось, что этого мало, то я подозреваю, что скорее всего, вы просто не знаете как правильно делать реализацию Вашей задачи, так сказать некую технологию или подход к реализации.

Рекомендую попробовать вникнуть в данную статью: Знакомство с Yii 2 на основе создания простого блога Если в ней что-то не понятно, то идите в документацию и читайте, что это такое.

Учите английский язык, очень много полезной информации пишут зарубежные коллеги. Не говоря уже о том, что пишут сами создатели framework'a) Зная английский будет легко пользоваться оригинальной полноценной документацией. Хотя документация yii на русском достаточно хорошо переведена.

Учиться тоже тяжело, просто так не получится, надо самому :) Через тысячи ошибок и неудач появляется бесценный опыт и понимание. Удачи.

Привет Skilledpwnz !
Если действительно имеется хорошая база знаний C#, то погрузится в asp.net не должно составить труда, всё таки это всего лишь технология создания web приложений, а не новый язык программирования! :)

На твоём месте я начал бы с изучения архитектуры asp.net, как происходит его работа при исполнении скрипта.
Фундамент заложит хорошее понимание принципов работы клиент-сервер приложений, архитектура и базовые возможности asp.net . Всё остальное придет с опытом.
Естественно информацию я бы брал из хорошей книги от хорошего автора, рекомендую:

• Pro ASP.NET MVC Framework с примерами на c# для профессионалов (Адам Фримен, Стивен Сандерсон)

Не пугайтесь слов "для профессионалов", авторы отлично изложили всю суть и дают достаточно практики для полноценного старта.
Если знаете английский то:

• ASP.NET MVC 5 Fundamentals Scott Allen

Почитайте статью на хабре о новом ASP.NET 5

Придумывайте себе задачи и пытайтесь их воплотить, опыт получается на ошибках. Думаю вы быстро освоите основы через книжку. А там уже раз и ADO.net , кэширование, компоненты .NET, MVC .

Удачи!

Такой стиль называется Flat (плоский дизайн), что подразумевает использование «плоских» элементов, без градиентов, эффектов объёма, фотореалистичности (скевоморфизм) и так далее.

Более осмысленным направлением flat дизайна (подразумевается, более типизированным) является Material Design — так называемый «материальный дизайн» от Google, используемый в новых версиях ОС Android, а также в других продуктах гугла. По нему есть четко задокументированные стайл гайды (style guides), включая типы визуальных компонент и списки рекомендованных цветов (палитр).

можно ли мне собрать команду разработчиков

Можно. Разрешаем. Берете плакат "Ищу разработчиков, готовых работать за еду" и ходите с ним возле бизнес-центров в вашем городе. Абсурдно, да?

Если у вас только идея, но нет профессии, -- вы бизнесмен, и разработчиков вам нужно нанять. Разработчики приносят в проект свое умение производить, а вы -- свой организаторский талант. Если же оного не имеется, у вас не идея, сударь, а мечта. К ней применим совет великого комбинатора "плюнуть на это дело слюной, как плевали еще до времен исторического материализма". Великий комбинатор знатным организатором был, ему можно верить.

Как у вас могла родиться идея сравнивать моджо и рельсы, полная чушь, рельсы и только рельсы. Представления у вас вообще никакого нет.

Если знакомы с питоном, то можно посмотреть видеокурс Python. Уровень 3. Разработка веб - приложений в Django . Если нет, то можно начать с предыдущих уровней (см. плейлисты того же автора). В любом случае полезно читать сайт Django на русском. Очень полезно сразу же начать работать с продвинутой IDE, которая будет помогать во всем. Лично мне очень помог PyCharm Professional Edition. У PyCharm есть 30-дневный триал.