Andreas Rumpf: Welcome to NimConf 2021 + Zen of Nim

[@undisclosedmusic4969]

I don't get why a great language like this doesn’t have a complete set of video courses and the only book is years old… Nim could be the go-to for everything but it's languishing. Target scientific computing, data science and machine learning! You can take the crown from python and julia easily

[@randyt700]

Lot of factors that affect language adoption. In my opinion the strongest is usage in academia. Python actually has some quality introductory computer science textbooks for high school students and if nim wants to have similar following, the nim community really has to push/market to highschool/college crowd. Industry will follow afterwards.

[@PeterPan-ev7dr]

Nim is right now like a future heavyweight boxing champion, having all the skills and patiently waiting for the chance to get the world title fight, but knowing inside that it will win ..

[@samhughes1747]

Maybe you should jump in and do some writing?

[@shalokshalom]

@@randyt700 Nim has not yet focused on programming newbies Python did this already in early days.

[@vncstudio]

It does not have to be one or the other. Nim can be a perfect partner with Python instead of C! Needs a little more support and packaging tools for cloud computing.

[@xealit]

it is a smart idea to have comprehensive metaprogramming in a compiled language with strict types 👍

[@WildWestDesigns]

I have been using nim for quite a while and I really do like it, other then not much in the way for GUI development. That's probably the biggest thing that is keeping me from it. I see a lot of promising projects, but either they haven't had any recent commits (a lot won't even build correctly), or documentation. While I don't have a problem with even regular I/O terminal apps for some tools, I know the ones that I would want to release to the masses, that won't really do for them. If only could get a single framework (even if it is something like TK) that could be used in STD for something, I think that would go a long way. That's just me thinking anyway, otherwise, I really do enjoy it.

[@encapsulatio]

Hopefully someone can demo scripting in Nim and how you achieve it and what are the limitations compared to really dynamic programming languages.

[@sanjaygatne1424]

at 11:11 you say 20 to x , is it mistake or its ok.

[@yishanju]

Only 720p，Sadge

[@davidste60]

Does anyone know how structural sharing is best used in Nim? Is there a neat way to avoid the deep copying of immutable data when you want to?

[@neversimon]

There many things at play least of all is the memory management scheme you choose. I'd recommend reading up on ARC/ORC, destructors, and views. Sounds like a lot but much of it overlaps.

[@davidste60]

@@neversimon I'm going to take that as a no. I've read up on ARC/ORC and didn't notice a neat way. I think one way to do it for a particular type is to override =deepCopy. Then you could use macros to determine which type to use in a given case. Actually, views might work, because the mutations are analysed and with immutable data there would be none. Neat.

[@zachoakes]

@@davidste60 there aren't immutable data structures in the standard library. i definitely want clojure-style HAMT / RRB based data structures too. i may try to implement them one day...

[@davidste60]

@@zachoakes That's the direction I'm thinking in too. The trick would be how to get it to mesh nicely with the rest of the language, not just make a haskell-lite inside of nim. I thought overriding the =deepCopy operator, and obviously only returning immutable references, might fit the bill. And of course, since they are acyclic they would work very well with ORC memory management, probably avoiding frame-drops. (unlike CLJ/CLJS)

[@Wyklepheph]

You pass the object as a reference by including `var` in the type description of the variable in the proc definition.. i.e. `proc someProc(someRef: var DeepObj) =`. That way you aren't deep copying anything since it's passed as a reference object

[@之波泉河]

very good.

[@bakedbeings]

It really bummed me out when I discovered f(a) isn't equivalent to f a. Having such a fundamental bit of syntax only working in some cases - one having a hidden-string-to-raw-string conversion and not the other - that's the kind of outline blurring inconsistency that often takes the pleasure out of modern C++ additions. Great concept but not true in implementation, and capricious at runtime, because history (look into universal initialisers). Finding that f strings are broken for console output - fmt("") != fmt"" - and require the substitution of an arbitrary, inscrutable & operator as a workaround, that's the antithesis of zen for me - that invisible "r" affecting a particular data type means the code simply isn't what it appears to be . I try to ignore it but.. how do you avoid something that comes up in: echo fmt"\tHello {name}!" I keep imagining showing rule 7 to new programmers while teaching basic i/o and being asked: what other basic rules break with intuition, have to be memorised, and how would they know?

[@amiteliyahou6422]

Indeed. I think Nim nails a lot of things right. Although this thing, I feel, just adds complexity, instead of removing it, as it is claims to be.

[@andreasrumpf9012]

Well it does the right thing for `re"abc "` but not for `fmt"abc "`. And there is no consistent way to resolve it so use `&"abc "` for string formatting which just works.

[@bakedbeings]

@@andreasrumpf9012 (I offer these comments with enormous respectfor you and what you've made, and in a spirit of friendly inquiry and striving, though the wording is surely cranky) **re** is the regular expression module right? It makes sense that something was needed to avoid the escape soup that occurs when using regular expressions in bash for example. I'm guessing, though, that `re("abc ")` doesn't receive a raw string, and parentheses symmetrically inconsistent for different use cases? I know there's a workaround for fmt, but.. now you need a new workaround and symbol for any future module you ever write if you don't want people to faceplant when they drop parentheses? In essence every function that takes a string as an argument, ever written in Nim by any programmer, for evermore, contains a potential gotcha depending on whether it's called with or without parens? But they can fall into the habit with any other data type? Maybe I'm overlooking something, but I can't resolve in my mind how the creator who's brought so much clarity and sense to so many aspects of this language, isn't turning in his bed at night over it. This clunky flatspot in the otherwise satisfyingly smooth wheel of learning and using Nim. This double-hack of an invisible conversion, over any other solution that either introduces a clear syntax or just encapsulates the conversion to raw string in the libraries (and functions) that are made much easier to use with raw strings. What made you rule out a consistent and visible syntax for raw strings, say surrounding them in `backticks`? Or a way to declare raw string arguments that can accept string literals and store a raw literal (like an overloaded constructor in C), which make it no harder to write functions that prefer raw strings? Maybe a declaration syntax for function arguments that specifies incoming strings will be converted to a raw string? Anything at all that can be read in the text of the page instead of the documentation, something that shows up in code sense/intellisense, something you can *see*?

[@andreasrumpf9012]

@@bakedbeings There is no inconsistency here, raw strings look like identifier"xyz" and if you want a cooked string you use a space in between or parenthesis. I don't lose sleep over this problem as I don't understand why there is a problem. These are the rules of the language, they are as easy to follow as other rules you might come up with, they are close to how Python does it and I've heard no complaints about it, until now, from you, over a decade after these rules have been implemented and documented. I suggest we continue the discussion on Nim's forum or github issue tracker as I'm afraid I still don't understand you.

[@sanjaygatne1424]

nice talk.

[@alexpyattaev]

If nim just used python syntax it could be great. Python is a gold standard for a good reason. If some/most python code happened to be valid nim it would be a massive win.

[@Ner0ki-e4u]

OOP syntax in python is let alone ugliest thing in existence

[@alexpyattaev]

@@Ner0ki-e4u OOP in general is quite ugly in most cases.