Tối giản việc đọc tin nổi bật, comment chất lượng nhiều reaction trên voz cho các fen bận rộn.

VozFen.com: [thảo luận] Tất tần tật về Go (Golang)

@pi nguyen Joined: 12/2017
#1
Ưng 1

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

Fi…
Fire Of Heart

@Fire Of Heart
#11
Ưng 8
Go mạnh lắm. Bạn nào mới ra trường nên theo.
Khuyên chân thành đấy.
Mình làm c++ lâu, cũng phải bỏ để qua golang

Fi…
Fire Of Heart

@Fire Of Heart
#13
Ưng 53
Gạch 1
Vàng quan điểm
Rảnh rảnh type vài dòng cho các bác:

Ưu điểm của Go:
1. Code dễ đọc, dễ hiểu.
2. Go compiler mang lại nhiều thông tin có để giải quyết các vấn đề thay vì những output vô nghĩa.
3. Go code portable
4. Hỗ trợ concurrency, distributed programming.
5. Support Garbage collection. Được thiết kế khá nhanh chứ ko chậm chạp như GC của java.
6. Ko có preprocessor, tăng tốc độ khi compile chương trình.
7. Có thể build web app.
8. Bộ thư viện chuẩn của Go cung cấp nhiều library cho phép làm việc dễ dàng.
9. Sử dụng static linking by default. Ko cần quan tâm tới library, different version v.v...
10. Support Unicode
(cái này mình đọc sách nhiều nên biết thôi :sexy

Tất nhiên ko có ngôn ngữ nào là hoàn hảo, quan trọng là mục tiêu khi người ta xây dựng ngôn ngữ đó là gì.
Ví dụ như Go thì ko có OOP, có thể gọi là ko trực tiếp support OOP thì chính xác hơn.
Về tốc độ thì mình nghĩ Go vẫn ko thể nhanh hơn C dc, đơn giản là Unix viết bằng C.

Nhưng dù sao Go là một ngôn ngữ hiện đại, dễ học, dễ nắm bắt, dễ viết.

Để học syntax 1 ngôn ngữ thì rất dễ, python hay Java thì chắc ngồi vài hôm là xong. Nhưng để thực sự "đào sâu" vào ngôn ngữ đấy, thì mình nghĩ các bác cần nhiều thời gian hơn rất nhiều.
Có thể mất cả năm trời để hiểu rõ dc các cơ chế hoạt động phía dưới của ngôn ngữ, sử dụng một cách thông thạo, code đẹp đẽ tối ưu.
Do tính chất công việc hiện nay nên đa phần nhiều người ko đạt dc tới level đó và cũng ko coi việc đó là quan trọng, với mình đó là 1 điều đáng buồn.

Các bác chỉ có thể code 1 cách tối ưu khi các bác hiểu rõ ngôn ngữ đó hoạt động như thế nào.

9a…
9a1phu

11/2011

@9a1phu 11/2011
#28
Ưng 4
Gạch 1
Rảnh rảnh type vài dòng cho các bác:

Ưu điểm của Go:
1. Code dễ đọc, dễ hiểu.
2. Go compiler mang lại nhiều thông tin có để giải quyết các vấn đề thay vì những output vô nghĩa.
3. Go code portable
4. Hỗ trợ concurrency, distributed programming.
5. Support Garbage collection. Được thiết kế khá nhanh chứ ko chậm chạp như GC của java.
6. Ko có preprocessor, tăng tốc độ khi compile chương trình.
7. Có thể build web app.
8. Bộ thư viện chuẩn của Go cung cấp nhiều library cho phép làm việc dễ dàng.
9. Sử dụng static linking by default. Ko cần quan tâm tới library, different version v.v...
10. Support Unicode
(cái này mình đọc sách nhiều nên biết thôi :sexy

Tất nhiên ko có ngôn ngữ nào là hoàn hảo, quan trọng là mục tiêu khi người ta xây dựng ngôn ngữ đó là gì.
Ví dụ như Go thì ko có OOP, có thể gọi là ko trực tiếp support OOP thì chính xác hơn.
Về tốc độ thì mình nghĩ Go vẫn ko thể nhanh hơn C dc, đơn giản là Unix viết bằng C.

Nhưng dù sao Go là một ngôn ngữ hiện đại, dễ học, dễ nắm bắt, dễ viết.

Để học syntax 1 ngôn ngữ thì rất dễ, python hay Java thì chắc ngồi vài hôm là xong. Nhưng để thực sự "đào sâu" vào ngôn ngữ đấy, thì mình nghĩ các bác cần nhiều thời gian hơn rất nhiều.
Có thể mất cả năm trời để hiểu rõ dc các cơ chế hoạt động phía dưới của ngôn ngữ, sử dụng một cách thông thạo, code đẹp đẽ tối ưu.
Do tính chất công việc hiện nay nên đa phần nhiều người ko đạt dc tới level đó và cũng ko coi việc đó là quan trọng, với mình đó là 1 điều đáng buồn.

Các bác chỉ có thể code 1 cách tối ưu khi các bác hiểu rõ ngôn ngữ đó hoạt động như thế nào.
Bữa cty mình có 1 case hài vl, má nào code Go sài ko đóng transaction hay sao ấy, nó lên connection poll . Sập,
Nói chung Go nó tường mình rõ ràng nhưng code cũng tỉ mỉ tí là OK. Chứ mấy cái vụ transaction bên thằng Hibernate nó lo cho rồi.

lo…
longkim1508

@longkim1508
#35
Ưng 7
Ko biết rust với swift cho hỏi go nó thiếu gì vậy
Cái cơ bản nhất là generic (có vẻ version 2 sẽ có, ngon hay k thì k chắc lắm)
Thiếu kiểu result (năm 2020 rồi gọi hàm vẫn trả về cái err và phải check nil haha)
Ko có kiểu optional
Thiếu nhiều hàm xử lý sequence (map filter reduce...)
Polymorphism ở runtime (rust có traits, swift thì xài protocol ở compile time) do hệ thống typing sida. B có thể thấy dev go abuse cái interface{} ntn.
Cá nhân mình thấy go giống như ngôn ngữ giúp các dev js / python code ra phần mềm nhẹ và nhanh hơn, chứ ko có j nổi trội.

Fi…
Fire Of Heart

@Fire Of Heart
#39
Ưng 16
Vàng quan điểm
Tôi giờ ngày nào cũng tự nhủ, ráng mỗi ngày try-hard golang thêm vài tiếng (bên cạnh việc công ty).
Bao gồm đọc sách, code side project, học thêm về distributed system, database.

Cố gắng 1-2 năm nữa lên pro, hy vọng dc lương 4-5k là ổn, khỏi cần ra nước ngoài nữa.

Chắc phải bỏ bớt thú vui gái gú, chơi game lại T_T

Ni…
Nipin

03/2018

@Nipin 03/2018
#47
Ưng 13
Mấy thằng như lazada hay tiki lúc nó có cả chục triệu user, tiền như núi rồi nó mới tính viết lại một số service bằng java, chứ startup các kiểu có thần kinh mới dùng java. Mà tôi thấy nó đổi sang java/c# chủ yếu là risk management (tìm lập trình viên java/c# thay thế mà chất lượng đạt chuẩn dễ hơn nhiều mấy thằng kia) chứ đếch phải performance hay ecosystem như mấy bạn nói.

Quay lại với Go hay Dart, tôi thấy cũng có tranh cãi khá nhiều. Thằng thì bảo mấy ngôn ngữ được backup bởi google, đã có vài triệu dòng code google dùng in house rồi thì sợ gì không có tương lai.
Thằng khác thì bảo chính là google nó mới có vấn đề: google hay đem con bỏ chợ không nói, vấn đề lớn nhất là core maintainers của go/dart là nhân viên google chứ không phải là cá nhân tự do. Tuy việc này khiến golang/dart phát triển nhanh hơn, nhưng cũng đồng nghĩa với việc ngôn ngữ đó nó phát triển theo nhu cầu của google chứ không phải là của cộng đồng (vụ generic của golang là điển hình cho vụ này), một lúc nào đó nhu cầu của google nó không phù hợp với nhu cầu chung của cộng đồng nữa thì sẽ có nhiều thứ nhiêu khê (và tín dụng của google cho vụ này thường là....)

mà tương lai ở đây nói là tương lai tươi sáng, chứ tương lai thường thường thì viết COBOL hay PASCAL đều có tương lai hết, lương cao việc không thiếu

Tr…
TrangTraiCoDon

04/2016

@TrangTraiCoDon 04/2016
#48
Ưng 4
https://topdev.vn/blog/tai-sao-team-discord-chuyen-tu-go-sang-rust/
Nói chung chả có ngôn ngữ nào là hoàn hảo
Nói chứ sinh viên trường được dạy C++ thì cứ ràng mà nắm C++. Học xong chuyển sang Go hay Rust 1 nốt nhạc...
Có cái cc mà chuyển sang rust 1 nốt nhạc

Ni…
Nipin

03/2018

@Nipin 03/2018
#57
Ưng 4
Gạch 1
Mình ko đồng ý lắm với những gì bạn nói. Với các công ty lớn thì phần mềm ngoài chức năng ra thì nó còn phải yêu cầu là ổn định và an toàn. Với Java thì phần lớn xài framework. Phần ổn định và an toàn được framework đảm bảo nên công việc của dev rất nhẹ nhàng. Những ngôn ngữ khác khó mà bằng nếu ecosys ko tốt.
Để dễ hiểu thì coi như dev là tài xế. Rõ ràng là lái xe tự động dễ dàng hơn nhiều so với lái xe số. Càng tự động nhiều càng nhàng.
lý luận java stable là do framework nó nhảm vkl.
còn ecosystem, rất nhiều công ty lớn nó có policy là NIH (not invented here), ecosystem to hay nhỏ ý nghĩa không lớn.
(mấy cái framework/library ngon các bạn khen nức nở theo các bạn nghĩ là từ đâu mà có, tự dưng từ trên trời rơi xuống à?)

mà thôi các bạn thích java/thích dùng java thì cứ việc thích, có ai cấm. tôi hoàn toàn đéo có hứng thú với java cũng như mấy thằng java fanboy, cho nên mạn phép tôi đưa các bạn vào ignored list, về sau đỡ phải mất thời gian của nhau

lu…
luanducgk

08/2012

@luanducgk 08/2012
#61
Ưng 5
^
Lazada, vứt sạch backend Go cũ chuyển hết sang Java.
Tiki đập một mớ cũ rewrite lại + build mới một loạt bằng Java.

Chắc vẫn nhỏ, không bì với unicorn được

Mình quen ông anh ở tiki, ông ấy bảo đập hết java đi làm lại bằng golang mà. Bác có nói ngược không vậy.

via theNEXTvoz for iPhone

Ik…
Ikeda

@Ikeda
#67
Ưng 9
voz chửi mạnh thế này thì chủ thớt biết tương lai của go rồi đó ...

lo…
lorddarkness

04/2011

@lorddarkness 04/2011
#70
Ưng 6
Gạch 1
Mấy bạn chưa bao giờ làm Java hay lỡ cỡ rồi nhảy sang cái khác luôn ác cảm vì cho rằng Java nó cùi, chậm, dài dòng... Blabla nhưng đâu có biết Java nó luôn tiến hoá để adapt với modern software development.

Tôi dùng cả Go cả Java cho hệ thống bên tôi, ngày trước tôi rất thích Go ở chỗ lightweight phù hợp với môi trường serverless nhưng dạo này Java có GraalVM thì ngon lắm rồi. Tương lai nếu Go k phát triển hơn thì mấy thế mạnh hiện tại sẽ bị thằng Java nó cắn mất. Chắc luôn
Mình nghĩ java cần phải làm nhiều nữa mới có thể cắn thị phần của Go ở mảng infras (đặc biệt là k8s)
+ build time + binary size + build tools/process/dependencies manager: Go build ra fat binary vs tốc độ khá nhanh, quản lý dependencies vs Go module giờ khá tiện nữa so với việc config/quản lý lằng nhằng của java (maven, gradle, ant)
+ memory footprint: GraalVM giúp Java app giảm khá nhiều memory footprint khá nhiều vs native image rồi nhưng vẫn nhiều hơn so vs Go
+ faster start up times: cái này đặc biệt giúp scale app nhanh khi dùng vs HPA
+ cgroups awareness: config/optimize cho JVM based app cũng là một vấn đề để tránh OOM kill, tuy đã hỗ trợ khá ok vs hotspot rồi nhưng đạt đến mức perfect thì chưa
+ GraalVM được develop bởi Oracle, mà mình thì éo ưa + tin tưởng Oracle lắm sau mấy vụ license

Tuy nhiên mấy thằng lớn contribute khá nhiều vô cloud native (ngoài 3 ông lớn Google, AWS, Azure) như RedHat (IBM), OpenSUSE, ... cũng đầu tư nhiều vô Java để giúp nó cloud native hơn nên mình nghĩ trong tương lai sẽ có nhiều hướng để làm vs cloud tùy theo hướng/ngôn ngữ mình thích

tr…
trungpham90

07/2012

@trungpham90 07/2012
#158
Ưng 4
Thế còn bản thân cái ngôn ngữ thì sao
http://tmikov.blogspot.com/2015/02/you-dont-like-googles-go-because-you.html.
Ngôn ngữ càng bị chửi nhiều chứng tỏ là càng nhiều người dùng, chuyện quá bt.

Chửi 1 ngôn ngữ thì phải nói được use case của các bạn là j. Kn của tôi maintain critical backend microservices, qps 20k chạy ngon trên cluster 80 instances, mỗi ngày xử lý gần 10 triệu transaction, weekly deployment ầm ầm.

Đội dev nhiều người, cần collab nhiều, thì ngôn ngữ nó phải đơn giản, hạn chế những tính năng hack não để tập trung vào dev business feature. Còn 1 người, 1 service thì code go thấy thiếu thiếu, gượng gượng rồi chửi, tôi nghĩ chắc cũng bt.

Use the right tool for the right job. Vậy job của bạn là j? Mà chỉ thấy bàn về tool?

gt…
gtunveteran

@gtunveteran
#159
Ưng 4
ed của crystal hay nim ăn đứt go, vì chúng nó backend là LLVM/GCC (nim thì transpile sang c, lúc đó thì dùng clang hay gcc để compile đều được, crystal thì transpile sang llvm opcod
Thế còn bản thân cái ngôn ngữ thì sao
http://tmikov.blogspot.com/2015/02/you-dont-like-googles-go-because-you.html.
Team mình có những thành viên xây dựng hệ thống cho zalo với zing từ ngày đầu nhé, stack của bọn mình là layer storage c++ ( cái này không ngôn ngữ nào có thể thay thế rồi) , service ( golang is best choice), frontend reactjs. Đây là 1 dự án của bọn mình nhé https://butta.vn/ . Ns chung mảng backend có những cái buộc phải dùng c++ thì ngoài ra dùng golang là best choice , trước mình cũng dev .NEt suốt nhưng h dị ứng với mấy cái máy ảo lắm rồi.

gt…
gtunveteran

@gtunveteran
#162
Ưng 12
Thế còn bản thân cái ngôn ngữ thì sao
http://tmikov.blogspot.com/2015/02/you-dont-like-googles-go-because-you.html.
Ngồi đọc blog làm cái quái j, đào sâu suy nghĩ về 1 một ngôn ngữ đi, giải quyết các vấn đề của n là được, ngồi nghe mấy thằnd lập trình viên chém gió khác j đẽo cày giữa đồng đâu. Quan trọng mình cần với công việc thế nào, như t , thấy n cực kì hợp lí, n không cần một cái layer trung gian runtime để chạy là 1 lợi thế cho deploy rất tốt rồi, tiếp đến n build rất nhanh ( điều mà c,c++ ko làm được). Cái nữa là việc import thư viện cực kì đơn giản, khác hẳn với c,c++. Một ngôn ngữ giải quyết được vấn đề về portable, deploy, build thì đó là 1 ngôn ngữ tốt. Các hạ tầng bây h chạy theo microservice, phân chia ứng dụng theo chiều ngang chứ ko còn kiểu stacklayer như trước kia, tóm lại chỉ gồm 3 phần layer rõ ràng , low layer ( liên quan tới hệ thống, lưu trữ, ở đây người ta thường dùng c/c++, các hệ quản trị cơ sở dữ liệu hay nosql đều viết bằng c++ hết), tiếp theo layer service ( go được thiết kế với layer service này , tạo các api bằng beego quá nhanh quá gọn, toàn bộ func cho api quảng trị người dùng t có thể viết trong 2 tiếng đổ lại chỉ bằng beego, cần giao tiếp với lowlayer thì sử dụng thrift cực kì nhanh và ổn định), layer UI,UX là cuộc chơi của các lib hay framework js rồi ko phải bàn. Trong trường hợp có những service cần giữ các connection để realtime thì đã có websocket ( golang có hỗ trợ nhé ), và đặc biệt grpc là thứ được sử dụng nhiều nhất trong các kết nối kiểu này ( phần OTT cty t dùng grpc full). Bảo golang là best choice cho starup hoàn toàn có cơ sở vì những tính năng n đem lại, toàn bộ hệ thống OTT, chat ,video call, socialnetwork, livestream ,notification của cty đều được build up theo kiến trúc microservice với bộ 3 c++, golang , js, hệ thống luôn mượt mà và trơn chu nhé, khả năng mở rộng tới hàng tỉ user còn được ( đó là thế mạnh của microservice)

dr…
dreamnight

06/2008

@dreamnight 06/2008
#163
Ưng 5
Ngôn ngữ càng bị chửi nhiều chứng tỏ là càng nhiều người dùng, chuyện quá bt.

Chửi 1 ngôn ngữ thì phải nói được use case của các bạn là j. Kn của tôi maintain critical backend microservices, qps 20k chạy ngon trên cluster 80 instances, mỗi ngày xử lý gần 10 triệu transaction, weekly deployment ầm ầm.

Đội dev nhiều người, cần collab nhiều, thì ngôn ngữ nó phải đơn giản, hạn chế những tính năng hack não để tập trung vào dev business feature. Còn 1 người, 1 service thì code go thấy thiếu thiếu, gượng gượng rồi chửi, tôi nghĩ chắc cũng bt.
Use the right tool for the right job. Vậy job của bạn là j? Mà chỉ thấy bàn về tool?

Đồng ý với bạn này.

Thật ra để hỏi ngôn ngữ XYZ nào tương lai sáng không thì chả có một cái foresee nào đủ mạnh để xác thực cả đâu.
Mình lấy ví dụ một ngôn ngữ đã có thời là hot trend nhé: Ruby on Rail. Cách đây 8-10 năm trước thì nó khá hot vì build nhanh một cái web trên nền MVC. Rồi lương ở VN cho Ruby vì thế tăng ào ào trong giai đoạn 2011-2015, nếu không nói quá giai đoạn đó nhiều cty sẵn sàng trả mức lương 1k$ cho người chỉ biết 1 năm exp, nhưng rồi cũng theo thời giai người ta lại nhảy ra chuyển qua Node, giờ nhìn lại thị trường còn bao nhiêu cty ở VN đang hunt Ruby đâu.

Thế nhưng những người giỏi Ruby ở giai đoạn đó thì sao? Không lẽ chết đói? Câu trả lời không đâu, người giỏi người ta lựa chọn ngôn ngữ vì sở thích nhưng kiến thức mới là thứ họ xây dựng. Chủ topic có sài XYZ ngôn ngữ nào, làm dự án nào nhưng tất cả đều xoay quanh kiến thức IT chung cả thôi, đó mới là thứ giúp bạn kiếm ra tiền, chứ kn viết một ngôn ngữ ko giúp bạn đi xa được.

Th…
ThuyMy

@ThuyMy
#171
Ưng 10
Chi tiết nhỏ thôi, nhưng làm mới thấy có giá trị.
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 )

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:

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 ?).

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:


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ả

Th…
ThuyMy

@ThuyMy
#212
Ưng 12
Đọ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

Th…
ThuyMy

@ThuyMy
#226
Ưng 6
Mấy bố VNG có tiếng khổ dâm từ xưa rồi mà, cái gì cũng muốn tự build mà tôi thấy cũng k có gì xuất sắc

Ngày xưa thời 2008 - 2009, tôi mấy lần đi nghe mấy lão Thanh, Thành... chém gió thấy khoe build DBMS, rồi build memory storage, rồi build proxy... các kiểu thấy cũng thường. Tôi thấy lấy hàng opensource về tuning chưa cần custom chạy cũng ngon y chang méo khác gì ))
Thật chất là mấy thứ đó gần như đã mature hết rồi. Hàng có sẵn thì cũng toàn là guru top tier dành cả đời để optimize, các anh bảo nhu cầu của anh "đặc thù" đến nỗi phải tự build riêng thì nói thẳng là nói phét. Hồi đó tôi cũng rãnh rỗi nghiên cứu bên trong proxy, rdbms có gì ... thì cũng sớm nhận ra hàm lượng chất xám trong đó là vô cùng lớn, nếu cty anh đếch chuyên về lĩnh vực đó thì trình anh đếch đủ, nhân lực anh cũng đếch đủ mà tự build riêng, còn thật sự đặc thù thì thuê bọn đó về tư vấn có khi còn kinh tế hơn là xây dựng solution nữa vời đếch đến đâu.
Văn hóa của bọn FAANG là tiền không thiếu, nhân lực không thiếu, nó dư tiền đốt để experiment mọi thứ.
Thị trường VN nói nhỏ thì không nhỏ nhưng so với bọn FAANG thì như cái móng tay, bọn VNG khoe tự build này nọ tôi nói thẳng cũng để thủ dâm tinh thần là chính (và các anh dev VNG đời đầu thì tôi lại càng nghi ngờ khi lưu password dưới dạng plaintext), trình các anh có cao đến mấy thì cũng đếch có cửa so với bọn dành cả đời để optimize sản phẩm của họ cả

