Bottle и плагины

он состоит из одного файла — его можно целиком затащить в проект для ради простоты, не нужно никаких зависимостей.

От React до Riot 2.0

Можно обобщить — riot dsl слишком много на себя берет, это очень толстая абстракция. Он не встраивается в JS — он оборачивает его в себя, принося новую сомнительную и ненужную семантику. Это серьезный проигрыш относительно react.

От React до Riot 2.0

Упрощая до предела — вот так:

var CommentList = React.createClass({
  render: function() {
    return this.props.comments.map(function (c) {
      return (<Comment data={c}></Comment>)
    });
  },
});

Фундаментальная ошибка в том, что они сделали yet another templating dsl, в котором есть свои инструкции control flow — в данном случае, each. В react нет никакого способа описать control flow, кроме обычного JS, а jsx — очень тонкий синтаксический сахар. То есть, мой пример абсолютно очевидным образом превратится в следующее:

var CommentList = React.createClass({displayName: "CommentList",
  render: function() {
    return this.props.comments.map(function (c) {
      return (React.createElement(Comment, {data: c}))
    });
  },
});

От React до Riot 2.0

А его я еще не встречал. Теперь погляжу.
Навскидку он как-то менее минималистичен.

От React до Riot 2.0

Любителям минимализма и pure JS рекомендую взглянуть на mithril.js. Он гораздо изящнее и лучше спроектирован.

От React до Riot 2.0

из туториала

<comment-list>
<comment each={ opts.comments } />
</comment-list>

Вот в первом же примере кода видна фундаментальная ошибка авторов, которые не поняли главной фишки jsx. А она именно в том, что это простой синтаксический сахар, а весь control flow описывается строго JS-ом.

Фактически, они как раз сделали то, в чем несведущие люди пытаются обвинять React — они сделали client-side PHP.

Pundle — bundler для python

Да черта с два я им что продам, я ж erlang-разработчик, я же не шарю. :)

Pundle — bundler для python

вы были в каком-то плохом его варианте

Ну, вокруг меня в офисе сидят 6 человек, которые пишут под рельсы и свято верят, что rvm на продакшене — самое то. Я за что купил, за то продал. =)

папка, куда питон пакеты по старинке валят всё что им угодно

Ну, блин. Это претензия уже то ли к самому питону, то ли к setuptools. Везде, где есть питон, есть такая папка, только иногда в нее валят все что попало через sudo.

virtualenv приходилось сносить и ставить всё заново

pip freeze выдает какую-то фигню

Я с этим не сталкивался. pip, конечно, выдает явно больше информации, чем нужно, он в этом плане туповат. Разделять dev-deps от prod-deps неудобно, согласен.
Для упрощения можно было бы добавить ключ --save у pip install, который бы автоматом дописал соответственное package==version в указанный файл — кстати, странно, что его до сих пор нет.

И так ли уж ужасен был опыт с bundler?

Против bundler я ничего пока не имею, и не буду иметь, надеюсь. Страдал я больше от rvm и, увидев pyenv, сразу же это вспомнил. Слишком свежие болезненные впечатления.

Вообще, я против самой идеи ничего не имею. Если реализация будет работать хорошо и без лишней магии — замечательно.

Pundle — bundler для python

а есть где-нибудь уже готовое обобщение фатальных недостатков связки системного python + pip + virtualenv?
я, наверное, недостаточно c ними работал, но вкратце пообщавшись с rvm+bundler решил, что мне они нравятся гораздо меньше. ладно еще в разработке, но в руби-мире принято тащить rvm на production…

и да, если бы мне хотелось на одной машине хостить приложения с разными версиями питона, я бы взял docker.

Анонс React Native

если что, у реакта нет 2-way binding по умолчанию. это чисто view.

Анонс React Native

если мне не изменяет память, они недавно писали в твиттер, что fb работает не просто на react, а еще и на master-е его.

Главное преимущество Go

