A bit off-topic, but I'd like to see a language à la rust+gc, with pattern matching, traits, and the functional stuff rust got right, but without all the worries of lifetimes, and maybe some easier trait management (function signatures become very ugly imo). I've heard the claim that lean is going in this direction.
Lean the theorem proving language?
Nim Version 1.6.6 Released
51–60 of 116 posts
Re: Nim Version 1.6.6 Released
#52Earlier quoted context omitted.
It’s probably my biggest gripe with nim. I hope they drop it and provide a tool like gofmt to get everyone’s code into the same style.
Nim has a tool called nimpretty similar to gofmt
Re: Nim Version 1.6.6 Released
#53A bit off-topic, but I'd like to see a language à la rust+gc, with pattern matching, traits, and the functional stuff rust got right, but without all the worries of lifetimes, and maybe some easier trait management (function signatures become very ugly imo). I've heard the claim that lean is going in this direction.
Re: Nim Version 1.6.6 Released
#54Hi, is Nim a good replacement for python? I write a lot of scripts, but I find that python can get cumbersome to maintain. I'm looking for something with stricter typing and a sane packaging/directory system, but also easy/fast to write. If Nim can work with numpy it's a plus
I find it even more productive than python thanks to the typing system. An often neglected highlight that I appreciate a lot is the fact that static typing + procedure overload has the additional benefit that names of functions tend to be very natural (you can reuse the name of function if the type signature is different). That along with UFCS (universal function call syntax), allows to create great apis in no times. Also template are a very easy way to boost productivity and allow to write great DSLs. See also an old but still relevant and very valid introduction of Nim for Python programmers [0]
It can work with numpy and even better there is a performant numpy replacement called arraymancer. Take into account that since you do not need to be afraid of loops, even working with standard sequences is very performant. See also the SciNim getting started book [1]
[0]: https://blog.zdsmith.com/posts/nim-for-python-programmers.ht... [1]: https://scinim.github.io/getting-started/
Re: Nim Version 1.6.6 Released
#55Earlier quoted context omitted.
You must remember that Nim is a statically typed compiled language with support for distinct types etc. This means that you wouldn't be able to call the wrong procedure if you didn't provide it the right types. Besides, not allowing similarly named but differently cased identifiers causes less ambiguity, not more.
I mean, it really might be fine. I've written maybe 20 lines of Nim in my life, what do I know. I just look at it and see a foot and a gun pointing at it. The arguments for it sound to me like "it's fine, there's a safety and a clever mechanism that prevents shooting yourself in the foot". Maybe it's all fine, but I'd for one feel more comfortable if the gun wasn't pointing at the foot in the first place.
Having a single syntax with multiple semantic meanings would indeed be a foot gun.
I can't think of a way how different syntax translating to a single semantic meaning could cause any concern. It's not like the wrong thing can happen, it just might look differently depending on codebase.
Re: Nim Version 1.6.6 Released
#56Earlier quoted context omitted.
We take it very seriously, but there isn't a whole lot we can do unfortunately. Apart from reporting false positives the only venue we could pursue is applying obfuscation practices used by actual viruses. This of course has its own slew of issues.
Yep, I mean, if the virus defence community took the same blanket, lazy approach with C and C++ compilers because viruses can be written in those, too (shock horror!) they'd be shutdown by some big players very fast.
Re: Nim Version 1.6.6 Released
#57A bit off-topic, but I'd like to see a language à la rust+gc, with pattern matching, traits, and the functional stuff rust got right, but without all the worries of lifetimes, and maybe some easier trait management (function signatures become very ugly imo). I've heard the claim that lean is going in this direction.
Re: Nim Version 1.6.6 Released
#58I wish they would take the antivirus issue on Windows more seriously https://github.com/nim-lang/Nim/issues/17820 This issue alone means I can't use it at work, and I haven't put much time and thought into Nim as a whole because I could only use it in private toy projects. I understand it's mostly the AV vendors fault and the devs shouldn't have to worry about a problem they haven't caused, but for me, this grinds re…
Re: Nim Version 1.6.6 Released
#59Hi, is Nim a good replacement for python? I write a lot of scripts, but I find that python can get cumbersome to maintain. I'm looking for something with stricter typing and a sane packaging/directory system, but also easy/fast to write. If Nim can work with numpy it's a plus
Nim goes further there by removing the need for tools like Pandas and numpy. You don't have to write code in "Pandas-style" because native Nim is equally fast and sometimes faster.
Re: Nim Version 1.6.6 Released
#60Earlier quoted context omitted.
This is an interesting take, I do see the value. If I was trying to prevent this type of aliasing, I'd have the compiler throw an error if there were two aliased variables names (xyz and XYZ for example), rather than merging them automatically.
That's what --styleCheck:error is for.
--styleCheck:error strictly enforces camel case.