gt…
gtunveteran

@gtunveteran
#247
Ưng 4
Đéo ưa cái tính hống hách dev nhà VNG nhưng tôi khẳng định Zalo là ứng dụng mess phổ biến hàng đầu VN. Voz ít ai chê zalo giật lag thế là ngon rồi mặc kệ hàng tự build hay tha từ tàu về
Toàn bộ backend là người việt hàng việt nhé, FE ko làm nên ko rõ, thực ra làm FE cũng khó khăn j đâu, nhiều bố coi thường trình dev việt nam mình quá, cỡ giao diện như Zalo , ko thiếu những team làm được, quan trọng là perfomance có đáp ứng được như vậy không, performance n liên quan tới backend là chính, và confirm là dùng hàng nhà trồng nhé ( tất nhiên có sử dụng opensource rồi ) . Mấy con bò trên tinhte đã ngu ko biết j lại còn phán dùng hàng Tàu. Cái j là tàu có thể chứ riêng phần mềm, các team việt nam hoàn toàn làm chủ được nhé, ở vn mình chỉ yếu trong việc tự build các lib hay xây dựng một nền tảng riêng, cái mảng đó phương Tây là trùm cmnr

Th…
ThuyMy

@ThuyMy
#248
Ưng 5
Nói chung là cái tôi của các anh dev khá lớn (nhất là mấy anh dev C, C++, ngôn ngữ càng low level thì cái tôi càng lớn) nhưng tầm nhìn thì thiếu đầu óc thực dụng. Các anh có trình độ đấy nhưng nhân lực, trình độ thì so thế đéo nào được bọn opensource. Thành ra sản phẩm mấy anh làm ra vừa phí công mà chất lượng cũng đếch hơn được bọn os là bao. Các anh tự hào sp các anh scale tỉ người dùng, dùng hàng os không đáp ứng nổi thì các anh đã benchmark chưa, có chịu khó tuning thử chưa hay lại là IKEA effect in play
Thuê 1 thằng có đầu óc practical build sản phẩm có khi còn tiết kiệm chi phí hơn
Tôi không chê dev Zalo cùi, không tự build đc sản phẩm in house ngon mà tôi chỉ chê họ rỗi hơi, bày vẽ đủ trò cho non-existent problem để rồi vừa tốn thời gian mà làm ra đc sản phẩm cũng inferior hơn bọn os. Mà đó là do họ dư tiền, dư nhân lực, vẽ ra hay bớt đi cũng không ảnh hưởng gì đến hòa bình thế giới. Còn các anh startup cũng bày đặt đi đú theo thì đúng là nhà nghèo học theo nhà giàu tiêu tiền
Tôi có 1 thuyết âm mưu là cái trò microservices là do bọn cloud provider nghĩ ra để dụ các anh startup đốt tiền .Đếch phải khi không tự nhiên mấy năm gần đây nhà nhà, người người ai cũng đòi microservices, ai cũng muốn sản phẩm của mình scale đến tỉ người dùng

