thảo luận Tất tần tật về Go (Golang)

[Nipin]

Thím cũng cãi nhau nhiều rồi vậy có cái opensource nào chưa để mình vào star
Với lại tóm tắt cái mấy cái kiến thức học được từ lang war/editor war dùng như thế nào trong project của thím với

có, persona mới của tôi đi kèm với cái github luôn (các nick cũ cũng có đống projects cũ cơ mà tôi lỡ tay xoá hết rồi)
github.com/nipinium
vào star hết cho tôi đi bạn ơi :x :x

 

[nntgwww]

^ ông kia khác stack quá ko star dc

Troll ngu nữa hả

Ngoài twitter thì group fb giúp cập nhật kiến thức phai nói nhanh thứ 2. Siêng thì lươn reddit nữa.

Chứ có ai nói cập nhật kiến thức nhơ vào voz

Nói vậy chứ bữa giờ có cai 2pic microservice là ưng. Vì đa phần các mem chia sẻ kinh nghiệm, nhiều keyword

 

[Nipin]

Troll ngu nữa hả

Ngoài twitter thì group fb giúp cập nhật kiến thức phai nói nhanh thứ 2. Siêng thì lươn reddit nữa.

Chứ có ai nói cập nhật kiến thức nhơ vào voz

fb của bạn có cãi nhau không, không cãi nhau hoặc không dám cãi thì làm sao mà lên trình? cùng lắm là mót được mấy đường link từ reddit thôi

https://medium.com/@jussiahola/cunninghams-law-and-human-motivation-d88063fdc098
các bạn ít dùng internet có thể thấy cách comment của tôi hơi phản cảm, nhưng thực ra thì đây là một giọng điệu khá thường dùng trên mạng. tôi thì không vào fb group kia nhưng theo ấn tượng của tôi là kiểu người quen thì hay nể nang nhau, cho nên nói chuyện thường hay nhường nhịn, cho nên kết quả thì hầu như chỉ là nhóm nhỏ tự sướng, đi ra ngoài không chịu được sóng gió

 

[Nipin]

Cơ mà học xong thường là quên hết mịe nó vì có dùng bao giờ đâu, mấy cái low level ấy thực tế chả cần mấy (trừ chỗ rất cần nhưng chả đến lượt).
Giờ chỉ HTML/JS/CSS với cái backend bất kỳ là đã làm mệt nghỉ để kiếm sống rồi. Mấy cái war này nhiều khi xem thì cũng google đọc tí cho biết nhưng mà cuối cùng thì ngoài để chém gió thì cũng chả thấy được gì

kiếm sống thì bạn làm 3 4 tháng là đủ sống cho cả năm rồi, không giải trí chém gió thì làm gì

cơ mà tôi không thấy học nhiều là thiếu. ví dụ đợt trước tôi làm tư vấn cho một dự án, có thằng client phàn nàn là nó import csv vào excel nó hiện sai tiếng việt, hỏi có cách nào khác không (vì file rất to cho nên thằng dev nó dùng csv), cậu dev thì bảo đấy là hạn chế của excel, đưa ra một cái link hướng dẫn import csv tiếng việt vào excel, nói chung cũng giải quyết vấn đề. cơ mà khách bảo người sử dụng cuối không rành IT, với lại có thể ra cửa hàng in không dùng bản excel mới nhất, có thể sẽ thọt. tôi nhìn qua bảo luôn "sao không thử để encoding là utf16 thay vì utf8", vì tôi sau thời gian dài chém gió trên mạng (tất nhiên đéo phải ở voz, ở đây tôi hầu như chả học được cái gì) thì biết windows nó internal encoding là UTF-16 little-endian, cho nên rất có nhiều khả năng là nó support cái encoding này ngay từ đầu.

mấy chuyện tương tự có rất nhiều, ví dụ bạn có thể dùng cái location của nginx để map các service khác nhau vào cùng một domain, đỡ mất công phải setting CORS (tất nhiên cái này tuỳ dự án), dùng systemd để quản lý service thay vì dùng mấy cái 3rd party process manager như pm2 hoặc heroku (cái này thì tôi biết hoàn toàn là do chúng nó hồi đó chửi nhau là có nên dùng systemd hay không)

 

[gtunveteran]

C++ ở đây là giúp đọc dữ liệu từ nosql nhanh hơn à thím .

