Tại sao Iris bị cộng đồng Go tẩy chay

Khám phá lý do Iris bị cộng đồng Go tẩy chay. Những sai lầm thiết kế và quản lý cộng đồng yếu kém đã khiến Iris trở thành ví dụ điển hình về một dự án opensource "thất bại" trong hệ sinh thái Go.

Trong hệ sinh thái của một ngôn ngữ lập trình, các frameworkvà thư viện đóng vai trò then chốt trong việc định hình năng suất và phương pháp luận của lập trình viên. Tuy nhiên, không phải tất cả các công cụ đều được tạo ra như nhau, và một số trở thành những case study về các quyết định thiết kế sai lầm và quản trị cộng đồng yếu kém. Iris là một ví dụ điển hình và nghiêm trọng nhất trong cộng đồng Go, không chỉ vì những hạn chế về mặt kỹ thuật mà còn bởi cách thức nó bị cộng đồng Go tẩy chay một cách rõ ràng và có hệ thống.

Hiện tượng Iris bị cô lập không chỉ là một cuộc tranh cãi nhỏ lẻ. Nó đã diễn ra trên nhiều nền tảng cốt lõi của cộng đồng Go: từ những cuộc thảo luận gay gắt và cảnh báo liên tục trên Reddit (đặc biệt là subreddit r/golang), cho đến việc các vấn đề và bình luận chỉ trích bị kiểm duyệt trên GitHub, và đỉnh điểm là việc Iris bị xóa khỏi danh sách Awesome-Go – một động thái cực kỳ hiếm thấy và là lời cảnh báo nghiêm trọng từ chính cộng đồng. Điều này không phải là một sự trùng hợp ngẫu nhiên, mà là kết quả của một loạt các hành vi gây tranh cãi và triết lý thiết kế đi ngược lại tinh thần của Go.

Tôi vẫn còn nhớ rõ những ngày đầu khi quyết định sử dụng Iris cho backend của một ứng dụng di động giúp khám bệnh online trong thời kỳ COVID. Với kinh nghiệm từ các framework "tích hợp sẵn mọi thứ" (batteries-included) như .NET MVC hay PhalconPHP, Iris ban đầu có vẻ là một lựa chọn tự nhiên cho Go, hứa hẹn sự tiện lợi và tốc độ phát triển nhanh chóng. Ứng dụng của tôi đã hoạt động tốt, hiệu năng đáp ứng được yêu cầu nhờ bản chất nhanh vốn có của Go, với các bottleneck thực sự nằm ở logic nghiệp vụ phức tạp hay giao dịch cơ sở dữ liệu. Tuy nhiên, theo thời gian, những vấn đề cố hữu của Iris dần bộc lộ rõ ràng, biến quá trình phát triển và bảo trì thành một gánh nặng thực sự, làm giảm năng suất và sự thoải mái của toàn đội ngũ. Tôi nhận ra rằng, dù một ứng dụng có thể "chạy được", nhưng trải nghiệm phát triển tệ hại và chi phí bảo trì cao mới là vấn đề cốt lõi – những vấn đề mà cộng đồng Go đã nhìn thấy và cảnh báo từ lâu.

Bài viết này sẽ phân tích một cách có hệ thống các lý do kỹ thuật, triết lý và đạo đức dẫn đến việc Iris bị cô lập và tại sao việc sử dụng nó trong bất kỳ dự án mới nào đều mang lại rủi ro không thể chấp nhận được.

1. Vấn đề về quản trị cộng đồng và sự thiếu minh bạch (Community Governance and Lack of Transparency)

Nền tảng của bất kỳ dự án mã nguồn mở (open-source) thành công nào là niềm tin. Iris đã đối mặt với những thách thức nghiêm trọng trong việc duy trì niềm tin này thông qua một số hành vi gây tranh cãi, dẫn đến hậu quả trực tiếp là bị xóa khỏi danh sách Awesome-Go, một động thái hiếm thấy đối với một dự án tầm cỡ.

