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

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
Ko biết bác mod năm nay bn tuổi. Kinh nghiệm chắc cũng dày dạn. Mức 4, 5k bên worldquant đáp ứng đc tốt
 
m.n cho em hỏi sao golang toàn thấy tuyển Software Engineer mà ít thấy tuyển backend web vậy ạ . Hay là golang thích hợp để làm phần mềm hơn là backend web ạ?
 
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
 
Last edited:
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
CTO của thím nói đúng mà. Đồng ý đổi ngôn ngữ đa phần xoay quanh syntax, nhưng để quen thuộc thì cũng không phải ngày 1 ngày 2 mà có khi cả tháng như thím nói, vậy đứng ở vị trí dev nếu có 2 job tương đương mà 1 job phải chuyển qua golang thì 96.69% dev sẽ chọn job còn lại rồi. Mà trong 1 cty dev ra vào liên tục, một vài ông không biết go vô làm rồi học còn đỡ chứ ông nào vào cũng mới toanh, cũng mất 1 tháng để làm quen thì cty nào chịu cho nổi trừ mấy cty bự hẳn.
 
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.
 
Những công ty to hơn như google, MS thì tôi không biết thế nào, nhưng tôi từng làm ở amazon, thì thấy mõi đứa luôn biết 2 ngôn ngữ, 1 là C++, 2 là Python, và ngôn ngữ mới nào tụi nó cũng chơi được cả.

Cái ngôn ngữ thì không quan trọng lắm, quan trọng là cái domain.
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.
 
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ả.
 
Last edited:
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"

Anh nghiên cứu nó tầm 1 tháng là đủ. Đương nhiên nghiên cứu nghiêm túc, Còn mấy cái design và clean code, thì chỗ nào cũng như nhau, khi implement thì xoay tới xoay lui tùy vào tư duy của từng thằng
Nếu như thím giải thích hiểu theo kiểu này thì view của thím với tôi khác nhau rồi :) Vậy thì chỉ cần đọc sách là master được hết. Như thế thì tôi xin rút lại, không cần đến 2 tháng mà chắc 2 tuần thôi là hoàn thành, nhưng nếu tôi là CTO thì không dám tuyển mấy senior này đâu :D

View của tôi là level senior trong dự án là phải làm được việc chứ không phải chỉ biết về ngôn ngữ/framework features. Cụ thể là cần những ông nhìn app bị đơ, log ghi là "Cannot determine type of property" mà vì đủ kinh nghiệm với ngôn ngữ/framework nên biết do config Docker bị thiếu. Nếu có sách nào đọc để biết được cái kiểu như này thì tôi cũng mong được đọc lắm :D
 
Nếu như thím giải thích hiểu theo kiểu này thì view của thím với tôi khác nhau rồi :) Vậy thì chỉ cần đọc sách là master được hết. Như thế thì tôi xin rút lại, không cần đến 2 tháng mà chắc 2 tuần thôi là hoàn thành, nhưng nếu tôi là CTO thì không dám tuyển mấy senior này đâu :D

View của tôi là level senior trong dự án là phải làm được việc chứ không phải chỉ biết về ngôn ngữ/framework features. Cụ thể là cần những ông nhìn app bị đơ, log ghi là "Cannot determine type of property" mà vì đủ kinh nghiệm với ngôn ngữ/framework nên biết do config Docker bị thiếu. Nếu có sách nào đọc để biết được cái kiểu như này thì tôi cũng mong được đọc lắm :D
Trời ạ, app đơ thì thiếu gì sách có thể giúp ông phân tích nguyên nhân bị đơ. Nhưng về nguyên tắc thì đơ là do nó access RAM, disk hoặc CPU một cách quá đáng. biết đươc cơ bản thì dùng tool mà phân tích thôi. Intel thì dùng cái tool trả phí của nó mà quét xem thời điểm lag, disk, ram, cpu được acccess thế nào, thread nào access cao. Nếu dùng linux thì dùng perf, là limit lại được context. Sau khi limit được rồi thì bay vào mà analyze thôi. Chứ chả lẽ ông ngồi mò xem config sai ở đâu à ? Mấy cái này trong mấy course linux performance nó đầy cả ra.


Cho nên mấy vòng tuyển dụng ở bigtech người ta toàn tuyển giải thuật và data, và kiến thức background. Cơ bản là tư duy tốt và kiến thức background chuẩn thì dính tới issue gì nó cũng tìm hướng để xử lý được. Chứ kiến thức về FW, lib các kiểu nó con chả thèm hỏi. Tôi PV thường nó hỏi xử lý vấn đề thế nào, tại sao chọn cái này cái kia, gặp vấn đề này hướng giải quyết của mày thế nào ...


