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

Nim in 2020: A Short Recap

nim-lang.org

Post reply on HN
Print view View original

71–80 of 121 posts

Re: Nim in 2020: A Short Recap

#71

Post by planetis »

Symmetry wrote: post #68
Rompect wrote: post #41

Earlier quoted context omitted.

For normal purposes, dealing with Rust's lifetimes will be easier than spending some time "learning to use the GC correctly"

It really depends on what you're doing. If you've developing an OS or web browser or game engine you're going to be having to think about memory management very carefully in any event and dealing with Rust's lifetimes is just formalizing the work you'd be doing anyways. But most applications aren't optimized that heavily and as long as you don't have a memory leak or an algorithmic pessimization you don't have to wor…

Rust algorithm is only one way to do automatic memory management. And regarded as being very restrictive. The scheme Nim implements (ORC), which is innovative as well, is more permissive and unobtrusive. I hope in the next year it becomes the default.

Re: Nim in 2020: A Short Recap

#72

Post by cb321 »

Symmetry wrote: post #68
Rompect wrote: post #41

Earlier quoted context omitted.

For normal purposes, dealing with Rust's lifetimes will be easier than spending some time "learning to use the GC correctly"

It really depends on what you're doing. If you've developing an OS or web browser or game engine you're going to be having to think about memory management very carefully in any event and dealing with Rust's lifetimes is just formalizing the work you'd be doing anyways. But most applications aren't optimized that heavily and as long as you don't have a memory leak or an algorithmic pessimization you don't have to wor…

People do game engines in Nim. ReelValley was even a commercial effort. (This is only to supplement the parent comment, not contradict.)

Your mileage may vary, but several times I've tried some single threaded thing in both Rust, C++ and Nim and the Nim came out faster (e.g. [1] had final Nim version 5.0 ms, C++ 27 ms, Rust 42 ms), not putting much effort into any, and is likely more readable to someone brand new to the language. Writing generic data structures & algos in Nim is also a true breeze/pleasure. Anyway, they are all "fast and maybe-safe by default" and all respond similarly to optimization care. There is no obvious performance disadvantage (and compiling times are much better in Nim, yielding scripting language-like code iteration).

[1] https://news.ycombinator.com/item?id=24817594

Re: Nim in 2020: A Short Recap

#73

Post by doteka »

I’d love to give Nim a shot, but comments like these from the author make sure I’ll never be able to take the language seriously:

