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

ссылки конечно давать не учили.

Ты не тот вопрос задаешь. Спроси, что такое Go way, юный падаван.

// Капча zaebat many на что-то намекает.

Что такое Go way, учитель?

ссылки конечно давать не учили.

ссылки на что, на «говорят в Москве кур доят gorilla toolkit - больший голэнг вэй, чем revel»?

ссылки на то, где говорят такое.

хабре

Лол, эту парашу еще кто-то читает? Вредные советы под видом профессионализма. Нет и не было никого голанг-вей. Есть набор идиом, которые описаны в effective go, и на которые можно положить. Все.

— Во первых - это пиратский кодекс, значит он писан для пиратов, второе - о том, что вы вернётесь на берег речи не было! И третье: кодекс - это всего лишь свод указаний, а не жёстких законов!

Потому что это ещё один монолитный рубионраилс.

Лол, эту парашу еще кто-то читает?

Напомнил мне удалить rss-подписку на это. Спасибо.

Что это значит для конечного пользователя? Чем конкретно двадцать немонолитных рубионраилса лучше одного монолитного?

http://www.youtube.com/watch?v=Y6OvsJqimfg

Go-way это использование стандартной библиотеки и простых внешних дополняющих библиотек вроде gorilla.

Не go-way — монолитные фреймворки слепо следующие mvc и обмазанные рефлексией там, где от неё профита нет.

Niet

Практика показывает обратное.

Что это значит для конечного пользователя?

Чо за пользователя? посетителя сайта?

Чем конкретно двадцать немонолитных рубионраилса лучше одного монолитного?

чо?

повсеместно используются структуры, как классы, с вызовом методов через точку

так вроде в Go и делают обычно, ибо классов как отдельной сущности нет

Чо за пользователя? посетителя сайта?

Для пользователя фреймворка (если речь о сайте, речь про его разработчика). Ты говоришь, что монолитность - это что-то плохое. Я жду в чём будет это проявляться для него. Ну типа, не сможет реализовать фичу X или *уй у него вставать не будет больше.

чо?

Чо - это твоя фраза в контексте «один монолитный рубионраилс» - что-то плохое. Я спрашиваю, чем лучше не один, а много, не монолитный, а блочный, не рубионраилс, а нерубионраилс.

Монолитность сама по себе не всегда однозначно плоха или хороша. Но минус относительно го — у нас так не принято.

обмазанные рефлексией там, где от неё профита нет

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

Монолитность сама по себе не всегда однозначно плоха или хороша. Но минус относительно го — у нас так не принято.

Во-во, это оно. То самое, на счёт чего я и делал реквест на прояснение. Как определить степень монолитности, монолитен ли вообще revel? Может быть нет? Какая именно часть фреймворка вызывает сомнения?

Хорошо, если ты прав. Ибо это бы значило значило, что разработчики и комьюнити go - адекватные и прагматичные люди, а не оголтелые фанатики, которые так увлекаются дорогой, что забывают куда ехали.

Хороший пример рефлексии — пакеты fmt, json, xml и подобные. Плохой пример — dependency injection во всякого рода martini. Экономится мало времени разработчика, работает медленнее явной реализации, возможность появления ошибок из-за ослабления типизации, которых можно было бы избежать.

В контексте вебфреймворков — насколько далека абстракция от net/http? Насколько сильно абстракция диктует структуру кода? Использует ли абстракция стандартные для го структуры и интерфейсы или обязывает использовать свои?

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

Revel в этом плане весьма монолитен. Типовые сайтики на нём делать может быть проще и быстрее, но для серьёзных приложений имеет смысл брать что-то ближе к net/http.

В контексте вебфреймворков — насколько далека абстракция от net/http?

Насколько?

Revel в этом плане весьма монолитен. Типовые сайтики на нём делать может быть проще и быстрее, но для серьёзных приложений имеет смысл брать что-то ближе к net/http.

Блин, опять то же самое. Стоит не стоит. Конкретно скажи, чем грозит использование этого фреймворка для «нетиповых сайтиков»?

В Revel есть DI?

а что есть golang-way?

можно спросить тут https://groups.google.com/forum/#!forum/golang-nuts

мне кажется это тупо вопрос full-stack vs micro, rails vs sinatra, django vs flask, play vs scalatra

кто сказан что golang-way это всегда пункт номер 2? это тупо

Не подскажешь го вэйную реализацию reverse routing'а?

Нашёл я бабку. Ей оказалась автор Martini, который необходимость создания своего фреймворка объяснил как «ящитаю, revel - это шаг в неправильном направлении». Хотя внимательные читатели отметили:

The only difference between martini and other approaches like beego and revel is that martini uses dependency injection, while others use registering controllers methods.

They both use reflection.

If revel is a step in the wrong direction, so is martini.

https://groups.google.com/forum/#!msg/golang-nuts/LubMauy6XFI/SmxL01oUNMkJ

В остальном же в go-nuts, на моё удивление, очень тёплые отзывы о Revel.

Не подскажешь го вэйную реализацию reverse routing'а?

Похоже только в revel и есть эта фича. Типобезопасный обратный роутинг. Демо:

// Show is an action that displayes the hotel information.
func (c Hotels) Show(id int) revel.Result {
	hotel := HotelByID(id)
	return c.Render(hotel)
}

// Save action saves the hotel info and redirects back to Show.
func (c Hotels) Save(hotel Hotel) revel.Result {
	...

	// Redirect back to Show.
	return c.Redirect(routes.Hotels.Show(hotel.ID))
}

Не про ревел.

Автогенерацию гоферы вполне себе ценят: на уровне вредных советов ей как бы заменяют дженерики (работающие реализации не трогал, чисто на уровне идеи), а на уровне продакшена — добавили полноценную команду go generate. Так в этом ничего страшного нет.