Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nim 2.0

nim-lang.org

Post reply on HN
Print view View original

161–170 of 213 posts

Re: Nim 2.0

#161

Post by mixmastamyk »

koromak wrote: post #143
sedatk wrote: post #135

So, Nim doesn’t seem to be under an umbrella of a non-profit. Isn’t this destined to be a problem at some point regarding either acquisition of rights or succession? Edit: Ouch. Just found this thread. Very disappointing, and actually makes a greater case for institutional ownership: https://forum.nim-lang.org/t/10312

I find using main a little obnoxious, but like who cares that much?

Right, I found such changes silly as well, but this kind of anger is a bad sign. Sounds like someone watches too much corporate TV.

If you can't handle a little silliness from humanity, might as well bow out now.

Re: Nim 2.0

#162

Post by kitd »

quazar wrote: post #55

https://github.com/belamenso/v This cleans up Nim's syntax a little, we use it in production with not much maintenance.

Still more readable than the average JS front end.

Re: Nim 2.0

#163

Post by foresto »

> Now one can define constructors and virtual procs that map to C++ constructors and virtual methods, allowing one to further customize the interoperability.

I hope this will help with bindings for C++ libraries that have historically been tricky to wrap.

For example, I would like to use Qt from a compiled language that's a pleasure to use, and this project looks promising:

https://github.com/jerous86/nimqt

Re: Nim 2.0

#164

Post by j-james »

59nadir wrote: post #157
j-james wrote: post #155

Earlier quoted context omitted.

> It's not so much a competitor (in performance or clarity) to Odin or Zig as it is a competitor to Go or something That seems accurate. Dealing with raw pointers as one does in Odin or Zig is very much de-emphasized in favour of dealing with safe references, and a lot of effort is put into optimizing out all the overhead of those reference checks (hence ARC/ORC) and writing code to evade them. The manual memory mana…

> I will also defend "naked imports" as a feature that works very well with the rest of the language: functions are disambiguated by signature and not just name and so conflicts scarcely occur (and simply force qualification when they do). And, this allows for the use of uniform function call syntax - being able to call arbitrary functions as "methods" on their first parameter. This is incredibly useful and allows fo…

> You can also not really have productive and well-fitting errors-as-values in a language that emphasizes UFCS

Eh, https://github.com/arnetheduck/nim-results and associated syntax from https://github.com/codex-storage/questionable would beg to disagree. Nim's stdlib does not have productive and well-fitting errors because it suffers from inertia and started far before the robust wonders of recoverable error handling via errors-as-types entered the mainstream with Rust and were refined with Swift (IMO). Option/Result types are fantastic and I do so wish the standard library used them: but it's nothing a (very large) wrapper couldn't provide, I suppose.

I do strongly think that other languages are greatly missing out on UFCS and I miss it dearly whenever I go to write Python or anything else. I'm not quite sure how you think UFCS would make it impossible to have good error handling? Rust also has (limited, unfortunately) UFCS and syntax around error handling does not suffer because of it. If by errors-as-values you mean Go-style error handling, I quite despise it - I think any benefits of the approach are far offset by the verbosity, quite similarly to Java's checked exceptions.

(in general concerns surrounding performance of errors surprise me - they're errors! they shouldn't be hit often! but if they are, you can certainly avoid such performance hits in nim.)

Re: Nim 2.0

#165

Post by skitter »

sedatk wrote: post #135

So, Nim doesn’t seem to be under an umbrella of a non-profit. Isn’t this destined to be a problem at some point regarding either acquisition of rights or succession? Edit: Ouch. Just found this thread. Very disappointing, and actually makes a greater case for institutional ownership: https://forum.nim-lang.org/t/10312

Was about to bring up that thread. Having a dictator for life isn't a good combination with that dictator going on unprompted, unhinged rants.

Re: Nim 2.0

#166

Post by [deleted] »

rbjorklin wrote: post #9
jadbox wrote: post #4

Anyone have working experience with Nim and Zig? I'd love to hear how they are similar and contrast. I'd also would like to see some idiomatic web server benchmarks between the two (now with Nim v2).

Zig doesn’t seem to have an implementation for the TechEmpower Benchmarks but Nim does: https://www.techempower.com/benchmarks/#section=data-r21&l=y...

[deleted]

Re: Nim 2.0

#167

Post by cb321 »

ElegantBeef wrote: post #125
pzo wrote: post #119

Earlier quoted context omitted.

that looks interesting, thanks! Did you try it if it delivers on promises? There was not any new commit since 2020 so not sure if the project is stale by now.

I do not use Rust, so sadly I have not.

As a 2-step approach, you could also probably use https://github.com/mozilla/cbindgen and then Nim's native C FFI.

Re: Nim 2.0

#168

Post by plainOldText »

fastball wrote: post #12
rbjorklin wrote: post #9

Earlier quoted context omitted.

Zig doesn’t seem to have an implementation for the TechEmpower Benchmarks but Nim does: https://www.techempower.com/benchmarks/#section=data-r21&l=y...

And I'm surprised by how terribly it ranks – basically dead last against everything, even the Python frameworks, which is impressive.

For reference, here's some other benchmarks which show happyx (a Nim framework) to come on top: https://web-frameworks-benchmark.netlify.app/result

Re: Nim 2.0

#169

Post by pshirshov »

I like capability separation with tags, though typeclasses are weird, higher-kinded types are not supported and implicits are weird.

Re: Nim 2.0

#170

Post by treeform »

FireInsight wrote: post #146
treeform wrote: post #68

Earlier quoted context omitted.

We have written pixie: https://github.com/treeform/pixie . Pixie is a 2D graphics library similar to Cairo and Skia written entirely in Nim. Which I think is a big accomplishment. It even has python bindings: https://pypi.org/project/pixie-python/

Is pixie capable of realtime usage like in games or generative art? Last time I looked it seemed CPU-only.

Not by itself! But together with other library boxy you can: https://github.com/treeform/boxy

You should use pixie to load textures, create text, rasterize vector graphic etc... and send them to boxy to be drawn every frame.

Yes Pixie is CPU only, and just like you can't use Cairo or Skea for real time games you can't use Pixie, but boxy you totally can.

Post reply on HN