Thao túng Dữ liệu và Hành vi Phi cạnh tranh (Data Manipulation and Anti-competitive Behavior): Iris liên tục tự quảng cáo là "framework nhanh nhất" dựa trên các kết quả benchmark. Tuy nhiên, cộng đồng đã đưa ra nhiều bằng chứng cho thấy các benchmark này có thể đã được thiết kế một cách thiếu công bằng để tạo lợi thế cho Iris. Các hành vi này bao gồm việc so sánh các kịch bản không tương đồng (ví dụ: so sánh hiệu năng của router thuần túy với một framework đầy đủ tính năng) và tinh chỉnh môi trường chạy một cách không thực tế để đạt được kết quả cao nhất cho Iris. Đã có những cáo buộc về việc sử dụng bot và các tài khoản giả (astroturfing) để tăng phiếu bầu (upvote) cho Iris và hạ bệ các framework đối thủ trên các nền tảng như GitHub và Reddit. Những hành vi này đã làm xói mòn sự cạnh tranh lành mạnh và gây nhiễu loạn thông tin cho các lập trình viên đang tìm kiếm công cụ phù hợp. Mức độ nghiêm trọng của v

ấn đề này lớn đến nỗi, trong nhiều bài benchmark độc lập về các thành phần cụ thể như hiệu năng template rendering, Iris thường bị loại bỏ hoàn toàn khỏi danh sách so sánh, thể hiện sự thiếu tin tưởng của cộng đồng vào các tuyên bố và số liệu của nó.

Kiểm duyệt và Thái độ Thù địch với Phản hồi (Censorship and Hostile Response to Feedback): Thay vì tiếp thu các chỉ trích mang tính xây dựng, tác giả của Iris (kataras) đã bị cáo buộc liên tục xóa các issue và bình luận chỉ ra các vấn đề của framework trên GitHub. Người dùng đưa ra các câu hỏi hợp lệ hoặc chỉ trích thường bị chặn (block) ngay lập tức. Cách tiếp cận này đã tạo ra một môi trường độc đoán, ngăn cản sự đóng góp và cải tiến từ cộng đồng, đồng thời tạo ra một môi trường không thân thiện. Điều này không chỉ làm mất đi những đóng góp tiềm năng mà còn khiến dự án thiếu đi sự đa dạng về quan điểm và kiểm tra chéo (peer review), vốn rất quan trọng cho sự ổn định và bảo mật của phần mềm mã nguồn mở.

Sao chép mã nguồn và Ghi đè lịch sử Git (Code Plagiarism and Git History Overwriting): Một trong những cáo buộc nghiêm trọng nhất chống lại Iris là việc sao chép mã nguồn từ các dự án Go mã nguồn mở khác, đặc biệt là httprouter của Julienschmidt, mà không tuân thủ các quy định về giấy phép hoặc ghi công đầy đủ. Cộng đồng đã chỉ ra rằng Iris ban đầu có những phần mã giống hệt, thậm chí cả các bình luận và tên biến, với httprouter nhưng lại thiếu thông báo giấy phép. Vấn đề này đã được ghi nhận và thảo luận sôi nổi trên các diễn đàn như Reddit và các issue trên GitHub. Nghiêm trọng hơn, tác giả của Iris còn bị cáo buộc thường xuyên "làm phẳng" (flatten) lịch sử Git của repository. Hành động này không chỉ xóa bỏ các commit cũ, làm mất đi dấu vết về nguồn gốc mã nguồn và các đóng góp của cộng đồng, mà còn gây khó khăn lớn cho việc theo dõi sự thay đổi, gỡ lỗi và kiểm tra bảo mật. Việc ghi đè lịch sử Git cũng làm suy yếu tính minh bạch và đáng tin cậy của dự án mã nguồn mở.

Những hành vi này, dù có thể được coi là "drama" ở một mức độ nào đó, thực chất là những dấu hiệu rõ ràng về một dự án thiếu sự quản trị chuyên nghiệp và không đáng tin cậy để làm nền tảng cho các hệ thống phần mềm quan trọng. Việc bị loại khỏi Awesome-Go là một lời cảnh báo nghiêm trọng từ chính cộng đồng Go.

2. Xung đột triết lý thiết kế với ngôn ngữ go (design philosophy conflict with go)

Đây là vấn đề kỹ thuật cốt lõi và là lý do chính tại sao Iris bị xem là một anti-pattern trong Go. Thiết kế của Iris đi ngược lại các nguyên tắc cơ bản đã làm nên sức mạnh của Go.