levgem.livejournal.com/463349.html — хороший пост, из которого понятны возможности интроспекции в erlang-е.

Главное преимущество Go

> «настоящая изоляция процессов»
отсутствие shared memory да и shared state вообще. у каждого эрланговского процесса свой heap, посылка сообщения = копирование.
_{ок, будем честны, shared state есть — ets и refcounted binaries — но он абсолютно не такой, как в других языках и до определенного момента его наличие не имеет никакого значения. проблемы с ets легко выявляются, а эффекты от refc бинарей вы ощутите разве что в реальном хайлоаде, к моменту которого вы уже будете знать, как делать не надо.}

> в нормальной программе на Go тоже вытесняющая многозадачность
там уже реализовали проверку на вытеснение при входе в функцию, как грозились?

> в Go вообще-то есть интроспекция
в erlang-е подцепиться к работающему приложению, хоть к продакшн серверу, и получить массу информации не только о состоянии системы в целом, но и о каждом отдельном процессе — потребление памяти, текущая функция, очередь сообщений, открытые порты — сокеты и файлы. просмотр ets-таблиц туда же. без остановок, на работающем сервере, в динамике.
я не знаю, что считается интроспекцией в go, но явно что-то другое.

Главное преимущество Go

Меня как человека, работающего и с erlang, и c go, очень раздражает, когда их пытаются ставить рядом.

Дело в том, что я точно знаю, что рантайм эрланга превосходит рантайм го в разы — настоящей изоляцией процессов, per-process gc, честным preemptive планировщиком, средствами интроспекции. Да, у него есть свои нюансы под высокой нагрузкой, но они есть везде. На мой взгляд, в крутизне рантайма с ним сейчас вообще ничто не может сравниться, тем более го, с его stop the world gc и планировщиком, недалеко ушедшим от примитивного gevent.

Главное преимущество Go

ну, у меня сегодня просто неудачный день — аналогичная проблема возникла в ревью рабочего кода. =)

Главное преимущество Go

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

ну и вообще, если в языке есть подходящая конструкция(panic-recover), не использовать ее только ради какого-то абстрактного пуризма мне не по нраву. все равно с уровня выше это выглядит абсолютно одинаково.

Главное преимущество Go

Я уже ниже ответил, но повторюсь — вы просто неправильно представляете, о чем я говорю. Там формат контекстно-зависим и линеен.

Сделаем проще. Вот мааленький кусочек кода:

    pic_order_cnt_type := r.Ue()
    if pic_order_cnt_type == 0 {
        r.Ue() /* log2_max_pic_order_cnt_lsb_minus4 */
    } else if pic_order_cnt_type == 1 {
        r.U(1) /* delta_pic_order_always_zero_flag */
        r.Se() /* offset_for_non_ref_pic */
        r.Se() /* offset_for_top_to_bottom_field */
        num_ref_frames_in_pic_order_cnt_cycle := r.Ue()
        for i := uint32(0); i <num_ref_frames_in_pic_order_cnt_cycle; i++ {
            r.Se() /* offset_for_ref_frame[ i ] */
        }
    }

где r.Ue() — чтение exp-golomb encoded числа, r.Se() — exp-signed golomb, а r.U(n) — чтение n бит. Все это — чтения нефиксированной длины, одно пропущенное чтение может сломать следующее чтение exp-golomb кода. А может не сломать, просто прочитается что-то не то. И такой if там не один.

Короче, нет, не работает тот метод. Только panic-recover.

Главное преимущество Go

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

нормальная идея, но не всегда применима.

Главное преимущество Go

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

я сам не мог привести примера лучше.

Главное преимущество Go

Не, не только для исключительных. Есть, например, парсер H264 SPS, где на BitReader-е последовательно примерно 30 раз вызываются 4 разных метода, из которых 2 точно могут вернуть ошибку и непременно вернут, если ты пропустил хотя бы одно чтение перед ними.

30 if-ов — нет уж, увольте, я выбираю плохую практику.