Tôi không biêt thói quen ở Vn thế nào, nhưng cái thời tôi ở làm ở Canada, tụi dev bên đó trưa nào cũng ngồi đọc sách. cứ ăn cơm xong là ngồi vào bàn đọc tới gần chiêu mới làm việc. Đó gần như thành văn hóa công ty tôi rồi. Cứ có chủ đề gì nó cần tìm hiểu chuyên sâu, là tụi nó lại tìm tới sách.
 
Last edited:
Trời ạ, app đơ thì thiếu gì sách có thể giúp ông phân tích nguyên nhân bị đơ. Nhưng về nguyên tắc thì đơ là do nó access RAM, disk hoặc CPU một cách quá đáng. biết đươc cơ bản thì dùng tool mà phân tích thôi. Intel thì dùng cái tool trả phí của nó mà quét xem thời điểm lag, disk, ram, cpu được acccess thế nào, thread nào access cao. Nếu dùng linux thì dùng perf, là limit lại được context. Sau khi limit được rồi thì bay vào mà analyze thôi. Chứ chả lẽ ông ngồi mò xem config sai ở đâu à ? Mấy cái này trong mấy course linux performance nó đầy cả ra.


Cho nên mấy vòng tuyển dụng ở bigtech người ta toàn tuyển giải thuật và data, và kiến thức background. Cơ bản là tư duy tốt và kiến thức background chuẩn thì dính tới issue gì nó cũng tìm hướng để xử lý được. Chứ kiến thức về FW, lib các kiểu nó con chả thèm hỏi. Tôi PV thường nó hỏi xử lý vấn đề thế nào, tại sao chọn cái này cái kia, gặp vấn đề này hướng giải quyết của mày thế nào ...


Tôi không biêt thói quen ở Vn thế nào, nhưng cái thời tôi ở làm ở Canada, tụi dev bên đó trưa nào cũng ngồi đọc sách. cứ ăn cơm xong là ngồi vào bàn đọc tới gần chiêu mới làm việc. Đó gần như thành văn hóa công ty tôi rồi. Cứ có chủ đề gì nó cần tìm hiểu chuyên sâu, là tụi nó lại tìm tới sách.
H làm ở đâu thế fen, tôi thì thấy fen nói đúng chuyện ngôn ngữ thật ra học nhanh bỏ cha ra, core libs Sài thêm 2 tháng là đủ hiểu. Văn hoá cty bác vl thế đọc sách gì tới chiều.
 
Trời ạ, app đơ thì thiếu gì sách có thể giúp ông phân tích nguyên nhân bị đơ. Nhưng về nguyên tắc thì đơ là do nó access RAM, disk hoặc CPU một cách quá đáng. biết đươc cơ bản thì dùng tool mà phân tích thôi. Intel thì dùng cái tool trả phí của nó mà quét xem thời điểm lag, disk, ram, cpu được acccess thế nào, thread nào access cao. Nếu dùng linux thì dùng perf, là limit lại được context. Sau khi limit được rồi thì bay vào mà analyze thôi. Chứ chả lẽ ông ngồi mò xem config sai ở đâu à ? Mấy cái này trong mấy course linux performance nó đầy cả ra.


Cho nên mấy vòng tuyển dụng ở bigtech người ta toàn tuyển giải thuật và data, cơ bản là người ta check khả năng tư duy, giải quyêt vấn đề. Gặp bất cứ vấn đề gì nó cũng xử lý dược thôi.


Tôi không biêt thói quen ở Vn thế nào, nhưng cái thời tôi ở làm ở Canada, tụi dev bên đó trưa nào cũng ngồi đọc sách. cứ ăn cơm xong là ngồi vào bàn đọc tới gần chiêu mới làm việc. Đó gần như thành văn hóa công ty tôi rồi.
Tôi nói view của tôi với thím khác nhau rồi mà :) Lúc có lỗi mà còn đi dò ở level của OS như perf, ps hay tìm trong sách, Google thì với tôi là senior làm việc ở level cúa junior :D
Làm việc ở level senior là ông nhìn log ở module A của app và ở đoạn đọc input data, và việc mất dữ liệu do thằng framework đảm nhiệm ở 1 module B hoàn toàn không được liệt kê trong stack trace, và việc mất dữ liệu này là vì thằng module C ở xa tít mù tắp thiếu system config, và system config là từ thằng Docker. Toàn bộ suy luận này là phải 1 phát ăn ngay trong đầu chứ không cần lên Google hay tra document gì cả. Tức là phải nắm được trọn vẹn cách hoạt động, behaviour cả lúc bình thường lẫn lúc có lỗi của phần lớn các module trong framework, chứ Google thì không tính.
Đã tầm Senior thì ông nào chả đọc đủ loại sách, nhưng mất thời gian nhất để làm việc hiệu quả là học được những cái interaction kiểu này, mà những thứ này thì bắt buộc phải làm nhiều mới nắm được.
 
