Русскоязычное сообщество Revel Framework на ЛОРе

подпишусь таки на тхреад

чем он лучше других фреймворков?

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

Даёшь обсуждение на родном языке!

давай

你好! ^_^

И как же :

Revel покинул, его не предлагать.

Отлично!
Хочу с вами проконсультироваться на выходных

чем он лучше других фреймворков?

Всё субъективно.

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

Чем отличается разработка на go от разработки на ruby и php? Очевидно, go - статически типизируемый, компилируемый. Большая часть ошибок должна отлавливаться на этапе компиляции. В отличии от php не умирает после каждого запроса. В отличии от ruby, сервер, роутинг, шаблонизатор и прочее - часть стандартной библиотеки go. Конечная производительность выше, по крайней мере, чем у ruby точно. Порог вхождения - умеренный, чужой код - читаемый даже для новичков. Особенно, если все следуют style guide'у и используют gofmt. Готовые библиотеки есть, будь то websockets или ещё что-то подобное; хоть и меньше, чем под какой-нибудь node.js. На вскидку, всё что пришло в голову.

И как же

Личное. Проблема решена.

OK. Я подписался на тег revel. Буду отвечать во всех темах.

Всё субъективно.

Ну было бы неплохо все же рассказать, почему стоит использовать именно revel, а не какой-нибудь martini :-)

Я не сильно осведомлён о целях проекта Martini.

Задачами Revel фреймворка же являются масштабируемость, продуктивность, расширяемость. Опыт использования, в большей степени, должен быть схож с разработкой на Play!, Rails, Django. На первый, собственно, и оглядывался автор при создании Revel.

По умолчанию, из шаблона генерируется базовое приложение с предопределенной структурой (как в Play!). Что позволяет сразу приступить к разработке бизнес-логики. При этом, любой компонент фреймворка может быть расширен. Не нравится принцип работы сессии, i18n, flash, валидации, gzip и т.п. -> переопределяем. В противном случае, не заморачиваемся по поводу их существования, делаем things that matter.

Расширяемость (типы компонентов): фильтры, интерцепторы, модули. Из первого состоит сам фреймворк. Пример - сессия или i18n. Второе схоже, наверное, с middleware. Например, auth. Третье - готовые приложения. Пример модуля - testrunner. Используется для запуска интеграционных тестов через браузер (по-умолчанию, включен в dev mode). Или static - используется для просмотра статических файлов.

Масштабируемость. Как пример, cache. По умолчанию хранит все данные в памяти. Необходимость устанавливать какой-то дополнительный софт - отсутствует. Пишем бизнес логику себе на здоровье. Для production окружения - можно указать данные (или ENV VARS) для подключения к (кластеру) memcached / redis. И вот, тот же самый бинарник без всяких изменений хранит данные не в памяти инстанса revel приложения, что имеет ряд недостатков, а в memcached / redis.

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

Вот, спасибо.

расскажи пжлста за орм, есть ли аналог алхимии?

Если не ошибаюсь для ssdb и redis есть адаптеры

Обновите там наконец пути к подрепозиториям.

code.google.com/p/go.net -> golang.org/x/net

https://golang.org/doc/go1.4#subrepo

активный пользовать revel'а

Ссылки на проекты?

Насколько разработка отличается от C++?

Revel всё ещё следует принципу «bring your own ORM». А вообще, из существующих:

• gorp (ORM подобная библиотека)
• gorm
• hood
• qbs
• jet
• beego.orm (говорят, что написали под влиянием Django ORM и SQLAlchemy)
• xorm

Для ssdb есть, для redis - вагон и маленькая тележка (на оффсайте советуют radix /адептам минимализма/ и redigo).

Больше месяца как https://github.com/revel/revel/pull/796

Принципиально, чтобы это мои были? Они для внутреннего использования. А вообще, для проектов недавно была создана страница в вики (revel/revel). Называется Apps in the Wild. Авторы могут добавлять свои. Собственно, там можно посмотреть на примеры использования.

Не сильно знаком с разработкой под web на C++. Но отличаться должна сильно. Всё таки, в go - сборщик мусора имеется, скорость компиляции совсем другая. Всё необходимое, будь то роутер, шаблонизатор, сервер или ещё что-то, уже в комплекте. Сторонних компонентов достаточно, ибо порог вхождения умеренный. В конечном итоге, продуктивность разработки под web на go должна быть на порядок выше, чем на C++.

Сборщик мусора замедляет работу программы (но ручное распределение памяти требует аккуратность). Скорость компиляции для меня не важнее производительности конечной программы. Стандартная библиотека хоть и не содержит шаблонизаторы и серверы (там это действительно не нужно, я считаю), но эти проблемы решаются подключением сторонних, таких как WebTookit. Учитывая все это нельзя не согласиться с Вами о низкой продуктивности разработки, хотя есть и некоторые оговорки, например: возможность подключить сборщик мусора.

Не, если C++ тебя полностью устраивает, используй его, разрешаю.

Насколько разработка отличается от C++?

тем что на Go можно писать как веб (инструменты и практики располагают) так и затыкать узкие места.