Здравствуйте, vsb, Вы писали:
vsb>Не знаю, что ты не так делаешь. Писать можно и на бейсике, если аккуратно. Это не отменяет минусов языка. Как минимум нужно знать про все расставленные грабли. Нужно помнить, что map передаёт в функцию-маппер не просто объект а ещё и его индекс и исходную коллекцию с какого то фига. Нужно помнить про все особенности parseInt, про то, что в старых браузерах он 010 пропарсит как 8, а в новых как 10, нужно помнить, что parseInt возвращает NaN для ошибок, но не всегда, а только если не смог пропарсить даже первый символ. И куча подобных мелочей. Огромная куча нелогичного контекста.
Скажем, если взять DOM, то таких нелогичностей будет на два-три порядка больше, при чем JS к этому никакого отношения не имеет — все эти грабли вылезут и в С++, если появится желание работать с DOM из С++.
Есть целый сайт, wtf.js, там много нестыковок. Представь, ни одна из них и даже почти все вместе они ничего ровным счетом не означают.
I>>В итоге надо писать своё хеширование. toString или нет, это дело десятое.
vsb>toString это конвертация объекта в строку, а не хеширование.
Я же внятно сказал — надо писать своё хеширование — понятно что это означает ?
toString или нет, это дело десятое — понятно что это означает ?
>В том и беда JS, он постоянно всё подпирает костылями. Если я пишу своё хеширование, я его могу протестировать на данных, улучшить. Я чётко понимаю, как работает это хеширование. Как работает хеширование на toString-е? Это загадка, покрытая мраком. Очевидно только, что в каждом браузере по-разному. Ну и вообще я хочу иметь нормальный toString для отладки. Какое он отношение имеет к хешированию?
У меня ощущение, что тебя ктото запрещает свои методы вводить.
I>>Задачи какие решаешь ?
vsb>Разные задачи. Не понимаю вопроса.
Опиши внятно что за область, обработка звука, вычисления или еще что.
>Ну банально — приходят данные, их надо вставлять в упорядоченный список (например по имени). Если у меня есть дерево, я просто строю дерево по имени и вставляю, операция вставки занимает O(1), всё моментально обновляется. Если у меня нет дерева, мне приходится использовать массив, двоичным поиском искать место для вставки (кстати какая стандартная функция в JS для двоичного поиска?) и впихивать туда элемент, получая O(N) и тормоза.
Ты описываешь какую то свою вычислительную модель. В зависимости от других сведений, которые ты стесняешься сообщить, тебе может сгодиться и образца 80х Бейсик а может быть не хватит и шаблонов С++
I>>Ты лучше про задачу расскажи, а то ты выдаёшь клочки какого то своего решения.
vsb>Я описываю, зачем в стандартной библиотеке любого языка нужны общепринятые коллекции.
Не любого и везде разные. Вот в С++ есть dequee, а в дотнете нет — ужос. Всяких мега-деревьев в дотнете тоже нет — снова ужос.
I>>Это отстой. Ты задачу какую решаешь ? У меня в проекте около 7 мб джаваскрипта и я не наблюдаю тех ужасов, о которых ты говоришь Надо полагать я чтото не так делаю ?
vsb>Не знаю, что ты не так делаешь. Писать можно и на бейсике, если аккуратно. Это не отменяет минусов языка. Как минимум нужно знать про все расставленные грабли. Нужно помнить, что map передаёт в функцию-маппер не просто объект а ещё и его индекс и исходную коллекцию с какого то фига.
И это правильно. Вот есть у тебя функция, которая для элемента i возвращает скажем, усредненное значение по соседним элементам , значение. Покажи как ты применишь не передавая в маппер ни индекс, ни исходную коллекцию.
>Нужно помнить про все особенности parseInt, про то, что в старых браузерах он 010 пропарсит как 8, а в новых как 10, нужно помнить, что parseInt возвращает NaN для ошибок, но не всегда, а только если не смог пропарсить даже первый символ. И куча подобных мелочей. Огромная куча нелогичного контекста.
Чудеса, в JS мизерная стандартная библиотека, в ней три с половиной функции. В дотнете том же сотни классов и в каждом из них есть нелогичности в методах. В джаве — тоже самое. В С++ в принципе более менее нормально.
Берешь в инете любую библиотеку для любого языка и найдешь вагоны нестыковок и их будет на порядки больше, чем в джаваскриптовой полу-библиотете.
С другими языками тебя это не смущает, а в джаваскриптом пугает ажно спать не можешь.
Реальность примерно такая — стандартная библиотека джаваскрипта это 1% необходимого для работы функционала, в ней основные функции это те, что в Array и String. Все юзать не надо — не понимаешь как работает функция — не используй. Не нравится — не используй.
Объяснение простое — для реальной работы в стандартной либе есть 1% необходимого для работы функционала.
Здравствуйте, Ikemefula, Вы писали:
I>Скажем, если взять DOM, то таких нелогичностей будет на два-три порядка больше
Грабли DOM каким-то магическим образом отменяют грабли JS.
I>Есть целый сайт, wtf.js, там много нестыковок. Представь, ни одна из них и даже почти все вместе они ничего ровным счетом не означают.
Бгг. Оver 9000 граблей и целые сайты занимательных wtf ничего не означают, over 9К фреймворков(когда я в послелний раз интересовался я нашёл сотни три, но я не сильно активно искал), так или иначе реализуют "классический" ООП поверх js ничего не означают, over 9K велосипедов(см ссылку выше), что бы писать не на JS а на чём-то другом тоже.
Это называется "хоть плюй в глаза — всё то Божья роса".
Здравствуйте, Yoriсk, Вы писали:
I>>Скажем, если взять DOM, то таких нелогичностей будет на два-три порядка больше
Y>Грабли DOM каким-то магическим образом отменяют грабли JS.
Если ты работаешь с DOM, то у тебя голова в 99% занята вовсе не языком программирования.
I>>Есть целый сайт, wtf.js, там много нестыковок. Представь, ни одна из них и даже почти все вместе они ничего ровным счетом не означают.
Y>Бгг. Оver 9000 граблей и целые сайты занимательных wtf ничего не означают,
Эти "целые сайты", во первых, содержат кучу ошибок, во вторых, слишком часто делают из мухи слона, и, самое главное, показывают одно и то же.
>over 9К фреймворков(когда я в послелний раз интересовался я нашёл сотни три, но я не сильно активно искал), так или иначе реализуют "классический" ООП поверх js ничего не означают, over 9K велосипедов(см ссылку выше), что бы писать не на JS а на чём-то другом тоже.
Ты наверное чего то не понимаешь — JS сейчас самый массовый язык. На нём пишет людей больше, чем на любом из оставшихся языков. Вот какой фокус — сейчас днем с огнем надо искать программиста с опытом, который не знает джаваскрипт и не пишет на нём хотя бы время от времени.
Отсюда растут фремворки — программисты, известно, учиться не любят и больше всего обожают изобретать велосипеды.
Y>Это называется "хоть плюй в глаза — всё то Божья роса".
У меня в данный момент это основной язык, а у тебя только сказки из интернета.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Sharov, Вы писали:
S>>А у каких библиотек, платформ есть легковесные потоки, не считя erlang?
EP>В Rust вроде встроены зелёные потоки.
И всё ? С учетом того, что Rust по большому счету еще никуда не вышел, остаётся только Эрланг.
>А так, наборы "сделай сам" в виде coroutines/fibers есть практически для всех языков — C++, D, Go, Python.
И животноводтство. Если эти вещи использовать один к одному вместо потоков, то Адъ И Израиль гарантирован.
Здравствуйте, vsb, Вы писали:
vsb>Модель обслуживания выбрана спорная. Легковесные потоки по всем параметрам предпочтительней. И работают не хуже, и многопроцессорность можно сделать, и код получается читабельным, а не лапша из коллбэков.
Хуже, намного хуже. Синхронный код давно уперся в потолок. Сейчас софт, который сильно завязан на IO, очень неэффективный, если написан синхронным кодом. 99% времени такой софт занимается ожиданием IO.
25 лет назад IO можно было подождать просто выполняя десяток-другой холостых циклов. Сейчас для ожидания IO надо заводить сервисный поток, ибо холостые циклы это слишком дорого, или делать ожидание унутре основного потока.
Лапшу из колбеков можно устранить многими путями
1. промисы
2. новый стандарт, промисы заменить на короутины и тд
3. язык навроде Coffee или Typescript
Многопроцессорность это ни о чем. node.js нужен там, где мало вычислений и много IO или коммуникации. Они никогда не догонит С++, потому вариант с многопроцессорностью это тупик.
Зато многопроцессорные системы можно и нужно использовать с node.js — эта хрень очень качественно масштабируется. С++ так не умеет.
vsb>ЯП спорный. Сам по себе JS мне очень нравится, но наслоения со времён 90-х, невнятная стандартная библиотека, это всё делает его очень спорным выбором.
У JS есть большой плюс — адски простое метапрограммирование, настолько простое, что даже студенты сами не замечают, как начинают пользоваться.
vsb>Ещё мне понравилось коммьюнити. Очень интересные миниатюрные библиотеки, отличное качество документации. Но это, наверное, не заслуга языка. Поэтому пока интересует исключительно технические плюсы.
Это именно заслуга языка. Сейчас это самый массовый язык, его аудитория намного больше аудитории любого другого языка.
Отсюда следствие — для написания либ полно квалифицированых рук, а не так как в с++ — язык знает много экспертов, а ни одной нормальной либы до сих пор нет.
Здравствуйте, Ikemefula, Вы писали:
I>Хуже, намного хуже. Синхронный код давно уперся в потолок. Сейчас софт, который сильно завязан на IO, очень неэффективный, если написан синхронным кодом. 99% времени такой софт занимается ожиданием IO.
9000 потоков ожидают IO 1000 потоков ждут пока им дадут процессор, 4 потока работают. Что тут неэффективного? Неэффективно тут будет с расходом памяти, если поток идентичен потоку ОС, но если поток легковесный, то он занимает размер такого же порядка, как и размер замыкания для callback-а и в итоге эта модель ничем не хуже. Callback-и это и есть имитация легковесных потоков, только без нормальной поддержки компилятора.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, Ikemefula, Вы писали:
I>>Хуже, намного хуже. Синхронный код давно уперся в потолок. Сейчас софт, который сильно завязан на IO, очень неэффективный, если написан синхронным кодом. 99% времени такой софт занимается ожиданием IO.
vsb>9000 потоков ожидают IO 1000 потоков ждут пока им дадут процессор, 4 потока работают. Что тут неэффективного?
Каждый из этих потоков ест адресное пространство, кучу памяти и вносит общую производительность.
>Неэффективно тут будет с расходом памяти, если поток идентичен потоку ОС, но если поток легковесный, то он занимает размер такого же порядка, как и размер замыкания для callback-а и в итоге эта модель ничем не хуже. Callback-и это и есть имитация легковесных потоков, только без нормальной поддержки компилятора.
Назови такой язык, кроме эрланга, где есть легковесный поток весом в одно замыкания для колбека.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, vsb, Вы писали:
vsb>>Здравствуйте, Ikemefula, Вы писали:
I>>>Хуже, намного хуже. Синхронный код давно уперся в потолок. Сейчас софт, который сильно завязан на IO, очень неэффективный, если написан синхронным кодом. 99% времени такой софт занимается ожиданием IO.
vsb>>9000 потоков ожидают IO 1000 потоков ждут пока им дадут процессор, 4 потока работают. Что тут неэффективного?
I>Каждый из этих потоков ест адресное пространство, кучу памяти и вносит общую производительность.
Если легковесный, кучу памяти не ест и на производительность не влияет.
>>Неэффективно тут будет с расходом памяти, если поток идентичен потоку ОС, но если поток легковесный, то он занимает размер такого же порядка, как и размер замыкания для callback-а и в итоге эта модель ничем не хуже. Callback-и это и есть имитация легковесных потоков, только без нормальной поддержки компилятора.
I>Назови такой язык, кроме эрланга, где есть легковесный поток весом в одно замыкания для колбека.
Go. Весом в одно замыкание он не обязан быть, достаточно веса, приемлемого для практики. 10 килобайтов скажем приемлемо, даже миллион соединений будут занимать всего 10 гигабайтов памяти.
Здравствуйте, vsb, Вы писали:
>>>Неэффективно тут будет с расходом памяти, если поток идентичен потоку ОС, но если поток легковесный, то он занимает размер такого же порядка, как и размер замыкания для callback-а и в итоге эта модель ничем не хуже. Callback-и это и есть имитация легковесных потоков, только без нормальной поддержки компилятора.
I>>Назови такой язык, кроме эрланга, где есть легковесный поток весом в одно замыкания для колбека.
vsb>Go. Весом в одно замыкание он не обязан быть, достаточно веса, приемлемого для практики. 10 килобайтов скажем приемлемо, даже миллион соединений будут занимать всего 10 гигабайтов памяти.
Еще кусочек экзотики. Такие языки будут востребованы, когда легковесные потоки будут поддерживаться в ОС, потому что вся эта лёгкость это на деле фейк.
Кроме того, в браузерах еще долго ничего кроме JS не будет.
Здравствуйте, Ikemefula, Вы писали:
>>>>Неэффективно тут будет с расходом памяти, если поток идентичен потоку ОС, но если поток легковесный, то он занимает размер такого же порядка, как и размер замыкания для callback-а и в итоге эта модель ничем не хуже. Callback-и это и есть имитация легковесных потоков, только без нормальной поддержки компилятора.
I>>>Назови такой язык, кроме эрланга, где есть легковесный поток весом в одно замыкания для колбека.
vsb>>Go. Весом в одно замыкание он не обязан быть, достаточно веса, приемлемого для практики. 10 килобайтов скажем приемлемо, даже миллион соединений будут занимать всего 10 гигабайтов памяти.
I>Еще кусочек экзотики.
Почему экзотики? Вполне практичный язык, как я понимаю. Своё место он уже занял и в ближайшее время никуда не денется.
I> Такие языки будут востребованы, когда легковесные потоки будут поддерживаться в ОС, потому что вся эта лёгкость это на деле фейк.
Легковесность в том числе подразумевает отсутствие переключений контекста. Если ОС переключает множество потоков, выходит довольно большой процент накладных расходов. Какого рода поддержка от ОС нужна? Всё, что нужно для легковесных потоков — планировщик потоков (в программе), вставка определенных инструкций в код в некоторых местах (желательно, чтобы вечный цикл в одном потоке не вешал всю программу) и вызов этого планировщика в библиотечных функциях I/O.
I>Кроме того, в браузерах еще долго ничего кроме JS не будет.
Это относится к серверному софту, браузеру эти вещи ни к чему.
Здравствуйте, vsb, Вы писали:
vsb>>>Go. Весом в одно замыкание он не обязан быть, достаточно веса, приемлемого для практики. 10 килобайтов скажем приемлемо, даже миллион соединений будут занимать всего 10 гигабайтов памяти.
I>>Еще кусочек экзотики.
vsb>Почему экзотики? Вполне практичный язык, как я понимаю. Своё место он уже занял и в ближайшее время никуда не денется.
Практичный это язык который хотя бы в десятке массовых. А язык который появился вчера и у него только местечковое применение это экзотика.
Нравится — пиши на нём, зачем тебе плохой джаваскрипт ?
I>> Такие языки будут востребованы, когда легковесные потоки будут поддерживаться в ОС, потому что вся эта лёгкость это на деле фейк.
I>>Кроме того, в браузерах еще долго ничего кроме JS не будет.
vsb>Это относится к серверному софту, браузеру эти вещи ни к чему.
Ну тогда тебе и джаваскрипт не нужен, пиши на эрланге, там как раз нужные тебе легкие потоки.
Здравствуйте, vsb, Вы писали:
vsb>Go. Весом в одно замыкание он не обязан быть, достаточно веса, приемлемого для практики. 10 килобайтов скажем приемлемо, даже миллион соединений будут занимать всего 10 гигабайтов памяти.
Здравствуйте, Sharov, Вы писали:
vsb>>Go. Весом в одно замыкание он не обязан быть, достаточно веса, приемлемого для практики. 10 килобайтов скажем приемлемо, даже миллион соединений будут занимать всего 10 гигабайтов памяти.
S>миллион соединений операционка не потянет...
Здравствуйте, Ikemefula, Вы писали:
vsb>>>>Go. Весом в одно замыкание он не обязан быть, достаточно веса, приемлемого для практики. 10 килобайтов скажем приемлемо, даже миллион соединений будут занимать всего 10 гигабайтов памяти.
I>>>Еще кусочек экзотики.
vsb>>Почему экзотики? Вполне практичный язык, как я понимаю. Своё место он уже занял и в ближайшее время никуда не денется.
I>Практичный это язык который хотя бы в десятке массовых. А язык который появился вчера и у него только местечковое применение это экзотика.
node и современный JS появился совсем недавно.
I>Нравится — пиши на нём, зачем тебе плохой джаваскрипт ?
Формирую мнение о технологиях, чтобы делать правильный выбор.
I>>> Такие языки будут востребованы, когда легковесные потоки будут поддерживаться в ОС, потому что вся эта лёгкость это на деле фейк.
I>>>Кроме того, в браузерах еще долго ничего кроме JS не будет.
vsb>>Это относится к серверному софту, браузеру эти вещи ни к чему.
I>Ну тогда тебе и джаваскрипт не нужен, пиши на эрланге, там как раз нужные тебе легкие потоки.
Эрланг чересчур чужеродный на мой взгляд. Но свои плюсы у него, конечно, есть. Это уже тема отдельного обсуждения.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, vsb, Вы писали:
S>>>миллион соединений операционка не потянет...
vsb>>Почему?
S>Тут неплохое обсуждение и ссылки полезные.
Ну в итоге всё упирается в память. Никаких проблем обслуживать миллион соединений на хорошем сервере я не вижу, если аккуратно всё написать.
Здравствуйте, vsb, Вы писали:
vsb>Ну в итоге всё упирается в память. Никаких проблем обслуживать миллион соединений на хорошем сервере я не вижу, если аккуратно всё написать.
Здравствуйте, vsb, Вы писали:
>>Практичный это язык который хотя бы в десятке массовых. А язык который появился вчера и у него только местечковое применение это экзотика.
vsb>node и современный JS появился совсем недавно.
Ну да, 15 лет это копейки.
I>>Ну тогда тебе и джаваскрипт не нужен, пиши на эрланге, там как раз нужные тебе легкие потоки.
vsb>Эрланг чересчур чужеродный на мой взгляд. Но свои плюсы у него, конечно, есть. Это уже тема отдельного обсуждения.
Есть только один способ внятно оценить язык — решить на нем какую нибудь важную для тебя задачу. Незачем протаскивать язык в продакшн, что бы оценить выхлоп. Если это много времени, возьми либу из твоей области и посмотри внутрь.
Если либ в твоей области нет, то однозначно ты хочешь чудес.
Надо полагать я чтото не так делаю ?
С учетом того, что Rust по большому счету еще никуда не вышел, остаётся только Эрланг.