Thiết kế Monolithic và API Phình to (Bloated API): Triết lý của Go đề cao các interface nhỏ, các thành phần có thể kết hợp (composable) và sự đơn giản. Lập trình viên được khuyến khích chỉ import những gì họ cần. Iris lại đi theo hướng ngược lại, cung cấp một giải pháp "tất cả trong một" khổng lồ. Nó tích hợp sẵn mọi thứ từ router, middleware, quản lý session, WebSocket, cho đến view engine. Điều này buộc người dùng phải chấp nhận toàn bộ hệ sinh thái của Iris, ngay cả khi họ chỉ cần một phần nhỏ chức năng, dẫn đến tình trạng khóa chặt công nghệ (vendor lock-in) và làm tăng độ phức tạp không cần thiết. Một framework có kiến trúc nguyên khối như Iris thường dẫn đến kích thước binary lớn hơn, tăng bề mặt tấn công (attack surface) và gây khó khăn trong việc tối ưu hóa hoặc loại bỏ các phần code không sử dụng (tree-shaking). Trong trường hợp ứng dụng khám bệnh online của tôi, dù Iris cung cấp rất nhiều tính năng, cuối cùng tôi chỉ sử dụng phần routing và binding, điều này cho thấy sự "phình to" không cần thiết của framework và việc các tính năng tích hợp sẵn không phù hợp với nhu cầu thực tế của dự án.

Lạm dụng Global State và các cơ chế Ngầm ("Magic"): Go khuyến khích sự tường minh (explicitness). Luồng dữ liệu và trạng thái phải rõ ràng và dễ theo dõi. Như câu châm ngôn của Go đã nói: "Clear is better than clever." (Rõ ràng tốt hơn thông minh). Các framework "magic" như Iris, với việc lạm dụng các biến toàn cục (global state) và các hàm init() để thực hiện cấu hình ngầm, đi ngược lại hoàn toàn triết lý này. Các cơ chế như tự động binding dữ liệu (auto-binding) một cách phức tạp che giấu logic xử lý và xác thực, khiến việc gỡ lỗi (debug) và suy luận về hành vi của chương trình trở nên cực kỳ khó khăn. Điều này làm giảm đáng kể khả năng đọc hiểu (readability) và bảo trì (maintainability) của code. Việc này cũng gây trở ngại lớn cho việc viết mã kiểm thử (testing), vì các thành phần phụ thuộc vào trạng thái toàn cục không thể được kiểm thử một cách độc lập. Như tôi đã chia sẻ, quá trình phát triển và gỡ lỗi với Iris khá mệt mỏi, và các thành viên mới trong nhóm mất nhiều thời gian để hiểu "magic code" của nó. Chất lượng code cũng bị ảnh hưởng (do phải tùy chỉnh nhiều thứ bằng adapter, v.v.), làm giảm hiệu suất tổng thể của đội ngũ.

Để minh họa sự khác biệt giữa cách tiếp cận tường minh của Go và cơ chế "magic" của Iris, hãy xem xét ví dụ về việc xử lý dữ liệu JSON từ một HTTP request:

Cách tiếp cận tường minh (ví dụ net/http hoặc Gin): Lập trình viên rõ ràng khai báo một struct và sau đó decode dữ liệu JSON vào struct đó.

// Ví dụ về cách xử lý request tường minh trong Go (ví dụ: với net/http hoặc Gin)
package main

import (
	"encoding/json"
	"fmt"
	"net/http"
)

type User struct {
	Name  string `json:"name"`
	Email string `json:"email"`
}

func createUserHandler(w http.ResponseWriter, r *http.Request) {
	var user User
	// Tường minh decode JSON từ request body
	err := json.NewDecoder(r.Body).Decode(&user)
	if err != nil {
		http.Error(w, err.Error(), http.StatusBadRequest)
		return
	}
	fmt.Printf("Received user: %+v\n", user)
	w.WriteHeader(http.StatusCreated)
	fmt.Fprint(w, "User created successfully")
}

func main() {
	http.HandleFunc("/users", createUserHandler)
	fmt.Println("Server listening on :8080")
	http.ListenAndServe(":8080", nil)
}

