2 điểm bởi GN⁺ 2023-08-02 | 1 bình luận | Chia sẻ qua WhatsApp
  • Quản lý bộ nhớ ORC trở thành mặc định
  • Backend JavaScript mặc định sử dụng BigInt cho int64uint64, 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:strictEffects luôn được bật, và tham số callback cần chú thích effectsOf
  • Ngôn ngữ đánh dấu mặc định cho chú thích tài liệu chuyển từ chế độ RstMarkdown trước đây sang Markdown, đồng thời thêm pragma {.doctype: Markdown | RST | RstMarkdown.} và các lệnh md2html, rst2html
  • Một số chức năng liên quan đến os trong thư viện chuẩn được tách thành giao diện mới dùng trừu tượng hóa Path, và được cung cấp qua các mô-đun std/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/sums sẽ cần cài nimble hoặc atlas
  • Cách dùng break không tên bên trong block khô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ủa ref hoặc ptr
  • 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ến let có được gán đúng một lần hay không
  • Thêm pragma virtual và mở rộng pragma constructor cho 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/pkgs sang $nimbleDir/pkgs2

1 bình luận

 
GN⁺ 2023-08-02
Ý 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

    • Mô tả đó chẳng phải giống C++ vector hay map đặt trên stack sao? Chúng cấp phát nội bộ khi cần, rồi toàn bộ container bị hủy khi ra khỏi scope
    • Nghe làm tôi muốn xem thử Nim. Tôi tò mò hệ thống build của nó thế nào. CMake thật sự rất khổ sở
    • Trông thật sự giống Python. Hy vọng nó phổ biến hơn; nhìn như một Rust dễ dùng hơn nhiều
    • Có vẻ hay. Không biết quản lý package đang ở tình trạng nào, và hệ sinh thái hiện tại vững chắc đến đâu
  • 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

    • Tôi đang dùng Nim làm đối tượng scripting cho game và một số mục đích khác không thể nói chi tiết, vì nó có thể chuyển đổi sang C và C++
      Đ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
    • Tôi tò mò cụ thể việc viết web app bằng cùng một ngôn ngữ hiệu quả cho backend và frontend hoạt động ra sao
      Đặ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?
    • Với những trường hợp từng micro giây đều quan trọng, như mã xử lý ADC 22 kSPS trên ESP32, nói thật là đã cần khoảng 2 giờ tinh chỉnh. Khi đó tôi mới học Nim, nên chủ yếu là tránh các cấp phát bổ sung
      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

    • Trong các thay đổi gần đây, tôi thích giá trị mặc định nhất. Nó hữu ích nói chung và còn giảm thêm boilerplate khởi tạo, đồng thời cho phép bảo đảm trạng thái hợp lệ ở thời điểm biên dịch trong những thứ như enum. Có lẽ điều này cũng áp dụng cho object variant
  • 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

    • Tôi cho rằng thông báo lỗi tệ và tooling thiếu thốn là vấn đề lớn nhất của Nim. Ngoài các điểm đó, nhìn chung đây là một ngôn ngữ tuyệt vời
    • Ít nhất báo cáo lỗi gần đây đã được cải thiện: https://nim-lang.org/blog/2023/03/31/version-20-rc2.html
  • 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

    • Việc ngày càng nhiều doanh nghiệp lớn và startup áp dụng là điều thú vị. Tôi tò mò liệu có thống kê hay dữ liệu liên quan không, hay chỉ là những câu chuyện truyền miệng
      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ờ

    • Khi đã nằm trong thư viện kiểu “có sẵn pin”, thư viện rất dễ bị đình trệ. Python vẫn kéo theo một số “viên pin” đã chết từ thập niên 90, nhưng ở đó thì chúng cần thiết
      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

    • Có liên quan phần nào, với Denim bạn có thể gọi mã Nim từ Node.js/Bun: https://github.com/openpeeps/denim
      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

    • Để bênh vực Nim, thực ra gần như chỉ Python mới có hệ sinh thái machine learning khổng lồ như numpy, scipy, pandas, opencv, pytorch, tensorflow, keras. Làm các tác vụ kiểu ML/AI bằng ngôn ngữ không phải Python thật sự rất khó
      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

    • Tôi đã dùng cả hai trong một dự án OS làm vì sở thích. Tôi dùng Nim[1], Zig[2], và tôi thích Nim hơn hẳn. Code ngắn gọn, thanh lịch, giúp tôi tập trung vào logic cốt lõi thay vì phải vật lộn với ngôn ngữ
      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 uint8
      Việ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
    • Tôi đang duy trì các binding sinh tự động cho thư viện C của mình dành cho Zig, Nim, Odin và Rust. Binding Rust chắc chắn cần được chỉnh lại nếu muốn idiomatic hơn
      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
    • Tôi đã viết chương trình bằng cả hai, nhưng cũng đã lâu không dùng Nim. Tôi nghĩ viết code bằng Nim thú vị hơn
      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
    • Tôi đã dùng cả Nim lẫn Zig trong dự án mới. Có rất nhiều khác biệt cụ thể, nhưng nếu nói đơn giản về đặc điểm thì Nim gần với việc tạo ra một con dao Thụy Sĩ kiểu Python dưới dạng ngôn ngữ biên dịch hơn
      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
    • Zig có vẻ không có bản triển khai trong TechEmpower Benchmarks, nhưng Nim thì có: https://www.techempower.com/benchmarks/#section=data-r21&l=y...