Fi…
Fire Of Heart

@Fire Of Heart
#258
Ưng 5
Thôi để nào rảnh tôi làm 1 bài về microservice và monolithic cho các anh vào chém.

#A…
#Anh BeDe Za Den Hose#

@#Anh BeDe Za Den Hose#
#264
Ưng 4
làm golang viết web app cực vl, chả có cái ORM nào ngon để xài với postgres. viết API mà toàn phải tự viết tay từ handler tới middleware này nọ. viết sang mấy cái khác thì cũng hầu hết tự code do spirit của community golang không thích framework.

dòm sang rails hay mới đây là phoenix (elixir) thì thấy golang chỉ sẽ mãi bì bõm trong đống microservices là hết vì ko có văn hoá framework/ opensource, quá ít tooling xung quanh như javascript/ rails...

tr…
trungpham90

07/2012

@trungpham90 07/2012
#290
Ưng 13
Vàng quan điểm
Mấy thím trên này bao nhiêu tuổi ròi mà kinh nghiệm nhiều vậy. Lại toàn làm cty lớn, product lớn.

30, cựu tl Grab, h là Googler

toàn trẻ trâu xl thôi bạn, thông cảm, xã hội chèn ép, lên mạng xl tí thôi, đừng khó khăn quá.

Ko những xl, còn viết hẳn blog để xl https://medium.com/@phamtrung/google-the-complete-interview-journey-dd87419bc229
Ae đọc thấy hay cho xin vài clap

