блин, может я неправильно поставил?

так вроде глобально ставил

Ребят, кто-нибудь nginx upstream юзает?)

а что именно ты ставил?

sudo npm i -g mysql

да я понял, что уже что-то не то

через npm ставятся пакеты ноды

это штука для работы с мускулем, а не сам мускуль

советую прочесть https://habrahabr.ru/post/243335/

спасибо)

Всем привет! Вопрос по express: Есть файл, в нем я объявляю роуты след. образом: app.use('/api/v1/:user', require('./routes/actions')); app.use('/api/v1/:user', require('./routes/user')); ну и собственно в файлах ./routes/actions.js экспортирую роутер от экспресса и юзаю как то так: const express = require('express'); const router = express.Router(); router.post('/doAction', myfunction); Ожидается, что для обращения к /doAction я должен обратится по адресу: /api/v1/someuser/doAction, оно так и работает, но почему - то req.params пуст. Можно его как то пробросить в myfunction?

Про over engineering

Отличная статья от мейнтейнера www.devopsbookmarks.com про ряд заблуждений, которые могут привести вас к тому самому состоянию over-engineering'а в вашем проекте, которое мы все всегда стараемся избежать. http://amp.gs/8BUH

Ребят, кто-нибудь nginx upstream юзает?)

ага

Выше писали что только для кеша

думаю все зависит от задачи - если у вас нет больших вычилений в памяти / реалтайм - то нода, если у вас предполагаются вычиления - то нода не подойдет - тк это один процес и ваши вычисления залочат всех, выбирайте java/golang/.netcore и тд

думаю все зависит от задачи - если у вас нет больших вычилений в памяти / реалтайм - то нода, если у вас предполагаются вычиления - то нода не подойдет - тк это один процес и ваши вычисления залочат всех, выбирайте java/golang/.netcore и тд

Вычисления всегда можно в воркеры или корутины вынести.

Вычисления всегда можно в воркеры или корутины вынести.

Можно, но воркер это отдельный процесс, а процесс для ОС это очень ресурсоемкая операция

Их можно держать в памяти и переиспользовать. Я уверен что для этого есть уже модуль

Про over engineering

Любимый пример — фейсбук =).

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

sudo npm i -g mysql

Не делай так.

Их можно держать в памяти и переиспользовать. Я уверен что для этого есть уже модуль

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

Сейчас в @devops_ru начался holly war на любимую тему :)

и да golang все таки лучше для больших систем чем bash

но чем же плох golang для больших систем?

Слишком простой.

а чем же это плохо, быстрое обучение разработчиков, быстрая разработка, простая поддержка, не надо тратить 10 лет как на тот-же С++

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

Нормально она всё считает

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

В JIT вгрохано безумное количество человекочасов

ну очевидно что JIT медленне чем AOT в статически типзированном языке

Зато он in time. Гугли перформанс strftime js против сишного

не смеши

js не может быть быстрее никогда

ну очевидно что JIT медленне чем AOT в статически типзированном языке

Всегда ли? Ну то есть, теоретически.

естетственно. там столько лишних проверок

Ну, это смотря какая статическая типизация ещё.

А если у тебя, например, на вход подаётся мап определённого вида?

jit тоько при пером старте медленней - дальше идет кэширование машинного кода и сишный компилятор - поэтому особой разницы не будет, только первое время работы

ну ребят, умоляю

jit может оптимизировать кусок кода неплохо - но при этом ему придется вставить куча проверок инвариантов

Согласен.

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

Дык, тебе не надо чтобы весь код был быстрый

Тебе надо, чтобы были быстры горячие места

Но статическая типизация в языке не даёт тебе гарантии того, что один и тот же код будет быстрее в нём.

Например, если этот код — это функция, которая по какой-то причине жуёт мап.

Короткий.

она дает максимум возможности для оптимизациии, при этом нет необходимости в деоптимизациях

насчет мапов - ну может быть

Это если форма всех параметров задана строго.

Тогда да.

это и есть статическая типизация)

Нет =)

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

ну дак и в cpp есть virtual те динамическое использование типов, если не так поправьте меня, в этом плане там же тоже должно быть достаточно проверок - точнее поиск по графу объектов, как и в jit

Это уже занудство, конечно.

вобще нужны бенчмарки - так бесполезно)))

ну оно медленнее, естетсвенно

Vitaliy не так, virtual это про виртуальную таблицу, т.е. полиморфизм подтипов

ну там есть indirection, он все замедляет конкретно

возможно это медленнее, чем оптимизированные объекты в v8

но это полиморфизм

ну оно медленнее, естетсвенно

Надо определиться о чём мы говорим. В теории jit может быть быстрее, чем скомпилированный, потому что он знает на каком конкретно проце крутится и может сгенерировать сильно специфичный asm под это. Другое дело, что jit в основном в языках с большой динамикой и там это не сильно помогает.

я говорю про jit в js конкретно

Но при это метапрограммирование никто не отменял и вот тут jit точно впереди.

ERROR: S client not available

jit в js не бывает

бывает jit в реализации

профит от знания конкретного процессора вряд ли имеет значимый вклад

Имеет

влияет - он же инструкции генерит специальные

Зацени компиляцию под какой-нибудь i686 и -native

я имеею в виду что jit в джаве и jit в js - не одно и то же

не могу понять что значит jit в js

По сути одно и то же. hitspot (java) перегоняет байткод в машинный, а crankshaft (v8) — ast в машинный

(немного вру, ибо там не ast, а выхлом от неоптимизирующего компилятора)

ну или msil в ютуе

.net

кстати у .netcore cli появился flag —native копиляцияя сразу в нативный код, интересно бенчмарк глянуть

Почему бы им с блюбердом не договориться и не заменить нативные промисы блюбердом?

bluebird расширяет спеку

и не только - он ей и противоречит

и не только - он ей и противоречит

как?

https://github.com/nodejs/node/issues/6673#issuecomment-218224365

один из примеров

Разве не единственный?

думаю нет

Я просто только про него знаю.

Про порядок срабатывания в некоторых ситуациях.

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

Ммм. Недавно же они говорили что они не оптимизированы потому что потом займутся.

Есть еще один случай: когда что-то сложное можно заменить простым

Например, регексп на поиск подстроки

@vkurchatkin Слушай. По твоему совету решил посмотреть на flow ещё раз (прошлый раз был давно, тогда оно было какое-то очень кривое и дико тормозило).

И знаешь, просто волшебно работает.

знаю)

[ignore] .*/node_modules/.*/test/.*только вписал, а то падало

но иногда приходится шаманить с игнорами, это да

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