(Context: gitter thread about frontend state management/immutable data structures, https://gitter.im/nim-lang/Nim?at=59722654bc46472974112028)

Araq: meh, I cannot watch these hipsters talk

Araq: as soon as I hear “business logic” I stop listening

He felt compelled to make these comments about a conference talk from Facebook, who are arguably running the largest web application in the world, regardless what you think about Facebook. Such a lack of humility does not instill confidence in project leadership.

Re: Nim in 2020: A Short Recap

#74

Post by planetis »

rattray wrote: post #45
matthiaswh wrote: post #42

Earlier quoted context omitted.

I've written a large-ish amount of Nim code on personal projects while using Python day to day at work, and almost every time I'm working with Nim my brain is screaming at me at how unlike Python it is. Nim took some inspiration from Python's syntax, but the similarity is only skin deep. The construct of the language is very, very different resulting in code that usually looks and is structured differently. IMO going…

I'm curious - how would you describe the qualitative differences in code structure that results? Are there ways in which Nim nudges you to structure your code in better ways than you would in Python? Are there footguns?

Yeah, it values composition over inheritance (mentioned in the official tutorials) and discourages you from using methods and other OOP concepts. It's by far a procedural language. Functional style is also not preferred either, imho a good thing, fp does not result in fast code.

Re: Nim in 2020: A Short Recap

#75

Post by planetis »

pjmlp wrote: post #28
pizza234 wrote: post #2

Very interesting. Is the memory model essentially a middle ground between GC-based and manual memory management?: > Scope-based memory management (destructors are injected after the scope) - generally reduces RAM usage of the programs and improves performance. How does Nim handle references? How similar is this to Rust's lifetimes GC-ed instead of manually managed? Is this essentially like Rust, with the main differe…

Reference counting with cycle collectors is a well known algorithm, nothing new. Environments like Mesa/Cedar at Xerox PARC already made use of it, back in 1985. https://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/parc...

(I can't see the link, its offline) the difference is though, there is no expensive heap scans. That is new (it's called "trial deletion", see the Bacon paper) and makes it "deterministic" due to that, independently from the heap size and suitable for hard real-time systems https://nim-lang.org/blog/2020/12/08/introducing-orc.html

Re: Nim in 2020: A Short Recap

#76

Post by adenozine »

doteka wrote: post #73

I’d love to give Nim a shot, but comments like these from the author make sure I’ll never be able to take the language seriously: (Context: gitter thread about frontend state management/immutable data structures, https://gitter.im/nim-lang/Nim?at=59722654bc46472974112028 ) Araq: meh, I cannot watch these hipsters talk Araq: as soon as I hear “business logic” I stop listening He felt compelled to make these comments a…

Well, offer up your language of choice, and I'm sure we could work together to find some online comments to assassinate the creators' character.

Perhaps instead of trying to drag someone in a public forum you should've reached out to him and brought it to his attention. Gitter is an IRC-esque platform, it's not exactly designed for deep academic discussions and thoughtful prose, it's a chatroom.

Also, since you've seen fit to bring up Facebook's project leadership, perhaps you should look at the MANY failings of theirs. Cambridge Analytica is only the most notorious, there are thousands of cases of injustice done for users. For a brand operating behind a mission of "connecting the world," they sure are disconnected from serving some of their users.

Facebook runs an impressive ship, sure. They are worthy of much less of my respect than Araq. I've written Grow up.

Re: Nim in 2020: A Short Recap

#77

Post by mattarm »

zubspace wrote: post #53

I've used Nin for this years advent-of-code challenge. Never used Nim before but there are some great tutorials [1]. It's a nice language with a great standard library. Implicit static typing is great after a bit of getting used to. Some things like tuples or "Object Variants" are fun to use. The only thing I'm missing is strong debugging support. You can use GDB and there is even some basic support for debugging in…

I wouldn't consider interactive step debugging an essential feature in large programs. My experience with C++ is that once program becomes "large" or makes enough use of threads, gdb falls over anyway and you're stuck with logging and "print" debugging anyway.

Re: Nim in 2020: A Short Recap

#78

Post by pjmlp »

planetis wrote: post #75
pjmlp wrote: post #28

Earlier quoted context omitted.

Reference counting with cycle collectors is a well known algorithm, nothing new. Environments like Mesa/Cedar at Xerox PARC already made use of it, back in 1985. https://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/parc...

(I can't see the link, its offline) the difference is though, there is no expensive heap scans. That is new (it's called "trial deletion", see the Bacon paper) and makes it "deterministic" due to that, independently from the heap size and suitable for hard real-time systems https://nim-lang.org/blog/2020/12/08/introducing-orc.html

Here is a working link from archive.org

https://archive.org/details/bitsavers_xeroxparctddingGarbage...

Re: Nim in 2020: A Short Recap

#79

Post by planetis »

beagle3 wrote: post #65
dom96 wrote: post #50

Earlier quoted context omitted.

When I first found Nim I was looking for a faster compiled Python. I've found something that is much better: static types, less of an emphasis on OOP, static dependency-free fast binaries and macros all work together well to make Nim awesome to work with but what makes Python great is retained: speed of development, ergonomic syntax, and a small learning curve. > very weird concepts I'm curious, what weird concepts a…

The Nim forum has recurring questions about deserializing JSON that only make sense if you assume Nim is runtime dynamic like Python. And many random question start with “Python let’s you..” or “shouldn’t we make this more like Python” to which Araq rather consistently (and rightly) replies “no, because this is not Python”

Which post, the one forgetting that string literals in JSON are quoted or the other one that paid no attention on the nesting of JSON objects :P

Re: Nim in 2020: A Short Recap

#80

Post by doteka »

adenozine wrote: post #76
doteka wrote: post #73

I’d love to give Nim a shot, but comments like these from the author make sure I’ll never be able to take the language seriously: (Context: gitter thread about frontend state management/immutable data structures, https://gitter.im/nim-lang/Nim?at=59722654bc46472974112028 ) Araq: meh, I cannot watch these hipsters talk Araq: as soon as I hear “business logic” I stop listening He felt compelled to make these comments a…

Well, offer up your language of choice, and I'm sure we could work together to find some online comments to assassinate the creators' character. Perhaps instead of trying to drag someone in a public forum you should've reached out to him and brought it to his attention. Gitter is an IRC-esque platform, it's not exactly designed for deep academic discussions and thoughtful prose, it's a chatroom. Also, since you've se…

That would be a great argument, except I didn't start out with the intention of assassinating anyone's character. The above thread is literally the 3rd search result for "Karax state management". You know, a very reasonable search query when someone's trying to determine whether a frontend framework is ready for production use. This does not bode well.

> Well, offer up your language of choice, and I'm sure we could work together to find some online comments to assassinate the creators' character.

Yeah, okay, let's play that game: you asked for it. Let's try to search for "Reagent state management", also the foremost frontend framework for a relatively obscure language (Clojurescript). I guarantee you will not find Rich Hickey making an ass of himself on the first page of results. I'm fairly certain you won't find it in the results at all, because he is more mature than that.

Let's try again for Scala.js: "Slinky state management". Again, no sign of Martin Odersky acting like an immature jackass anywhere in the search results.

Words matter. First impressions matter. If you don't realize that I'm afraid you are in need of growing up yourself.

Post reply on HN