tr…
trungpham90

07/2012

@trungpham90 07/2012
#297
Ưng 4
Thanh niên đó nền tảng cũng tốt mà, học ở Sing, làm ở Sing.
Vậy mà còn fail mấy lần mới pass dc.
Mình cũng fail amazon 1 lần, tới round cuối rồi ^^
để nào train pv lại chứ dạo này ko có nhu cầu nhảy việc lắm ^^
PV Amazon thì nên tập trung vào Leadership principle (LP), mỗi principle nên có 1 câu chuyện để demonstrate theo Star format (Situation-Task-Action-Result). Amz nó coi trọng behaviour hơn, vì nó nghĩ là tech thì train đc, còn behaviour thì ko. Còn tech thì chỉ cần vững, ko quá thọt là đc.

Vào Google thì hên xui khá nhiều, vì tỷ lệ chọi quá cao, và Google khá bảo thủ trong việc tuyển người.

tr…
trungpham90

07/2012

@trungpham90 07/2012
#305
Ưng 5
hehe trước đó đã đọc qua bài viết của bác rồi, ko ngờ Googler cũng chơi voz Bài viết bác làm động lực cho e mỗi ngày cày LC, HR đó, với bài của anh này nữa https://medium.com/@XiaohanZeng/i-i...-and-luckily-got-five-job-offers-25178cf74e0f
Tài khoản Đã tốn tiền, sao bỏ đc