Cách tiếp cận "Magic" (ý tưởng của Iris): Iris có thể tự động bind dữ liệu vào các tham số hàm hoặc struct mà không cần gọi decode tường minh. Mặc dù có vẻ tiện lợi ban đầu, điều này che giấu logic và khiến việc theo dõi luồng dữ liệu trở nên khó khăn.

package controllers

import (
	"github.com/kataras/iris/v12/_examples/mvc/vuejs-todo-mvc/src/todo"

	"github.com/kataras/iris/v12"
	"github.com/kataras/iris/v12/mvc"
	"github.com/kataras/iris/v12/sessions"
	"github.com/kataras/iris/v12/websocket"
)

// TodoController is our TODO app's web controller.
type TodoController struct {
	Service todo.Service

	Session *sessions.Session

	NS *websocket.NSConn
}

// BeforeActivation called once before the server ran, and before
// the routes and dependencies binded.
// You can bind custom things to the controller, add new methods, add middleware,
// add dependencies to the struct or the method(s) and more.
func (c *TodoController) BeforeActivation(b mvc.BeforeActivation) {
	// this could be binded to a controller's function input argument
	// if any, or struct field if any:
	b.Dependencies().Register(func(ctx iris.Context) (items []todo.Item) {
		ctx.ReadJSON(&items)
		return
	}) // Note: from Iris v12.2 these type of dependencies are automatically resolved.
}

// Get handles the GET: /todos route.
func (c *TodoController) Get() []todo.Item {
	return c.Service.Get(c.Session.ID())
}

// PostItemResponse the response data that will be returned as json
// after a post save action of all todo items.
type PostItemResponse struct {
	Success bool `json:"success"`
}

var emptyResponse = PostItemResponse{Success: false}

// Post handles the POST: /todos route.
func (c *TodoController) Post(newItems []todo.Item) PostItemResponse {
	if err := c.Service.Save(c.Session.ID(), newItems); err != nil {
		return emptyResponse
	}

	return PostItemResponse{Success: true}
}

func (c *TodoController) Save(msg websocket.Message) error {
	id := c.Session.ID()
	c.NS.Conn.Server().Broadcast(nil, websocket.Message{
		Namespace: msg.Namespace,
		Event:     "saved",
		To:        id,
		Body:      websocket.Marshal(c.Service.Get(id)),
	})

	return nil
}

Sự che giấu thư viện chuẩn (net/http): Một framework tốt trong Go nên bổ trợ, chứ không phải thay thế hoàn toàn thư viện chuẩn. Các framework như Gin hay Chi vẫn cho phép lập trình viên làm việc trực tiếp với các kiểu dữ liệu quen thuộc như http.Handler và http.Request. Iris lại tạo ra các lớp trừu tượng dày đặc của riêng mình, che giấu hoàn toàn các thành phần cốt lõi của net/http. Điều này không chỉ tạo ra một đường cong học tập không cần thiết mà còn ngăn cản lập trình viên tái sử dụng kiến thức và các thư viện khác trong hệ sinh thái Go. Việc này cũng làm giảm khả năng tương thích ngược (backward compatibility) và gây khó khăn khi Go cập nhật thư viện net/http. Trải nghiệm của tôi với việc "thay thế các thành phần khó khăn" và việc "các thành viên mới mất nhiều thời gian để hiểu magic code" là hệ quả trực tiếp của việc Iris che giấu thư viện chuẩn và tạo ra các lớp trừu tượng riêng.

3. Đánh Giá Lại Luận Điểm Về Hiệu Năng (Re-evaluating Performance Claims)

Luận điểm bán hàng chính của Iris là hiệu năng. Tuy nhiên, luận điểm này có nhiều lỗ hổng khi phân tích kỹ.