Các bạn đa phần quen với việc sử dụng các db có săn như mysql hay mongodb rồi nên ít động tới c++ , bản chất của việc viết lên các db đó 99% các db kể cả RMDB hay noSQL đều được viết bằng c++, việc phát triển tinh năng mới cho db dựa vào các open source có sẵn thì buộc bạn phải can thiệp vào cấp độ low level , tức là phải làm việc với c++, để ý sẽ thấy mỗi một tập đoàn lớn đều sử dụng db riêng do mình phát triển để tự kiếm soát được toàn bộ hiệu năng của hệ thống, google có leveldb https://github.com/google/leveldb , facebook có rockdbs https://github.com/facebook/rocksdb, zalo vn có zdb .;., chìa khóa thành công của một tập đoàn làm product lớn là họ có thể kiếm soát hoàn toàn mã nguồn từ layer thấp nhất tới cao nhất hay không ( đó là lí do tại sao mỗi cty luôn cố phát triển một kiến trúc lữu trữ ở level thấp thay vì dùng luôn sản phẩm của bên thứ 3) với fb họ thậm chí còn làm bản mysql riêng tích hợp rockdbs http://myrocks.io/ , ở việt nam sự thành công của vng cũng đến từ điều này, kiểm soát toàn bộ sản phẩm cuả mình, biết được lí do tại sao hiệu năng chậm, khi bạn sử dụng một service của bên thứ 3 có nghĩa là bạn đã phải đặt hoàn toàn niềm tin vào service đó rồi ( điều đó rất nguy hiểm nếu service đó chưa thực sự tốt, chưa thực sự trưởng thành hoặc đơn giản n không phù hợp với hướng phát triển của cty bạn), đừng nghĩ việc sử dụng thư viện này thư viện nọ một cách bừa bãi ( cứ cho rằng rất nhiều cty lớn n dùng đi) phải hiểu được n có phù hợp với tính chất của cty mình không, có thể phát triển thêm j ở mã nguồn của n để phù hợp với sản phẩm của mình hay không, cái đó là điều quan trọng . Tất nhiên không phải cái nào mình cũng có thể kiểm soát hết được nhưng cố gắng kiếm soát được càng nghiều càng tốt, thì sản phẩm của mình mới chạy ngon được. Cty mình cũng có bộ lưu trữ tự phát triển riêng ( thực ra bộ đó do những thành viên đầu tiên của vng đã phát triển cho zalo đem sang), khi 1 dịch vụ bị chậm thì mn có thể cùng nhau phân tách tới tận level thấp để tối ưu tốt nhất có thể. Cái người tối ưu ở level thấp tất nhiên phải biết về c++ rồi , ko thì cũng chịu ko làm được j cả.

 

[gtunveteran]

bác có thể nói rõ về user-case của c++ trong trường hợp này cụ thể là gì không ? Em thấy làm webservice nó chủ yếu bottleneck ở DB, chứ còn cần gì đến tính toán CPU-bound đâu mà phải cho c++ vào nhỉ. Có lẽ nào bác tự implement một cái DBMS riêng :> mà kể cả thế đi nữa, thì DBMS nó cũng thường phụ thuộc vào số lượng RAM là chính, CPU nằm chơi có chạy mấy đâu.

Đúng rồi đó, botteck ở db là nguyên nhân chính, như bên mình sử dụng full noSQL luôn, 1 trong những vấn đề ở noSQL so với mySQL là phần id n ko được đánh tự động, mình phải viết 1 service để đánh id cho các bản ghi, để làm điều đó phải có 1 service , ở đây service thrift của mình hoàn toàn viết bằng c++, và can thiệp trực tiếp tới db c++ để giải quyết vấn đề concurentcy và atomic khi đánh id. Bạn nào quan tâm tới việc viết 1 db lưu trữ như thế nào thì có thể đọc bài này , n sẽ hướng dẫn làm thế nào để xây dựng 1 db lưu trữ cho riêng mình https://medium.com/zalopay-engineer...vice-bằng-go-và-c-phần-1-storage-565b1a3f7e1b. Những db lưu trữ thực chất sử dụng những func liên quan tới đọc ghi file , vấn để ở chỗ bạn tổ chức lưu như thế nào để lấy ra được bằng 1 cách nhanh nhất.

 

[freelancer_coder]

có, persona mới của tôi đi kèm với cái github luôn (các nick cũ cũng có đống projects cũ cơ mà tôi lỡ tay xoá hết rồi)
github.com/nipinium
vào star hết cho tôi đi bạn ơi :x :x

