• I Cast Fist@programming.dev
    link
    fedilink
    arrow-up
    3
    ·
    1 year ago

    I’m curious to the reasoning behind moving a bunch of standard library stuff to external packages, listed at the end of the blog post. Faster compiling? Smaller executables? Faster development for each now separate package?

    • grayrest@programming.dev
      link
      fedilink
      arrow-up
      3
      ·
      1 year ago

      I don’t know the specific motivation here but in general it’s for package development to not be tied to the language release. People also generally have different backwards compatibility expectations for the stdlib vs a regular library and that constrains the development of the package. In Python the meme is that stdlib is where packages go to die. Not all large stdlib languages feel that way. Clojure, for example, has a pretty sizeable stdlib while being code frozen without a lot of demand for change. In general, however, language developers prefer not having things in stdlib.

    • unquietwiki@programming.devOP
      link
      fedilink
      English
      arrow-up
      2
      ·
      1 year ago

      I saw that list, and figured that they were distancing themselves from obsolete encryption (MD5 & SHA-1), as well as remove database management from their scope (which seems like the right move, IMO).

  • cacheson@kbin.social
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    It seems like maybe there are some new features that weren’t in the previous release candidate? I don’t remember default values for objects being a thing. Maybe just me though?

    • I Cast Fist@programming.dev
      link
      fedilink
      arrow-up
      4
      ·
      1 year ago

      That is a new and welcome change, in my opinion. I have a bit of experience with Nim and when you defined a type (object), you couldn’t define default values. The workaround was making or overloading a new() function with default values instead.

      • cacheson@kbin.social
        link
        fedilink
        arrow-up
        2
        ·
        1 year ago

        Oh, yeah, don’t get me wrong, I like the change. I just figured the difference between a release candidate and the actual release would just be bug fixes and such.

  • itadakimasu@programming.dev
    link
    fedilink
    arrow-up
    1
    arrow-down
    1
    ·
    1 year ago

    I want to love Nim but during my trial run with it. It was a pain in the ass to get set up on my Mac in a way that I could use it easily ie as a repl for quick and dirty prototyping and learning

      • itadakimasu@programming.dev
        link
        fedilink
        arrow-up
        2
        ·
        1 year ago

        No issue setting up Nim itself (and I realize my complaint is not fault to Nim itself) but it would be great if this complimentary jupyter kernel for Nim would work on MacOS… Hasn’t been maintained in a while: https://github.com/stisa/jupyternim/issues/38

        Would be very useful for my workflow as someone who wants to explore Nim for data science-y type tasks.

        Anyone know of an alternative Nim jupyter kernel?

        • sotolf@programming.dev
          link
          fedilink
          arrow-up
          1
          ·
          1 year ago

          I don’t think the jupyter kernel is made by the core developers of nim, it’s kind of weird to call the language pain in the ass because of one weird niche usecase being hard to set up :)

        • janAkali@lemmy.one
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 year ago

          Try inim.

          It’s not perfect, but closest thing to repl.
          I use it all the time for very small experiments.
          Installation should be as easy as:

          nimble install inim
          
        • insomniac_lemon@kbin.social
          link
          fedilink
          arrow-up
          1
          ·
          1 year ago

          Not sure about MacOS plus it’s not REPL (sorry if that is key), but have you tried faster compilers for prototyping? Such as TCC (Bellard’s Tiny C Compiler) as long as performance isn’t critical and if you don’t need multi-threading.

          Clang is also pretty good (for a simple benchmark, the result I got was that Clang with opt:size gives similar performance to plain GCC but with half the compile time). (nlvm is also a thing but I have no idea how that’d compare even to Nim compiling code via Clang)

          With some setup, maybe some form of hot code reloading?