Sự khác biệt giữa Micro-benchmark và Hiệu năng Thực tế (Micro-benchmark vs. Real-world Performance): Các benchmark mà Iris quảng bá thường tập trung vào các tác vụ xử lý đơn giản, bị giới hạn bởi CPU (CPU-bound), như định tuyến (routing) các request HTTP đơn thuần. Trong thực tế, hầu hết các ứng dụng web đều bị giới hạn bởi I/O (I/O-bound) – thời gian chờ phản hồi từ cơ sở dữ liệu (database), các API của bên thứ ba, hoặc hệ thống tệp (file system). Trong các kịch bản này, sự chênh lệch vài micro giây (mus) của framework là không đáng kể so với hàng chục hoặc hàng trăm mili giây (ms) của các tác vụ I/O. Theo Định luật Amdahl (Amdahl's Law), việc tối ưu hóa một phần nhỏ của hệ thống (như hiệu năng của framework) sẽ không mang lại cải thiện đáng kể cho hiệu năng tổng thể nếu phần lớn thời gian xử lý nằm ở các tác vụ khác (như I/O). Như tôi đã nhận thấy trong dự án ứng dụng khám bệnh online, hiệu năng của Iris không phải là vấn đề chính vì bản thân Go đã rất nhanh và đáp ứng tốt. Các bottleneck thực sự thường nằm ở logic nghiệp vụ phức tạp, các giao dịch cơ sở dữ liệu, hoặc các hoạt động I/O khác, nơi mà sự khác biệt về tốc độ framework trở nên không đáng kể.

Hiệu năng của Lập trình viên (Developer Performance): Một yếu tố thường bị bỏ qua là hiệu năng của lập trình viên. Một framework với code tường minh, dễ đọc, dễ bảo trì và dễ gỡ lỗi sẽ giúp tăng năng suất của đội ngũ về lâu dài. Một framework "kỳ diệu" (magical) và mờ ám như Iris, dù có thể nhanh hơn một chút trên benchmark, lại làm giảm đáng kể hiệu năng của lập trình viên, dẫn đến chi phí bảo trì và phát triển (maintenance and development costs) cao hơn. Điều này bao gồm thời gian onboarding cho lập trình viên mới, tăng tỷ lệ lỗi (bug rates) do sự phức tạp và thiếu tường minh, tốc độ phát triển tính năng chậm hơn, và khó khăn trong việc refactoring code. Đây mới là chi phí thực sự cần quan tâm trong một dự án phần mềm. Trải nghiệm "development experience tệ" và việc "team khá không thoải mái" của tôi là minh chứng rõ ràng cho việc hiệu năng của framework không thể bù đắp cho hiệu năng của lập trình viên bị suy giảm.

4. Rủi Ro Hữu Hình Khi Sử Dụng Iris Trong Môi Trường Production (Tangible Risks of Using Iris in Production)

Việc lựa chọn Iris cho một dự án không chỉ là một quyết định kỹ thuật tồi, mà còn là một quyết định kinh doanh đầy rủi ro. Chính những rủi ro này là lý do chính khiến nhiều lập trình viên, bao gồm cả những người từng có kinh nghiệm với các framework "tích hợp sẵn" khác, cuối cùng đã từ bỏ Iris.

Rủi ro bảo trì (Maintenance Risk): Dự án phụ thuộc gần như hoàn toàn vào một nhà phát triển duy nhất (bus factor of one) với lịch sử hành vi không ổn định. Nếu tác giả này ngừng phát triển, các dự án sử dụng Iris sẽ bị mắc kẹt với một nền tảng không được hỗ trợ và không có ai bảo trì. Điều này đặc biệt nguy hiểm đối với các lỗ hổng bảo mật (security vulnerabilities) mới phát hiện, có thể không được vá kịp thời. Tính cứng nhắc của framework cũng khiến việc nâng cấp hoặc vá lỗi trở nên khó khăn.

Thiếu hụt hỗ trợ từ cộng đồng (Lack of Community Support): Do các vấn đề trong quá khứ, việc tìm kiếm sự hỗ trợ cho các vấn đề liên quan đến Iris trên các nền tảng như Stack Overflow hay Reddit là gần như không thể. Các diễn đàn và kênh cộng đồng chính thống thường sẽ không khuyến khích hoặc thậm chí từ chối hỗ trợ cho các vấn đề của Iris.

Khó khăn trong tuyển dụng và đường cong học tập (Hiring Difficulties and Learning Curve): Việc thuyết phục các lập trình viên Go có kinh nghiệm tham gia một dự án sử dụng Iris là một thách thức lớn, vì nó được coi là một công nghệ độc hại và lỗi thời. Đối với các thành viên mới trong nhóm, đường cong học tập của Iris không tốt do sự che giấu thư viện chuẩn và các cơ chế "magic", làm giảm năng suất của toàn đội. Kinh nghiệm của tôi về việc "team khá không thoải mái" và "các thành viên mới mất nhiều thời gian để hiểu magic code" là những ví dụ cụ thể về rào cản này trong thực tế.

Khóa chặt công nghệ (Vendor Lock-in): Do thiết kế monolithic và API độc quyền, việc di chuyển một ứng dụng từ Iris sang một framework khác đòi hỏi một nỗ lực viết lại (rewrite) rất lớn. Điều này bao gồm việc phải thay đổi các kiểu dữ liệu context tùy chỉnh, middleware, templating engine và các cơ chế xử lý request/response không chuẩn, khiến quá trình di chuyển trở nên tốn kém và rủi ro. Việc tôi gặp khó khăn trong "việc thay thế các thành phần" và cuối cùng chỉ sử dụng một phần nhỏ của Iris cho thấy mức độ khóa chặt công nghệ mà framework này tạo ra.

5. Con Dao Hai Lưỡi Của Các Framework "Tích Hợp Sẵn" (The Double-Edged Sword of "Batteries-Included" Frameworks)

Iris là một ví dụ điển hình cho mặt trái của các framework "tích hợp sẵn mọi thứ". Mặc dù ban đầu chúng có vẻ hấp dẫn vì sự tiện lợi và tốc độ khởi tạo dự án, nhưng chúng tiềm ẩn nhiều rủi ro:

Ưu điểm (Potential Advantages):

Khởi tạo nhanh chóng (Rapid Prototyping): Cung cấp sẵn các thành phần cần thiết, giúp lập trình viên nhanh chóng dựng lên một ứng dụng cơ bản.
Tính nhất quán (Consistency): Đảm bảo một cách tiếp cận đồng nhất trong toàn bộ dự án nếu tuân thủ chặt chẽ các quy tắc của framework.
Giảm thiểu quyết định (Reduced Decision Fatigue): Ít phải lựa chọn các thư viện độc lập cho từng chức năng.

Nhược điểm (Significant Disadvantages), đặc biệt là với các framework như Iris:

Bloat và Kích thước Binary lớn (Bloat and Larger Binary Size): Bao gồm nhiều tính năng mà dự án có thể không bao giờ sử dụng, làm tăng kích thước binary và có thể ảnh hưởng đến thời gian khởi động.
Tính độc đoán (Opinionated Nature): Buộc lập trình viên phải tuân theo một cách làm việc cụ thể, có thể không phù hợp với mọi yêu cầu dự án hoặc sở thích của đội ngũ.
Khó tùy chỉnh và Thay thế thành phần (Difficulty in Customization and Component Swapping): Việc thay thế một thành phần tích hợp sẵn bằng một thư viện khác (ví dụ: đổi router hoặc view engine) thường rất khó khăn hoặc không thể, do sự phụ thuộc chặt chẽ giữa các module.
Phụ thuộc vào một nhà phát triển/nhóm nhỏ (Reliance on a Small Team/Single Developer): Rủi ro cao nếu nhà phát triển chính ngừng hỗ trợ hoặc thay đổi định hướng, khiến dự án bị bỏ lại phía sau.
Giảm hiểu biết về cơ chế nền tảng (Reduced Understanding of Underlying Mechanisms): Khi framework che giấu quá nhiều chi tiết của thư viện chuẩn, lập trình viên có thể không hiểu rõ cách Go hoạt động ở cấp độ thấp hơn, gây khó khăn khi gỡ lỗi các vấn đề phức tạp hoặc khi cần tối ưu hóa sâu.
Khả năng lỗi thời nhanh chóng (Potential for Rapid Obsolescence): Nếu framework không theo kịp sự phát triển của ngôn ngữ hoặc các tiêu chuẩn cộng đồng, nó có thể nhanh chóng trở nên lỗi thời.

Go, với triết lý "do one thing well" (làm một việc thật tốt) và khuyến khích các thư viện nhỏ, có thể kết hợp, thường không phù hợp với mô hình "tích hợp sẵn" quá mức. Các framework Go thành công hơn thường là những framework tối giản, cung cấp một nền tảng vững chắc nhưng vẫn cho phép lập trình viên tự do lựa chọn các thư viện khác để xây dựng ứng dụng của mình.

Kết Luận (Conclusion)

Iris Framework là một trường hợp nghiên cứu về sự thất bại trên nhiều phương diện: đạo đức cộng đồng, triết lý thiết kế và quản trị rủi ro. Nó đại diện cho một phương pháp luận đi ngược lại những nguyên tắc cốt lõi về sự rõ ràng (clarity), đơn giản (simplicity) và khả năng kết hợp (composability) đã làm nên thành công của Go.

Sự tẩy chay của cộng đồng, mặc dù là một yếu tố đáng chú ý, nhưng những lý do chính khiến nhiều lập trình viên, bao gồm cả những người từng có kinh nghiệm từ các framework "tích hợp sẵn" khác, từ bỏ Iris là do các vấn đề thực tế về khả năng bảo trì (maintainability), tính linh hoạt (flexibility) kém, sự cứng nhắc và độc đoán trong thiết kế, cũng như đường cong học tập không tốt cho đội ngũ.

Trường hợp ứng dụng khám bệnh online của tôi là một minh chứng sống động cho những vấn đề này. Tôi đã sử dụng Iris cho backend của một ứng dụng di động giúp khám bệnh online trong thời kỳ COVID. Mặc dù ứng dụng vẫn hoạt động tốt và đáp ứng được hiệu năng cơ bản (nhờ bản chất nhanh vốn có của Go và các bottleneck thường nằm ở logic nghiệp vụ, giao dịch cơ sở dữ liệu, I/O, v.v.), nhưng trải nghiệm phát triển lại cực kỳ tiêu cực. Quá trình phát triển và gỡ lỗi trở nên vô cùng mệt mỏi, không chỉ vì sự phức tạp của các cơ chế "magic" mà còn do việc thay thế các thành phần tích hợp sẵn của Iris là vô cùng khó khăn, gần như không thể nếu không can thiệp sâu vào lõi framework. Cuối cùng, ứng dụng của tôi chỉ sử dụng phần routing và binding của Iris, bỏ qua hầu hết các tính năng "tích hợp sẵn" khác như quản lý session hay view engine, điều này càng khẳng định sự "phình to" không cần thiết của framework và việc các tính năng tích hợp sẵn không phù hợp với nhu cầu thực tế của dự án. Hơn nữa, toàn bộ đội ngũ phát triển cảm thấy không thoải mái, thậm chí khó chịu với việc phải làm việc trên một codebase thiếu tường minh. Các thành viên mới mất rất nhiều thời gian để làm quen và hiểu được luồng hoạt động của "magic code", làm chậm đáng kể quá trình onboarding. Chất lượng code cũng bị ảnh hưởng nghiêm trọng do phải liên tục tùy chỉnh nhiều thứ bằng các adapter hoặc viết lại các phần logic để phù hợp với triết lý của Go, dẫn đến code kém chất lượng và khó bảo trì. Điều này nhấn mạnh rằng hiệu năng của framework trên benchmark không thể bù đắp cho hiệu năng của lập trình viên và chất lượng bảo trì tổng thể của dự án.

Dựa trên các phân tích về kỹ thuật và rủi ro, không có một lý do hợp lý nào để lựa chọn Iris cho các dự án mới. Trong Go, bạn nên hạn chế tối đa việc sử dụng các framework "magic" và ưu tiên sự tường minh. Các giải pháp thay thế như Gin (phổ biến, hiệu năng cao), Echo (nhẹ, nhanh, ít "magic"), Fiber (lấy cảm hứng từ Express, tập trung vào hiệu năng), hoặc Go-zero (hướng microservice với các thực tiễn kỹ thuật tích hợp sẵn), hoặc thậm chí là sử dụng trực tiếp thư viện net/http để xây dựng một micro-framework tùy chỉnh, đều cung cấp một nền tảng vững chắc, minh bạch và phù hợp hơn với triết lý của Go, đảm bảo tính bền vững và khả năng bảo trì cho dự án của bạn.