Nhìn sơ qua cái kemalcr thấy có vẻ hay đó nhỉ. Crystal đã có cái ORM nào ổn ổn như Sequel hay AR bên Ruby chưa thím?
Thím có vẻ kỳ công với crystal sao không làm CR advocate cho trọn đi. Lập topic riêng PR, review về các lib/tool thông dụng, tutorial làm các cái đơn giản cho sinh viên, người tò mò vọc.

 

[Nipin]

Nhìn sơ qua cái kemalcr thấy có vẻ hay đó nhỉ. Crystal đã có cái ORM nào ổn ổn như Sequel hay AR bên Ruby chưa thím?
Thím có vẻ kỳ công với crystal sao không làm CR advocate cho trọn đi. Lập topic riêng PR, review về các lib/tool thông dụng, tutorial làm các cái đơn giản cho sinh viên, người tò mò vọc.

đợi nó ra version 1.0 đã bạn, chứ nó chưa stable tôi cũng ngại pr lắm

orm của crystal thì có nhiều mà tôi cũng chưa thấy thằng nào thực sự ngon:
- overall thì thằng luckyframework có cái avram orm là tốt nhất, feature nhiều, đặc biệt là cực kỳ type safe, cơ mà tôi éo thích
- đi kèm với amberframework thì có cái gọi là granite, cái này thì chỉ là orm cơ bản, chả có chức năng vẹo gì đáng kể
- jennifer orm: thằng này tính năng cũng nhiều, cơ mà y hệt 3 thằng trên là hiện tại hỗ trợ postgresql custom type không tốt lắm (tôi cần citext để có case insensitive)
- crecto: thằng này ăn theo ecto của elixir, nhưng tính năng không bằng một góc, với lại cũng ngừng phát triển rồi thì phải
- clear orm: tôi đang nhắm thằng này, về cơ bản thì khá phù hợp nhu cầu, cơ mà single dev cho nên phát triển chậm vãi, mãi cũng chưa có phần migration tử tế, mấy cái polymorphism nghe cũng hay ho mà nó wip từ đầu năm rồi không xong

nói chung cũng hơi chán, cái luckyframework orm hiện tại chắc là ngon nhất rồi cơ mà quá opinionated tôi không quá thích

thư viện ngon thì phần lớn là port từ ngôn ngữ khác chứ bảo là ngon hẳn thì hầu như là chưa có (cơ mà ít nhất nó cũng hơn thằng nim , ít nhất thằng này mấy cái thư viện nổi tiếng của c/c++ thì đều có binding cả, dù là chưa hoàn thiện, thằng nim thì hầu như là phải tự viết )

cơ mà như thường lệ, thì thằng crystal có cái này: https://github.com/veelenga/awesome-crystal
index tất cả thư viện thì có mấy website, hiện tại thì thằng này là trội nhất: https://crystalshards.org/
nói chung là không có công ty to backup cho nên còn non trẻ lắm, multi thread thỉnh thoảng vẫn coredump

 

[trungpham90]

