Все семейство языков борланд погибло, еще до этого погибли все семейство dbase, php тихо гибнет, c# и java агонизируют и будут страдать долго, я надеюсь c# выживет после полного перерождения, потому, что синтаксис языка очень хорош, а вот все дерьмо майкрософтовское вокруг просто ужасно, сейчас он становится более открытым, исходники вот публикуют, должен выжить, ну а java это ужасное болото бюрократии, и захолустье духа, в котором утонет любое хорошее начинание.
fshp и Мак Алексей: я 20 лет программирую, писал на asm под x86 процы и даже на машинном коде под контроллеры моторола, dbase, clipper, delphi, cbuilder, c#, php, java, это только те языки на которых долго и активно писал, разработал свою СУБД типа монги когда это еще не было меинстримом в 1999 году еще, свой сетевой протокол RPC в 2000, свой формат сериализации типа json, свои domain-specific языки программирования, веб сервера, долго занимался системным программированием под win и linux, и про типизированные языки и фп знаю достаточно, чтобы адекватно их сравнивать, и вот после всего этого я говорю Вам - JS это один из лучших языков, которые я видел в своей жизни.
Впечатление от JS, что это язык с низким уровнем входа обманцивое. Anhedonia: JS один из лучших языков по гибкости и красоте, но только в умелых руках, потому, что это сложнейший язык и большая часть тех, кто на нем пишет, не понимают ни концепции и мощи языка ни смысла ими самими написанного.
Для ноды есть сервера приложений, которые позволяют запустить 100 сайтов в одном потоке, а точнее N сайтов в M потоков. Не нужно будет иметь много ядер и не будет расхода памяти на переключение контекстов.
Если есть алгоритм, который будет вычисляться целую секунду без асинхронных вызовов, то это завесит процесс ноды на секунду и она не примет входящих событий, если конечно не разрывать алгоритм, отдавая управление из его середины в event-loop при помощи nextTick, setImmediate или setTimeout. Но не все алгоритмы можно вот так разорвать. А если это сервер, каждый запрос к которому вызывает долгие вычисления, то это уже беда, их нужно будет вынести в С++ код, который гораздо быстрее и в котором можно реализовать многопоточность в рамках одного процесса. Но между основным кодом на ноде и кодом на С++ придется делать копирование памяти, связанное с их синхронизацией.
Такого, чтобы все было собрано в одном месте - нет, везде 99% ересь. Если будете писать на node.js, то не напоритесть на middleware, ибо сказано: все, что Node.js дал, все middleware отберет. Вот тут я толкую этот достоверный хадис: Какие библиотеки использовать для высоконагруженного приложения в Node.js? Лучше всего не использовать дополнительных библиотек для построения API, а писать все самому. Я для своих задач написал достаточно универсальное решение, но оно не подойдет для всех и является экстремистским как по форме, так и по содержанию: habrahabr.ru/post/247543 Тем не менее, в его коде можно найти много полезного, берите - дарю. И да поможет Вам Аллах!
Александр Прозоров: Фигасе, не заметил, разве я так учил, что вот это ...`id`="+id+"... я спрашиваю? Или вот это if(row==false) что это такое за говнокодище? Ану все переписать аккуратненько! )))
Я про оба случая говорю, и когда много пользователей и когда много файлов у одного, это крайние случаи одной задачи, с обоими встречался. Когда миллионы файлов, это конечно не пользовательские файлы были, а один раз логи телеметрии, а другой раз документы (решения судов), но не важно. Мы же не можем обезопасить себя от того, что человек захочет залить на сервер те же логи или документы. А много пользователей - тут уже без вопросов нужно генерировать хеш от имени, а то и на папки делить, даже уникальные логины дают хуже скорость доступа.
Это для маленьких объемов данных, а когда это сервис для миллионов человек, то ничего подобного не происходит. В этом конкретном вопросе, скорее всего можно сделать как попало, и ни кто никогда не столкнется с проблемами.
Если пользователи начинают создавать папки, то очень много папок выходит, у каждого свое дерево, а так одно на всех, сбалансированное для быстрого доступа, так хранят свои кеши многие сервера, например nginx.
У Вас бывало 13 млн файлов в каталоге? А 2 млн каталогов по 3 файла? Большинство ФС плохо справляются с оптимальным хранением таких структур, а в природе они встречаются. Переименование файлов в хеш от содержимого или в хеш от времени или в рандомное имя - помогает ФС построить не вырожденный ключ по имени и очень ускоряет потом доступ. Есть конечно специализированные ФС, которые сами все это делают, например ZFS, о чем я сказал.
Потому, что в этой задаче нужно делать не шаблоны и байдинг, а Rich UI, множество форм, гридов, комбобоксов, и т.д., нужен развитый набор контролов. По структуре мне больше нравится webcomponents.org но он еще не так развит, как предложенные.
Ото погодите, я доберусь написать про развертывание прикладного облака на ноде из 5 машин и 10млн открытых сокетов с сообщением по каждому сокету раз в 10сек.