Be…
BetterNextTime

@BetterNextTime
#341
Ưng 5
Bạn @weedvnz giải thích sai rồi.
  • Ở ví dụ đầu tiên, main thread sẽ block đến khi nào channel done có output -> Sai, main thread block đến khi nào có nhận đc value đầu tiền từ done channel hoặc done channel bị closed.
  • Deadlock là vì trong goroutine worker gửi 3 tới channel num mà không có receiver wait for message (num là unbuffered channel nên goroutine worker bị blocked, trong khi trong main thread thì bị blocked vì waiting for data from done channel, vì vậy mới ra deadlock (both threads are waiting for each other)

Code:
working...done
fatal error: all goroutines are asleep - deadlock!

goroutine 1 [chan receive]: <- receiver bị block
main.main()
/tmp/sandbox835183100/prog.go:24 +0xa5

goroutine 6 [chan send]: -> sender bị block
main.worker(0xc00005e060, 0xc00005e0c0)
/tmp/sandbox835183100/prog.go:13 +0xf8
created by main.main
/tmp/sandbox835183100/prog.go:22 +0x89

Program exited: status 2.

Be…
BetterNextTime

@BetterNextTime
#345
Ưng 7
Nếu bạn muốn học go thì nên học dần dần như thế này:

Be…
BetterNextTime

@BetterNextTime
#348
Ưng 4
Dùng cho dự án microservices thì Gin, Echo hay GoKit ngon hơn hở bác?

Tuỳ theo dự án nhé.
Nếu dự án chỉ là
  • CRUD API
  • Simple logic
  • Proxy server only
Thì dùng gin hoặc echo đều được

Nếu dự án chia nhiều layer và
  • Access external API
  • API logic phức tạp (using multiple datasources hoặc có background task)
Thì dùng Gokit tốt nhé

Thực ra mình vẫn khuyên nên dùng go-kit. Lí do là vì nó có sẵn layer structure nên mình adapt vào dễ. Còn gin và echo viết dễ nhưng sau này cần phát triển lên cho team nhiều người cần có convention chung để maintain, lúc đó sẽ vất vả hơn go-kit

Gu…
Guardiann

@Guardiann
#401
Ưng 10
Gạch 9
Ngược dòng
Mình tính sau làm dev backend nhưng muốn học mấy cái mới mới như python và golang để apply vào mấy cty product như Gotit thì có trung tâm nào uy tín dạy mấy cái đó không?
Cám ơn mọi người

Mình ở hà nội thì cũng tìm 1 số trung tâm như
techmaster, hvit nhưng mà sao cảm giác giảng viên không được giỏi lắm
Ngành này 120 IQ trở lên thì fen theo nha )