Tôi thấy được cái này mất cái kia.
1. Bình thường nếu tôi khai báo expicit thì cần implement 1 interface IDE có thể gen tất cả các method cần implement cho tôi. Dùng structural typing này thì cái IDE đem đi vứt. (chả lẽ lại bật source của cái interface lên rồi copy paste sang )
View attachment 64848
2. Khai báo từng minh thì tôi dùng IDE refactor hàng trăm implement của 1 interface cái một và tôi sure 100% là đếch sót cái nào, còn kiểu implicit như trên thì IDE đem đi vứt (trừ phi nó list hết tất cả các class chứa method của cái interface đó và tôi phải đi soi lại từng cái một). Anh nào hay refactor code codebase to to tí thì cái này là vô cùng cần thiết, tôi đếch muốn ngồi cả ngày để debug chỉ vì rename 1 cái method
3. Tôi muốn impl 1 cái interface mà lỡ gõ sai chính tả thì chắc phải đợi lúc compile mới biết (mà giả sử cái class đó chưa được gán vào đâu hết thì chắc compile cũng xuôi lọt luôn).
Trong khi nếu anh khai báo tường minh:
View attachment 64854
3. Mấy cái DI Container dựa trên type chắc anh Go cũng không impl được vì biết đc class nào thuộc về interface nào đâu.
4. Tôi muốn xem 1 interface có những impl nào thì cũng chịu chết (chả lẽ 1 cái interface có method read nó list ra cả trăm cái class không liên quan cho tôi xem ?).
View attachment 64849
5. Auto complete cũng chịu chết, dùng implicit thì anh Go có suggest được tốt thế này không:
View attachment 64850
View attachment 64851
6. Khai báo từng minh thì tôi đọc source cũng dễ hơn, đọc 1 cái class thấy nó implement cái interface nào là biết ngay cái method đó để làm gì liền, cái class đó có thể xài trong context nào liền.
Nói chung theo kiểu anh Go thì thằng IDE chẳng khác gì phế vật.
Ở đây tôi bàn về khía cạnh tooling thôi, xài mấy ngôn ngữ typed mà IDE nó cứ trơ người ra thì rất bực. Hồi đó tôi code thử Go trên goland thì ôi thôi, xài IDE như không xài, chả khác gì đang code JS. Code vài dòng là phải bật docs lên để xem vì không biết interface này thằng nào đang impl để mà ném vô, trong khi Java, Kotlin tôi đếch cần phải nhìn docs luôn vì IDE nó suggest, gen code hết rồi.
Nói chung type system ngoài để check type thì còn để support IDE, khai báo càng tường minh thì IDE nó biết anh đang muốn gì mà còn support, mang tiếng là static typing mà IDE cứ trơ người ra thì code khác mịa gì Dương Quá đâu . Nói chung lập trình thì càng explicit càng tốt, code không phải chỉ có 1 mình bạn đọc mà còn cho người khác, cho IDE nó đọc nữa. Mấy anh cứ chửi thằng Java verbose chứ codebase to lên tí thằng nào cũng quay đầu về với anh Java cả

Ông bạn h tranh luận có point hơn này +1

Tôi dùng Goland thấy khá ổn, refactoring cũng ngon mà sao ông bạn chê nhỉ? Nhiều người còn xài Vim nữa vẫn code ầm ầm.

Nếu stick vs Java, heavily dựa trên IDE và ideology của nó là mọi thứ đều phải là Object thì sẽ thấy khó chịu.

Nhưng ideology của Go là mọi thứ ko cần phải là Object, và interface thì chỉ nên định nghĩa ở lớp trên cùng của package, nơi mà cần phải giao tiếp với những package khác, nói chung nó khiến code đơn giản hơn và ko quá lạm dụng inheritance.

DI thì yeah, cũng có lúc thấy thiếu, cái này cũng là 1 khía cạnh khá controversial, vì argument là nếu structure ko phức tạp thì khỏi cần DI -> cũng hơi cảm tính.

Codebase thì tôi đã đụng vào mono-repo của Grab dùng Go, còn Java thì là mono-repo của Google, thì cảm thấy Google khó chịu hơn, vì Java có quá nhiều thứ behind the scene, đương nhiên là cảm tính thôi, bản thân 2 cty cũng khác nhau.

 

[tthixk]

Ông bạn h tranh luận có point hơn này +1

Tôi dùng Goland thấy khá ổn, refactoring cũng ngon mà sao ông bạn chê nhỉ? Nhiều người còn xài Vim nữa vẫn code ầm ầm.

Nếu stick vs Java, heavily dựa trên IDE và ideology của nó là mọi thứ đều phải là Object thì sẽ thấy khó chịu.

Nhưng ideology của Go là mọi thứ ko cần phải là Object, và interface thì chỉ nên định nghĩa ở lớp trên cùng của package, nơi mà cần phải giao tiếp với những package khác, nói chung nó khiến code đơn giản hơn và ko quá lạm dụng inheritance.

DI thì yeah, cũng có lúc thấy thiếu, cái này cũng là 1 khía cạnh khá controversial, vì argument là nếu structure ko phức tạp thì khỏi cần DI -> cũng hơi cảm tính.

Codebase thì tôi đã đụng vào mono-repo của Grab dùng Go, còn Java thì là mono-repo của Google, thì cảm thấy Google khó chịu hơn, vì Java có quá nhiều thứ behind the scene, đương nhiên là cảm tính thôi, bản thân 2 cty cũng khác nhau.

làm ở Grab thì có coding convention là ko dùng implicit interface như cách ông dùng trên kia mà nhỉ

