Nim 2.0 - Ngôn ngữ lập trình tập trung vào mô hình lập trình mệnh lệnh và hệ thống macro
(nim-lang.org)- Quản lý bộ nhớ ORC trở thành mặc định
- Backend JavaScript mặc định sử dụng BigInt cho
int64vàuint64, và nếu dùng các kiểu này trong mã tương tác với backend JS thì có thể cần cập nhật --experimental:strictEffectsluôn được bật, và tham số callback cần chú thícheffectsOf- Ngôn ngữ đánh dấu mặc định cho chú thích tài liệu chuyển từ chế độ
RstMarkdowntrước đây sang Markdown, đồng thời thêm pragma{.doctype: Markdown | RST | RstMarkdown.}và các lệnhmd2html,rst2html - Một số chức năng liên quan đến
ostrong thư viện chuẩn được tách thành giao diện mới dùng trừu tượng hóaPath, và được cung cấp qua các mô-đunstd/oserrors,std/envvars,std/paths,std/dirs,std/files,std/symlinks,std/appdirs,std/cmdline - Nhiều mô-đun thư viện chuẩn đã được chuyển sang gói Nimble, nên khi dùng
std/punycode,std/asyncftpclient,std/smtp,std/db_*,std/md5,std/sha1,std/sumssẽ cần càinimblehoặcatlas - Cách dùng
breakkhông tên bên trongblockkhông tên bị ngừng hỗ trợ (deprecation), và sẽ trở thành lỗi trong các phiên bản sau - Định nghĩa
"strictFuncs"thay đổi, cấm lưu trữ vào các dereference củarefhoặcptr - Tuple unpacking của biến được xử lý như cú pháp rút gọn mở rộng thành nhiều phép gán, và giờ có thể unpack tuple lồng nhau
- Suy luận kiểu từ trên xuống đã được triển khai ở nhiều trường hợp mặc định, nên mã khởi tạo
seq[(float, byte, cstring)]trong ví dụ có thể biên dịch - Có thể chỉ định giá trị mặc định cho các trường của object, và các trường không được khởi tạo tường minh sẽ dùng giá trị mặc định đó
- Thêm tùy chọn thực nghiệm
strictDefsđể kiểm tra biến đã được gán giá trị tường minh trước khi dùng hay chưa, và kiểm tra biếnletcó được gán đúng một lần hay không - Thêm pragma
virtualvà mở rộng pragmaconstructorcho khả năng tương tác C++, cho phép định nghĩa constructor và proc ảo ánh xạ tới constructor và phương thức ảo của C++ - Đi kèm Nimble 0.14 với hỗ trợ lock-file, và vị trí lưu thư viện chuyển từ
$nimbleDir/pkgssang$nimbleDir/pkgs2
1 bình luận
Ý kiến trên Hacker News
Đang dùng Nim trong production và khá hài lòng. Chủ yếu tôi xây dựng các công cụ phân tích dữ liệu và tạo báo cáo, rồi biên dịch thành các file thực thi CLI được script phía server gọi
Nim tạo ra các file thực thi nhanh và nhỏ, có cấu trúc dữ liệu JSON không đồng nhất cùng thư viện dataframe tốt. Ngôn ngữ này rất ưu tiên stack, nên ngay cả các cấu trúc dữ liệu động như sequence và table cũng có con trỏ trên stack trỏ tới dữ liệu trên heap, còn vòng đời được quản lý bởi stack frame
Trong chương trình hầu như không có tham chiếu động và cũng không cần bận tâm tới GC. Hệ thống kiểu đơn giản, hợp lý và dễ dẫn dắt bạn viết mã đúng. Các giá trị mặc định cũng gần với tính minh bạch tham chiếu; nếu không chủ động thoát ra, mọi thứ đều là truyền giá trị bất biến
Generic mạnh mẽ và hoạt động đúng như kỳ vọng, còn cú pháp gọi hàm phổ quát thì hữu ích đến mức khó tin. Chỉ cần tạo procedure và function nhận một kiểu cụ thể làm đối số đầu tiên là có thể viết thứ tương đương với method hay interface, nhờ đó không cần các lớp trừu tượng ấy và cấu trúc mã trở nên đơn giản, phẳng hơn
Trải nghiệm rất thú vị, gợi nhớ lúc trước khi tôi phát hiện ra D, thậm chí còn tốt hơn. Nếu tưởng tượng một Python có chú thích kiểu, biên dịch native, gần như 100% là logic nghiệp vụ và không có phần thừa thãi, thì đó khá gần với trải nghiệm Nim
Tôi rất mong được thử bản phát hành này. Với tư cách người đã lập trình chuyên nghiệp 25 năm, tôi thấy Nim là ngôn ngữ kết hợp tốt ưu điểm của nhiều thế giới
Dễ dùng như Python, có kiểu mạnh nhưng suy luận kiểu rất tốt, và các mặc định được thiết kế để vừa nhanh vừa an toàn. Nó phù hợp từ embedded cho tới điện toán hiệu năng cao
Nhờ UFCS, generic và concepts, bạn có được lợi ích của OOP mà ít phải viết mã giàn giáo để liên tục dựng các quan hệ dữ liệu mong manh chỉ nhằm mục đích tổ chức. Khác với Python, sự mơ hồ sẽ trở thành lỗi biên dịch
Tôi cảm thấy cùng một chương trình thường nhỏ hơn, dễ đọc hơn và dễ hiểu hơn rất nhiều so với hầu hết ngôn ngữ khác. Phía sau cũng không có quá nhiều phép màu, vì các mặc định vốn đã hợp lý
Metaprogramming lúc biên dịch ở một đẳng cấp khác. Nó nằm trong cốt lõi thiết kế ngôn ngữ, không cần một dialect riêng hay trò thay thế chuỗi, và cũng trực quan khi dùng. Ví dụ, rất dễ sinh mã parsing tùy chỉnh từ file để loại bỏ boilerplate lặp lại, mà biên dịch cũng nhanh
Nhờ hệ thống kiểu xuất sắc, viết tốt còn dễ hơn Python nhưng hiệu năng ngang C/C++, và việc phân phối dưới dạng file thực thi nhỏ, độc lập cũng rất dễ
Nó có ABI native cho C, C++, ObjC, JS, FFI tuyệt vời, cùng khả năng tương tác tốt với Python. Bạn có thể dùng trực tiếp các hệ sinh thái hiện có mà không cần viết lại
Hãy tưởng tượng viết pseudocode kiểu Python cho ESP32 mà gần như không tốn công vẫn cực kỳ hiệu quả, và khi muốn vẫn có thể điều khiển bare-metal. Hoặc viết web app có cả backend lẫn frontend bằng cùng một ngôn ngữ hiệu quả, làm game bullet hell tốc độ cao mà vẫn không phải lo về GC vì mặc định là cấp phát trên stack trừ khi bạn chỉ định khác
Từ góc nhìn kinh doanh, điểm rất giá trị là bạn có thể prototype nhanh như Python nhưng kết quả đã đủ nhanh và nhẹ cho production. Nó có thể trở thành vũ khí bí mật của một công ty
Điều thật sự tuyệt là có thể trực tiếp quản lý môi trường C bên dưới runtime, đồng thời dùng một ngôn ngữ hiện đại cấp cao ở phía trên với hỗ trợ hạng nhất cho những thứ như JSON. Là người thích Python, tôi vẫn thấy Nim tốt hơn, là một Python hay hơn
Đặc biệt muốn biết trong quá trình phát triển, khả năng tương tác JS tiện đến mức nào, và liệu nó có vượt quá mức chỉ biên dịch Nim thành JS như một thư viện độc lập hay không. Có thể gọi trực tiếp API trình duyệt từ Nim, hoặc gọi qua một wrapper khá đơn giản không?
Dù vậy trong khoảng 4 năm, không có suy giảm hiệu năng lớn hay thay đổi cần thiết nào
Xin chúc mừng tất cả những người liên quan và toàn bộ cộng đồng Nim. Tôi đã dùng Nim làm ngôn ngữ chính trong 10 năm qua, và rất thích các tính năng mới của Nim 2.0
Một vài tính năng thật sự là bước ngoặt cho dự án của tôi. Chẳng hạn giá trị mặc định của object về mặt lý thuyết có thể cho phép Norm[1] hoạt động không chỉ với instance object mà cả với kiểu object. Nếu không có enum mới có thể overload, Karkas[2] hẳn đã hoàn toàn bất khả thi. Dù hiện vẫn đang làm tiếp
[1] https://norm.nim.town
[2] https://karkas.nim.town
Nim là một ngôn ngữ thật sự tốt để viết phần mềm. Bạn có thể triển khai nhanh, phát triển vui vẻ mà vẫn tạo ra phần mềm có hiệu năng rất cao
Tuy vậy theo kinh nghiệm của tôi, nó vẫn còn vài góc cạnh sắc. Bạn phải khớp trình biên dịch C/C++ và các tùy chọn, thông báo lỗi rất nghèo nàn, và một số thư viện chỉ hoạt động với một vài thiết lập và hệ thống nhất định. Dù vậy, xét cộng đồng còn nhỏ thì cũng khó trách nhiều. Tích hợp VS Code hoạt động tốt và gần như không crash
Nếu Manning Publications thấy điều này, tôi mong sẽ có một cuốn sách về phiên bản Nim mới nhất, và hy vọng họ cân nhắc một kiểu dàn trang khác với phông chữ dễ đọc hơn
Tôi đã mua cuốn sách rất hay của Dominik Picheta, nhưng bản giấy dùng phông quá mảnh nên dù đã cắt kính tôi vẫn thấy rất khó đọc, phải dùng bản PDF. Các thành phần của phông như nét và thân chữ quá mảnh
Tôi tự hỏi có phải do mình già đi không nên đem so với bản gốc K&R ấn bản 2, nhưng cuốn đó vẫn đọc hoàn toàn tốt
Reddit đã viết một bài về cách họ dùng Nim: https://www.reddit.com/r/RedditEng/comments/yvbt4h/why_i_enj...
Ngày càng có nhiều doanh nghiệp lớn và startup áp dụng Nim. Tôi rất mong chờ Nim 2.0 và vô cùng cảm ơn tất cả những ai đã đóng góp
Dù là giai thoại thì có thể nêu vài tên công ty không?
Nim từng là ngôn ngữ yêu thích nhất của tôi trong một thời gian, và tôi rất háo hức vì cuối cùng 2.0 đã được phát hành. Rất nhiều tính năng trong lần này là những thứ đã được chờ đợi từ lâu
Nhược điểm duy nhất là, như được đề cập ở cuối, một số mô-đun đi kèm đã được chuyển sang kho lưu trữ bên thứ ba. Không phải vấn đề lớn, nhưng việc hỗ trợ SQLite được tích hợp sẵn trong thư viện là điều rất hay. Một khi bắt đầu hỗ trợ vài cơ sở dữ liệu, chắc chắn sẽ có thêm áp lực phải hỗ trợ nhiều cơ sở dữ liệu hơn. Tuy vậy, việc cả hỗ trợ MD5 và SHA1 cũng bị loại bỏ thì hơi bất ngờ
Hỗ trợ đường dẫn hay logging thì nên nằm trong chuẩn, nhưng một số thứ nên là bên thứ ba để có thể tiến hóa tốt hơn
Chúc mừng tất cả những người liên quan. Tôi cảm thấy Nim là một ngôn ngữ thật sự thú vị
Tôi đang cố tìm lý do để dùng nó trong công việc. Công việc của tôi nằm quanh mảng di động, nên việc có thể biên dịch sang JS và ObjC rất hấp dẫn, nhưng hiện tôi vẫn chưa vượt quá mức mày mò thử nghiệm. So với Rust thì việc bắt đầu đơn giản hơn nhiều
Nó hoạt động theo cách tạo Node addon. Rất phù hợp để tái sử dụng mã Nim trong ứng dụng web hoặc dùng cho phần mã nhạy cảm về hiệu năng
Vài tháng trước tôi đã tìm hiểu Nim, và về mặt tính năng thì có rất nhiều thứ tôi ước Python có được. Chẳng hạn như tương tác dễ dàng với C/C++, kiểu tĩnh, biên dịch, có thể biên dịch chéo và chạy trên Android/iOS
Nhưng dù ngôn ngữ này không mới, hệ sinh thái vẫn nhỏ. Không có nhiều thư viện chất lượng cao như numpy, scipy, pandas, opencv của Python. Thật tiếc là các tay chơi lớn không áp dụng nó, và tôi nghĩ sẽ tốt hơn nếu Unreal Engine thử chọn Nim thay vì tạo ngôn ngữ scripting mới Verse của riêng mình
Một điểm đáng tiếc nữa là khả năng tương tác ngay với thư viện C/C++ mà không cần tự viết adapter. Sẽ tốt nếu chỉ cần nhập header là xong
Tôi cũng mong có khả năng tương tác dễ dàng tương tự với Rust. Điều đó có thể giúp tăng mức độ áp dụng, vì với Rust dễ tìm các crate đa nền tảng chất lượng cao hoạt động ổn cả trên thiết bị di động hơn
Tôi lo rằng trong vài năm tới, Python nhanh hơn, việc loại bỏ GIL, nuitka, briefcase cho di động, v.v. có thể giúp Python bắt kịp, hoặc Mojo sẽ chiếm mất vị trí của Nim
Dù vậy Nim có thư viện nimpy cho phép tương tác gần như liền mạch với Python. Nghĩa là bạn có thể import PyTorch, scipy, opencv và dùng trực tiếp trong Nim
Muốn biết liệu có ai đã thực sự dùng Nim và Zig chưa. Muốn nghe hai ngôn ngữ này giống và khác nhau thế nào. Cũng muốn xem benchmark web server theo lối viết idiomatic của hai ngôn ngữ, dựa trên Nim v2
Zig cũng tốt, và tôi thích cách nó hỗ trợ optional value cũng như cách tiếp cận xử lý lỗi. Nhưng tôi không thích cú pháp ồn ào kiểu
!?[]u8để biểu diễn error union của một optional pointer tới multi-pointer uint8Việc phải chuẩn bị và truyền allocator trong hầu hết code cần cấp phát động cũng làm xao nhãng logic cốt lõi. Ngay cả những việc nhỏ như nối chuỗi hay định dạng chuỗi cũng trở thành việc đáng kể
Zig cũng không có dynamic dispatch, nên khó viết code đa hình, phải đi đường vòng bằng một dạng duck typing nào đó. Cuối cùng tôi kết luận Zig không phù hợp với mình
[1] https://github.com/khaledh/axiom
[2] https://github.com/khaledh/axiom-zig
Nhìn vào các ví dụ thì về cơ bản là cùng một đoạn code được viết bằng nhiều ngôn ngữ, nên có thể nắm được bức tranh lớn, nhưng về mặt tính năng ngôn ngữ thì mới chỉ chạm bề mặt. Ví dụ bản Zig không dùng tính năng comptime
Zig: https://github.com/floooh/sokol-zig/tree/master/src/examples
Nim: https://github.com/floooh/sokol-nim/tree/master/examples
Odin: https://github.com/floooh/sokol-odin/tree/main/examples
Rust: https://github.com/floooh/sokol-rust/tree/main/examples
Zig thì nhàm chán hơn, nhưng đều là vì những lý do tốt. Cá nhân tôi sẽ không viết OS bằng Nim, nhưng Zig khi trưởng thành hơn có vẻ sẽ rất tuyệt cho mục đích đó. Tôi đã bắt đầu dùng nó cho phần mềm nhúng
Tôi nghĩ mình sẽ dùng Nim cho công cụ CLI, ứng dụng server, và có thể cả ứng dụng GUI lẫn game
Đội ngũ Zig có vẻ đầu tư nhiều công sức hơn hẳn vào toàn bộ hạ tầng compiler, và theo trải nghiệm của tôi thì thật sự ấn tượng. Có nhiều đổi mới xuất sắc
Zig là một ngôn ngữ tập trung hơn nhiều, nhắm vào một ngách cụ thể là kế nhiệm và thay thế C, và nó đáp ứng mục tiêu đó rất tốt
Tôi nghĩ sở thích ngôn ngữ phụ thuộc vào những nhu cầu và mong muốn cá nhân mà ngôn ngữ hiện tại chưa đáp ứng được. Tôi chọn gắn bó với Zig vì thấy cách nó nhắm tới vai trò kế nhiệm C rất thú vị, nhưng tôi cũng hiểu vì sao người khác chọn Nim