De…
DeathEater

@DeathEater
#443
Ưng 4
Sếp có chỉ thị học go để làm việc với bên backend go, cả team cùng bắt đầu học
frontend với backend giao tiếp với nhau qua API, thì qtam làm gì backend viết bằng ngôn ngữ nào. Đi bắt mấy thằng frontend học golang làm gì , sếp gì xàm vđ

Be…
BetterNextTime

@BetterNextTime
#482
Ưng 6
Thím có project mẫu nào để học theo không nhỉ?

Trước giờ toàn code Java, Kotlin sang Go thấy thọt thọt chưa quen khó chịu quá.
Project mới bắt buộc dùng nên đang xem lại, trước giờ toàn học chơi chơi
Nếu code server thím có thể dùng thử cái library này
https://github.com/go-kit/kit/tree/master/examples

Còn nếu code library thì cứ tìm mấy cái repo của google mà tham khảo
https://github.com/google/go-cloud

Nếu muốn include cả frontend để làm monorepo thì xem cái này
https://github.com/sosedoff/pgweb

Cần library thì vào đây
https://github.com/avelino/awesome-go

zn…
znvdicrd

08/2021

@znvdicrd 08/2021
#750
Ưng 4
Cũng hóng. trước khì tôi có hỏi thằng CTO về việc dùng golang, nó đưa cái thị phần ngôn ngữ đang sử dụng, và kết luận là khó kiếm và chi phí tuyển dụng cao. Nên bỏ.