cách implicit interface như ông làm 1 thằng khác ko biết add thêm 1 func vào interface đó là nát, điều thường xảy ra với team dev gần 1k người như Grab.

 

[trungpham90]

làm ở Grab thì có coding convention là ko dùng implicit interface như cách ông dùng trên kia mà nhỉ

cách implicit interface như ông làm 1 thằng khác ko biết add thêm 1 func vào interface đó là nát, điều thường xảy ra với team dev gần 1k người như Grab.

Sao nát đc, mono-repo mà, sửa 1 phát là biết ngay.

 

[ThuyMy]

Đọc bài của anh @gtunveteran làm tôi nghĩ ngay đến bài này
http://paulgraham.com/ds.html (btw chỉ là tranh luận trên mạng, anh không có thời gian đọc blog muốn do real thing thì tùy anh vậy).
Nhiều anh startup user còn chưa thấy đâu đã cầm đèn đi trước oto đổ tiền vô xây cơ sở hạ tầng, technical đủ thứ để phục vụ "tỉ người dùng". Những thứ này nó không hề free, đổi lại là thời gian deliver sản phẩm, thời gian maintain, tiền bạc, nhân lực... Bọn FAANG tự làm hàng inhouse vì đơn giản là nó có problem riêng và quan trọng là họ có thừa nhân lực để làm. Còn các anh startup học theo thì đếch khác gì solution looking for a problem (trừ phi cái solution đó là sản phẩm chủ lực của cái startup của nah).
Còn các anh startup tiền không có, nhân lực không có mà đòi làm hàng inhouse (để phục vụ tỉ người dùng) tôi nói thẳng là bullshit.
Thực tế thành công của startup nó đếch nằm ở yếu tố technical mà ở yếu tố thị trường. Đem tiền cho mấy anh "engineer" đi làm startup thì 10 anh hết 9 anh lo tìm cách build infrastructure phục vụ tỉ người dùng trong khi user thì chưa thấy đâu.
Thành công của VNG, của M$, của Google là họ tìm được thị trường và giành được nó trong 1 khoảng thời gian nhanh nhất có thể, đếch phải là vì họ build đc infrastructure phục vụ tỉ người dùng trong những ngày đầu . Việc scale lên chỉ là điều hiển nhiên khi họ tìm thấy thị trường, thấy tiền mà thôi.
Tôi không biết anh có phải là founder của cái startup mà anh đăng không, nếu phải thì tôi khuyên anh nên tập trung tìm khách hàng hơn là đi làm mấy thứ đốt tiền, đốt thời gian này. Còn ngược lại thì tôi nói thẳng anh chỉ là thằng engineer vẽ hươu vẽ vượn để đốt tiền bọn founder mà thôi

 

[naiveryan]

Comment của ông chung chung quá. Mind to elaborate? Việc lựa chọn trade off là chuyện bt của swe, làm j có solution hoàn hảo.

Từ đầu thấy bạn cứ đem cái Polymorphic Abstraction của Go đi khoe, nên tôi đang chỉ ra tại sao ko nên khoe đó.

Syntax và Type System ko phải là điểm mạnh của Go, Go mạnh cái khác. Ngta bảo tốt khoe xấu che, còn bạn đem cái xấu ra khoe ấy, cái Interface của Go là tổng hợp của Syntax xấu, Design ko tốt, Error prone mà bạn khoe làm gì.

 

[trungpham90]

Từ đầu thấy bạn cứ đem cái Polymorphic Abstraction của Go đi khoe, nên tôi đang chỉ ra tại sao ko nên khoe đó.

Syntax và Type System ko phải là điểm mạnh của Go, Go mạnh cái khác. Ngta bảo tốt khoe xấu che, còn bạn đem cái xấu ra khoe ấy, cái Interface của Go là tổng hợp của Syntax xấu, Design ko tốt, Error prone mà bạn khoe làm gì.

Ông bạn lại nói chung chung rồi, tôi thấy hay và tôi phân tích tại sao, ông chê chung chung như vậy thì nc j nữa?

 

[naiveryan]

ờ đúng rồi, ngoài tôi ra thì còn thằng nào viết wall of text nữa mà còn phải thắc mắc :-<
p/s: cơ mà tôi đíu hiểu lắm, cách comment của tôi ở diễn đàn quốc tế bình thường vkl, về việt nam toàn thấy bảo là hăng máu các kiểu.