Tôi nói view của tôi với thím khác nhau rồi mà :) Lúc có lỗi mà còn đi dò ở level của OS như perf, ps hay tìm trong sách, Google thì với tôi là senior làm việc ở level cúa junior :D
Làm việc ở level senior là ông nhìn log ở module A của app và ở đoạn đọc input data, và việc mất dữ liệu do thằng framework đảm nhiệm ở 1 module B hoàn toàn không được liệt kê trong stack trace, và việc mất dữ liệu này là vì thằng module C ở xa tít mù tắp thiếu system config, và system config là từ thằng Docker. Toàn bộ suy luận này là phải 1 phát ăn ngay trong đầu chứ không cần lên Google hay tra document gì cả. Tức là phải nắm được trọn vẹn cách hoạt động, behaviour cả lúc bình thường lẫn lúc có lỗi của phần lớn các module trong framework, chứ Google thì không tính.
Đã tầm Senior thì ông nào chả đọc đủ loại sách, nhưng mất thời gian nhất để làm việc hiệu quả là học được những cái interaction kiểu này, mà những thứ này thì bắt buộc phải làm nhiều mới nắm được.

Cuộc đời của ông sẽ làm viêc với hàng chục FW, hàng trăm thư viện., trái qua hàng chục công ty với nền tảng khác nhau, Nên bảo để ông nhớ từng thứ là điều không thể. Cái ông cần là kiến nền tảng, và khả năng phân tích thôi. Chứ bảo tuyển kỹ sư mà theo kiểu 5 năm kinh nghiệm làm việc với FW này kia thì nó lại khó.

MÀ cuộc đời tôi đi PV thấy cực hiếm nếu không muốn nói là không có thằng nào hỏi kiến thức kieur ông cả.
 
Tôi nói view của tôi với thím khác nhau rồi mà :) Lúc có lỗi mà còn đi dò ở level của OS như perf, ps hay tìm trong sách, Google thì với tôi là senior làm việc ở level cúa junior :D
Làm việc ở level senior là ông nhìn log ở module A của app và ở đoạn đọc input data, và việc mất dữ liệu do thằng framework đảm nhiệm ở 1 module B hoàn toàn không được liệt kê trong stack trace, và việc mất dữ liệu này là vì thằng module C ở xa tít mù tắp thiếu system config, và system config là từ thằng Docker. Toàn bộ suy luận này là phải 1 phát ăn ngay trong đầu chứ không cần lên Google hay tra document gì cả. Tức là phải nắm được trọn vẹn cách hoạt động, behaviour cả lúc bình thường lẫn lúc có lỗi của phần lớn các module trong framework, chứ Google thì không tính.
Đã tầm Senior thì ông nào chả đọc đủ loại sách, nhưng mất thời gian nhất để làm việc hiệu quả là học được những cái interaction kiểu này, mà những thứ này thì bắt buộc phải làm nhiều mới nắm được.
tôi hay gặp các anh như mô tả ở các tổ chức ít vận động, chỉ phát triển thêm/maintain 1 hệ thống nào đó năm này qua năm khác. Senior domain hẹp thế này kể cũng hay, làm việc khá nhàn, nhưng hơi hạn chế về career path vì thời gian trải nghiệm 1 thứ mới mẻ của các anh ấy quá lâu nên tri thức thiếu sự đa dạng là điều dễ đoán
 
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

Nếu như CTO nói khó kiếm và chi phí tuyển dụng cao cũng có thể đúng. Nhân sự hiện tại đang có thế mạnh Java chẳng hạn, code spring boot như múa, và dự án không yêu cầu Go thì sao phải đi tìm thuê nhân sự Go làm gì.
Mình thấy nếu muốn một dự án sử dụng một ngôn ngữ mới thì nhân sự hiện tại vài ba người phải tự nghiên cứu mày mò, thử nghiệm kỹ.

Tôi thấy vấn đề thường gặp là ở framework hay library. Nhiều khi có mấy cái lỗi mà mình không nghĩ ra nó đang bị, loay hoay xử lý với nó cần phải có kinh nghiệm chứ ngôn ngữ thường hiếm khi gặp vấn đề mất thời gian.
 
Back
Top