mà lên tới tầm Senior thì quan tâm tới ngôn ngữ làm gì nữa nhỉ, cái nào chả code được. Nếu muốn code đẹp và chuyên nghiệp thì cho nó thơi gian 2 tháng. Code từ C/C++, tới Python, JS, Java, flutter nhưng thấy những thứ cơ bản vẫn vậy. Muốn code đẹp hơn và hiểu sâu về ngôn ngữ thì đọc thêm cuốn ninja python.... Mất 1 tháng là code đẹp như mơ rồi
Chưa cần đến vị trí CTO, ngay như đến lead architect là phải hiểu chọn giải pháp để tối ưu được nguồn lực hiện tại chứ không chạy theo ngôn ngữ nữa rồi. Ở đây nó còn liên quan đến nhiều vấn đề ngoài kỹ thuật như nhân sự, tiền, thời gian ... nên rất có thể CTO của thím đúng đấy.

Nói ra khéo động chạm nhưng đi pv ông nào bảo nhảy ngôn ngữ mất có 2 tháng để code mượt là tôi xếp vào nhóm chỉ làm những project nhỏ hoặc là junior.
Kinh nghiệm của tôi là thế này: ngôn ngữ các ông đang quen dùng mà nhảy sang framework mới, vd từ Django sang Flask, Spring sang Micronaut cũng mất ít nhất 6 tháng để dùng hết các feature của nó thành thạo ở level của senior (1). Nhảy sang ngôn ngữ khác cùng loại (vd Java -> C#) ngoài việc làm quen framework còn phải học thêm cả core library và các khái niệm khác, độ khó (2) tăng thêm nữa.
Nhảy sang ngôn ngữ khác loại (vd: static type -> dynamic type như C# sang Ruby/Python) thêm một level vì còn khác nhau cả workflow lúc develop.
Còn nhảy ngôn ngữ khác paradigm như từ OOP sang FP thì các ông tự hiểu độ khó ở mức như thế nào.

(1) Dùng ở level senior tức là có bất kỳ vấn đề hay lỗi nào nhìn log là phải định hình được ngay nguyên nhân ở khu vực nào, vd: lỗi ở code hay cấu hình, môi trường, thư việc; xem code biết tối ưu như thế nào, xử lý các lỗi performance liên quan đến bộ nhớ, CPU do dùng framework chưa đúng ... Đối với tôi, chức năng đang ở framework A mà viết lại cho nó chạy y hệt như framework B thì chưa gọi là senior
(2) Độ khó ở đây là độ khó để học/thành thạo trong thời gian ngắn, không có nghĩa khó tức là framework/ngôn ngữ không thể học được.

ti…
tipfono

04/2021

@tipfono 04/2021
#753
Ưng 4
Biết nhiều ngôn ngữ là chuyện thường, có thời gian là cân được. Nhưng dùng ngôn ngữ mới để mượt được thì phải có thời gian, không nhanh được đâu.
Cái này thì anh nhầm, có những cuốn sách nó viết chuyên sâu, mà anh đọc xong có thể hiểu cực sâu về ngôn ngữ, và cách người ta thiết kế ngôn ngữ đó, nó trình bày dạng ý tưởng nên đọc rất nhanh và hiểu rất sâu về những thứ tụi thiết kế ngôn ngữ nó làm, và tại sao nó thiết kế ra syntax đó. Ví dụ như cuốn này "Secrets of the JavaScript Ninja.pdf", hoặc những cuốn như này "Martin Reddy - API Design for C++-Morgan Kaufmann (2011).pdf"

Anh nghiên cứu nó tầm 1 tháng là đủ. Đương nhiên nghiên cứu nghiêm túc, Thói quenc của tôi khi đọc sách là lựa sách thật kĩ, đọc từng line một, không bỏ 1 chữ nào, và nếu không hiểu thì tìm hiểu những thứ không hiểu ở những cuốn sách khác viết tốt hơn phần đó. Nên mỗi cuốn sách tôi tốn 1-2 tháng để đọc là vì vậy. nói là đọc 1 cuốn nhưng tham khảo tài liệu và ghi chú chắc phải 5-6 cuốn.

Thời gian còn lại anh có thể lên github để đọc code. ANh có thể suy nghĩ về kiến trúc dự án sắp làm, và check xem những thằng chuyên nghiệp nó implement từng phàn kiến trúc như thế nào. Xem nhiều thằng, kết nối từng phần đó lại, là anh sẽ thấy ưu điểm nhược điểm của style code của từng thằng, và rút ra một bản note cho mình. Là anh sẽ code chuẩn liền. Mấy cái code này đôi khi còn mang tính cá nhân và phong cách cửa từng thằng nữa, nên cũng khó nói thằng nào code OK, thằng nào code đểu

Đương nhiên anh code lâu 1 ngôn ngữ thì anh sẽ code tốt nó hơn. Nhưng thế giới này không chờ ai cả.