Cũng ngờ ngợ you là Ser Nya, té ra nick mới chỉ là ít toxic hơn nick cũ -))

ờ có giai đoạn tôi cũng đéo thèm vào box cntt,

Tôi cũng nhiều khi chán cái box này vì kiến thức trong đây toàn như hàng dạt, toàn đại hiệp nói nhiều lan man nhưng nông cạn, đại đa số là junior nên ko muốn đáp.

 

[dangmt]

Tôi cũng nhiều khi chán cái box này vì kiến thức trong đây toàn như hàng dạt, toàn đại hiệp nói nhiều lan man nhưng nông cạn, đại đa số là junior nên ko muốn đáp.

Bạn vào box này thì trình độ của bạn cũng chẳng hơn gì Junior là mấy.

 

[naiveryan]

Ông bạn lại nói chung chung rồi, tôi thấy hay và tôi phân tích tại sao, ông chê chung chung như vậy thì nc j nữa?

Tôi chê có dẫn so sánh với implementation của các nn khác đó chứ chung chung gì, bạn chỉ thấy được flexibility của Go interface rồi tưởng hay lắm nhưng có thèm tìm hiểu nếu implicit define như vậy dẫn tới cái gì đâu.

À đây nè, đọc cái này đi rồi xem tại sao bọn strong typed lang khác vẫn phải explicit defined interface:
https://bluxte.net/musings/2018/04/10/go-good-bad-ugly/

 

[trungpham90]

Tôi chê có dẫn so sánh với implementation của các nn khác đó chứ chung chung gì, bạn chỉ thấy được flexibility của Go interface rồi tưởng hay lắm nhưng có thèm tìm hiểu nếu implicit define như vậy dẫn tới cái gì đâu.

À đây nè, đọc cái này đi rồi xem tại sao bọn strong typed lang khác vẫn phải explicit defined interface:
https://bluxte.net/musings/2018/04/10/go-good-bad-ugly/

Những cái Bad trong bài:

• finding what types implement a given interface is hard as it relies on function definition matching. I often discover interesting implementations in Java or Scala by searching for classes that implement an interface.
• when adding a method to an interface, you will find what types need to be updated only when they are used as values of this interface type. This can go unnoticed for quite some time. Go recommends to have tiny interfaces with very few methods, which is a way to prevent this.
• a type may unknowingly implement an interface because it has the corresponding methods. But being accidental, the semantics of the implementation may be different from what is expected from the interface contract.

Pros and Cons thôi, trích lại post tôi ở trên:

ideology của Go là mọi thứ ko cần phải là Object, và interface thì chỉ nên định nghĩa ở lớp trên cùng của package, nơi mà cần phải giao tiếp với những package khác, nói chung nó khiến code đơn giản hơn và ko quá lạm dụng inheritance mà khuyến khích dùng composition.

DI thì yeah, cũng có lúc thấy thiếu, cái này cũng là 1 khía cạnh khá controversial, vì argument là nếu structure ko phức tạp thì khỏi cần DI -> cũng hơi cảm tính.

Như nhiều bài tôi đã viết ở trên, thực ra trong bài cũng nói, Go ko đẹp, mà đơn giản, phù hợp vs microservices, dev ko cần quá chú trọng đến những tính năng fancy mà focus vào getting the shit done. Nói thế để ông bạn hiểu tại sao tôi đánh giá cao tính năng đó, nó phải ở trong context.


https://softwareengineering.stackex...-with-implicit-interfaces-and-how-does-that-c

Đây, answer này rất đúng ý tôi:

The consequences of implicit interfaces are a few things.

• Accidental interface implementation, this can be a happy accident, or an accidental LSP violation by meeting someone else's interface which you didn't intend to while not honoring the intent of it's contract.
• The ability to easily make any method accept a mock of any given object at all by simply mirroring that objects interface (or even just creating an interface that meets that methods requirements and no more).
• The ability to create adapters or other various similar patterns with more ease in regards to objects you can't meddle at the innards of.
• Delay interface implementation, and implement it later without having to touch the actual implementation, only implementing it when you actually want to create another implementor.

 

[naiveryan]

Những cái Bad trong bài:



Pros and Cons thôi, trích lại post tôi ở trên:

ideology của Go là mọi thứ ko cần phải là Object, và interface thì chỉ nên định nghĩa ở lớp trên cùng của package, nơi mà cần phải giao tiếp với những package khác, nói chung nó khiến code đơn giản hơn và ko quá lạm dụng inheritance mà khuyến khích dùng composition.

