Ну да, имхо, новость должна быть либо про что-то широко известное, либо новость и должна презентовать что-то новое. А тут минорная версия какого-то нового языка и получилось непонятно, чем именно 0.30.2 стала такой примечательной, что удостоилась новости.
не является pure dataflow, это все control-flow с элементами dataflow
Погодите. Я правильно понимаю ситуацию? Вот я говорю, что есть Elixir c GenStage и Flow, которые позволяют реализовывать любую dataflow задачу стабильно, со всеми нужными примочками, обвязками и интроспекцией.
А вы говорите, что этого недостаточно, только потому что он не принуждает вас насильно писать в dataflow-подходе абсолютно всё, включая расчёт чисел Фибоначчи и вывод в консоль? Мне кажется, тут идея идёт уже в ущерб практичности и универсальности.
То, что вы описываете, в целом то и похоже на акторную модель. Акторы так же, как у вас компоненты, запускаются и ждут сообщений. Вы можете запустить определенные акторы, которые должны ожидать сообщений постоянно, а можете при получении потока данных динамически запустить много акторов, которые чисто обработают эти данные и завершатся.
Вопрос только в описании графа перетекания данных между акторами. В целом, можно это сделать в декларативном виде.
И я согласен, что это удобный подход для проектирования системы на верхнем уровне. Под неудобством я имел в виду, что внутренняя реализация акторов как раз является более простым кодом и там уже на каждый чих типа вывести "Hello world" в консоль продолжать думать потоками данных - это уже оверхед.
Концепция интересная: каждая следующая команда имеет на входе результат предыдущей , поэтому вместо обычной записи c(b(a())) можем иметь более наглядную а -> b -> c
Так это обычный pipe-оператор, который является одной из основных синтаксических конструкций в таких языках как Elixir и F#
На том же Elixir есть Flow - библиотека для потоковой обработки. Вот например, как посчитать частоту употребления слов в текстовом документе:
path_to_file
# потоковое чтение из файла
|> File.stream!()
# использовать IO-поток в качестве продьюсера для Flow
|> Flow.from_enumerable()
# разбить каждую строку по пробельным символам
|> Flow.flat_map(fn(line) -> String.split(line, ~r/\s+/) end)
# распараллелить дальнейшую обработку на несколько потоков
|> Flow.partition()
# отфильтровать то, что не является словами
|> Flow.filter(fn(word) -> Regex.match?(~r/^[\w-]+$/iu, word) end)
# выполнить свёртку с подсчётом слов
|> Flow.reduce(fn -> %{} end, fn(word, acc) ->
Map.update(acc, word, 1, fn(count) -> count + 1 end)
end)
# преобразовать в список - реальные вычисления инициируются тут
|> Enum.to_list()
# отсортировать результат по убыванию частотности слов
|> Enum.sort(fn({_w1, count1}, {_w2, count2}) -> count1 >= count2 end)
А как эту же задачу решить на Neva?
P.S. Другое дело, что несмотря на удобство pipe-оператора писать 100% кода только в этом стиле - это неудобно. Поэтому глупо весь язык под это затачивать.
Могу подтвердить, что HRы и нанимающие менеджеры обсуждают почти всегда только gross, так что он имеется в виду по умолчанию.
Сотрудники между собой может и обсуждают "на руки", но мы тут обсуждаем что сказала руководитель команды IT-рекрутинга. К гадалке не ходи, она говорила про gross. Тут вообще без вариантов.
Она написала что это потолок для лида. Откуда следует что там есть выше?
Бывают такие случаи, когда компания не нанимает выше середины вилки.
Ну, раз уж вы выбрали Коми, то вот вам варианты до 5 млн в местной столице на ДомКлик
Понятно, что автор исходного коммента несколько утрировал ситуацию, но и вы зачем-то додумали, что речь про Москву. А Россия за садовым кольцом не заканчивается.
Давайте проверим, только не со слов (не будем опираться на личный опыт), а источником: Хабр Карьера. Результат перед вами.
Хабр Карьера показывает нетто, а в разговорах HR всегда говорят о брутто.
На скриншоте видно, что наибольшее кол-во джунов (80%) попали в диапазон 73.5 - 140 т.р. брутто.
Ну, т.е. корректнее было сказать, что вилка для начинающих специалистов остается в пределах 70-140 т.р. за редким исключением.
Так ли велика проблема, что Анастасия промахнулась на 10 т.р. при размахе диапазона в 70 т.р.? По-моему нет, тем более что от компании к компании, а также от стека (для той же Java диапазон 90-160k gross) это может варьироваться.
Так они ещё и язык специальный придумали, где можно побольше избыточного бойлерплейта генерировать, Golang называется xD
Теперь понятно зачем он такой невыразительный. Чтоб красивые проценты по достижениям нейросетей рисовать.
Надо было вопрос точнее формулировать: Почему её не можно трогать? xD
Вы тут используете риторический приём "ложная дихотомия"
У вас просто нет фокуса на новую деятельность. Поэтому вы вместо продуктивных действий праздно жалуетесь на жизнь в комментариях.
Юзкейсы Симулинка понятны. Но мне показалось, что в случае Neva речь о том, чтобы всё в таком стиле писать.
Ну да, имхо, новость должна быть либо про что-то широко известное, либо новость и должна презентовать что-то новое. А тут минорная версия какого-то нового языка и получилось непонятно, чем именно 0.30.2 стала такой примечательной, что удостоилась новости.
Погодите. Я правильно понимаю ситуацию? Вот я говорю, что есть Elixir c GenStage и Flow, которые позволяют реализовывать любую dataflow задачу стабильно, со всеми нужными примочками, обвязками и интроспекцией.
А вы говорите, что этого недостаточно, только потому что он не принуждает вас насильно писать в dataflow-подходе абсолютно всё, включая расчёт чисел Фибоначчи и вывод в консоль? Мне кажется, тут идея идёт уже в ущерб практичности и универсальности.
Если мы хотим последовательно, то будут последовательно, хотим параллельно - будут параллельно.
Я уже выше приводил пример с Flow. Но можно и ещё проще, например, хотите в 10 параллельных потоков события обработать, вот пожалуйста:
Другими словами, когда надо - распараллеливаете, когда надо - схлопываете снова в 1 поток.
Подробнее о базовых элементах: Task, Stream
И о самом потоковом подходе: GenStage и Flow
То, что вы описываете, в целом то и похоже на акторную модель. Акторы так же, как у вас компоненты, запускаются и ждут сообщений. Вы можете запустить определенные акторы, которые должны ожидать сообщений постоянно, а можете при получении потока данных динамически запустить много акторов, которые чисто обработают эти данные и завершатся.
Вопрос только в описании графа перетекания данных между акторами. В целом, можно это сделать в декларативном виде.
И я согласен, что это удобный подход для проектирования системы на верхнем уровне. Под неудобством я имел в виду, что внутренняя реализация акторов как раз является более простым кодом и там уже на каждый чих типа вывести "Hello world" в консоль продолжать думать потоками данных - это уже оверхед.
Что вы под этим подразумеваете? Pipe-operator?
Так это обычный pipe-оператор, который является одной из основных синтаксических конструкций в таких языках как Elixir и F#
На том же Elixir есть Flow - библиотека для потоковой обработки. Вот например, как посчитать частоту употребления слов в текстовом документе:
А как эту же задачу решить на Neva?
P.S. Другое дело, что несмотря на удобство pipe-оператора писать 100% кода только в этом стиле - это неудобно. Поэтому глупо весь язык под это затачивать.
Да, можно вместо th расслаблено произносить d и носители вас прекрасно поймут.
А в чём смысл этой статьи? Вы хотя бы небольшой обзор языка сделали бы, с примерами и т.д.
Могу подтвердить, что HRы и нанимающие менеджеры обсуждают почти всегда только gross, так что он имеется в виду по умолчанию.
Сотрудники между собой может и обсуждают "на руки", но мы тут обсуждаем что сказала руководитель команды IT-рекрутинга. К гадалке не ходи, она говорила про gross. Тут вообще без вариантов.
Бывают такие случаи, когда компания не нанимает выше середины вилки.
Ну, раз уж вы выбрали Коми, то вот вам варианты до 5 млн в местной столице на ДомКлик
Понятно, что автор исходного коммента несколько утрировал ситуацию, но и вы зачем-то додумали, что речь про Москву. А Россия за садовым кольцом не заканчивается.
Так и есть. 2 месяца назад с ним подобную переписку вёл https://habr.com/ru/articles/855102/comments/#comment_27568354
Смотрю комменты к этой статье, а воз и ныне там(
Так он и не писал про Мск. Например, где-нибудь в Бологое 2 однушки вполне реально взять за год.
Хабр Карьера показывает нетто, а в разговорах HR всегда говорят о брутто.
На скриншоте видно, что наибольшее кол-во джунов (80%) попали в диапазон 73.5 - 140 т.р. брутто.
Ну, т.е. корректнее было сказать, что вилка для начинающих специалистов остается в пределах 70-140 т.р. за редким исключением.
Так ли велика проблема, что Анастасия промахнулась на 10 т.р. при размахе диапазона в 70 т.р.? По-моему нет, тем более что от компании к компании, а также от стека (для той же Java диапазон 90-160k gross) это может варьироваться.
Ну, естественно это джун, а кто ж ещё. Откуда взялась мода думать, что джун - это плохой/некомпетентный сотрудник? Джун - это начинающий специалист.
А почему без опыта? До 2 лет опыта - это тоже джун (начинающий специалист).