DI thì yeah, cũng có lúc thấy thiếu, cái này cũng là 1 khía cạnh khá controversial, vì argument là nếu structure ko phức tạp thì khỏi cần DI -> cũng hơi cảm tính.

Như nhiều bài tôi đã viết ở trên, thực ra trong bài cũng nói, Go ko đẹp, mà đơn giản, phù hợp vs microservices, dev ko cần quá chú trọng đến những tính năng fancy mà focus vào getting the shit done. Nói thế để ông bạn hiểu tại sao tôi đánh giá cao tính năng đó, nó phải ở trong context.


https://softwareengineering.stackex...-with-implicit-interfaces-and-how-does-that-c

Đây, answer này rất đúng ý tôi:

The consequences of implicit interfaces are a few things.

• Accidental interface implementation, this can be a happy accident, or an accidental LSP violation by meeting someone else's interface which you didn't intend to while not honoring the intent of it's contract.
• The ability to easily make any method accept a mock of any given object at all by simply mirroring that objects interface (or even just creating an interface that meets that methods requirements and no more).
• The ability to create adapters or other various similar patterns with more ease in regards to objects you can't meddle at the innards of.
• Delay interface implementation, and implement it later without having to touch the actual implementation, only implementing it when you actually want to create another implementor.

Hình như bạn nhầm lẫn tôi với ai đó hay đọc sót gì ở đây thì phải.

Tôi đã nói về Polymorphic Abstraction và triết lý prefer composition over inheritance ngay từ đầu và dẫn ra một loạt ngôn ngữ khác đều promote cái triết lý đó. Và bọn nn đó cũng đầy đủ đồ chơi để làm được, code còn elegance hơn Go nhiều. Vậy nên nhắc lại là cái interface của Go là cái đi sau, chẳng có gì mới mẻ mà bạn cứ khăng khăng như Go sáng tác ra nó ấy.

Cái khác biệt là Go thì implicit define, tức là bạn ko cần tag hay ghi rõ interface signature vào chỗ implementation thôi, chứ purpose của nó ko khác gì Trait/Typeclass/Interface của bọn kia cả.

Và implicit nó dẫn đến những bug ko báo trước hoặc function ko mong muốn (accidental interface implementation như trên kia nói). Bạn kéo xuống mà đọc về 2 cái bug Nil value và data race kia kìa.

Tôi chẳng nói về Inheritance, DI, hay object gì ở đây cả mà bạn dẫn ra làm gì? Nói để biết thêm, tôi là anti-fan của OOP nên bạn k cần phải lo mấy thứ đó.

 

[trungpham90]

Hình như bạn nhầm lẫn tôi với ai đó hay đọc sót gì ở đây thì phải.

Tôi đã nói về Polymorphic Abstraction và triết lý prefer composition over inheritance ngay từ đầu và dẫn ra một loạt ngôn ngữ khác đều promote cái triết lý đó. Và bọn nn đó cũng đầy đủ đồ chơi để làm được, code còn elegance hơn Go nhiều. Vậy nên nhắc lại là cái interface của Go là cái đi sau, chẳng có gì mới mẻ mà bạn cứ khăng khăng như Go sáng tác ra nó ấy.

Cái khác biệt là Go thì implicit define, tức là bạn ko cần tag hay ghi rõ interface signature vào chỗ implementation thôi, chứ purpose của nó ko khác gì Trait/Typeclass/Interface của bọn kia cả.

Và implicit nó dẫn đến những bug ko báo trước hoặc function ko mong muốn (accidental interface implementation như trên kia nói). Bạn kéo xuống mà đọc về 2 cái bug Nil value và data race kia kìa.

Tôi chẳng nói về Inheritance, DI, hay object gì ở đây cả mà bạn dẫn ra làm gì? Nói để biết thêm, tôi là anti-fan của OOP nên bạn k cần phải lo mấy thứ đó.

Implicit interface thì nó UT dễ hơn, vs các package có thể phát triển song song mà ko quá dependent vào nhau, đó là cái hay tôi thấy, còn cái prefer composition over inheritance là cái cơ bản cmnr rồi, tôi có bàn về interface vs OOP đâu mà ông nêu ra như đúng rồi. Java tôi code 12 năm rồi, còn lạ lol j nữa?