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

81–90 of 121 posts

Re: Nim in 2020: A Short Recap

#81

Post by cb321 »

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…

I just watched that Facebook F8 talk Araq gave up on quickly. It is a very high-level software engineering management sort of talk which actually becomes pretty clear pretty quickly. While at FB they may be engineers, at many other companies they could almost have been MBAs. I take Araq's comments as simply a lack of interest in discussion at that level, and his need to make said comments just an explanation to the conversor there and hardly worth making a big deal over.

In any event, even if you radically disagree with Araq's personal communication style, I think you should still give Nim a try. Many people do not like Linus Torvalds' communication style and still use Linux with great joy...

Re: Nim in 2020: A Short Recap

#82

Post by planetis »

doteka wrote: post #80
adenozine wrote: post #76

Earlier quoted context omitted.

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 w…

Fair point, although yourself gave me the wrong impression initially. karax doesn't support stateful components indeed.

Re: Nim in 2020: A Short Recap

#83

Post by nimmer »

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…

Nim has multiple memory management strategies with very different trade-offs.

ORC provides performance comparable to Rust but without having to write the boilerplate.

https://nim-lang.github.io/Nim/gc

https://nim-lang.org/blog/2020/12/08/introducing-orc.html

Re: Nim in 2020: A Short Recap

#84

Post by adenozine »

doteka wrote: post #80
adenozine wrote: post #76

Earlier quoted context omitted.

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 w…

I'm on mobile, but I'm certain Odersky was brutalized for "Pimp my library" or Pimp my Classes or something like that some years back.

I can appreciate your perspective a little more from your clarifying it. I stand by my original point that this is something NOT to be handled in public.

You're certainly right that it'd be hard to find Rich Hickey making an ass out of himself. I can't see myself arguing that anyhow. I guess I don't really think Araq made an ass out of himself in making that comment, especially with the context of the conversation. I think there is a lot of pretentious attitudes in front-end circles, and it's certainly very irritating to listen to people talk so highly of these things as if they are pristine towers of brilliance when it's JUST a webpage.

Re: Nim in 2020: A Short Recap

#85

Post by beagle3 »

dom96 wrote: post #66
beagle3 wrote: post #65

Earlier quoted context omitted.

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”

> The Nim forum has recurring questions about deserializing JSON that only make sense if you assume Nim is runtime dynamic like Python. Nim is a statically typed Python, and actually the way you can deserialise JSON is very Python-like, so I'm not sure where you got this from. Here is an example: Python: >>> import json >>> j = json.loads('{"foo": 42}') >>> j["foo"] 42 Nim: import json let j = parseJson("{\"foo\": 42…

But replace the last line with 3+j["foo"] in python (and respectively, echo (3+j["foo"]) in Nim), and the Python prints 45 whereas the Nim compiler greets you with ~40 lines of output asking you what exactly you meant.

Just to clarify: I'm not complaining. I'm happy that the compiler bugs you to do 3+int(j["foo"]) if you're going to treat it as an int. But I don't consider Nim a statically typed Python.

(Also: am a very satisfied owner of a dead-tree version of the Nim book. Thanks! Highly recommended. And dom96 is awesome in general)

Re: Nim in 2020: A Short Recap

#86

Post by weitzj »

elcritch wrote: post #56
jononor wrote: post #44

Earlier quoted context omitted.

The relative simplicity of the language is a feature. I can imagine introducing Nim to embedded/microcontroller firmware developers that only know/use C99 now. I cannot imagine introducing Rust - while a great language, it is C++ level complexity - and that is not always warranted.

Nim fits great on microcontrollers! Benefit is that it compiles to C and therefore can run anywhere C can. It also lets you reuse all the rest of the embedded C environment and build tools, which given the nature of embedded toolchains is handy for hitting the ground running. Rust's standard library/runtime binaries are really heavy compared to Nim's.

How are your esp32 Nim deployments holding up? Do you have futur plans for the new esp32 riscv processors?

Re: Nim in 2020: A Short Recap

#87

Post by zubspace »

mattarm wrote: post #77
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.

This largely depends in the IDE. The thing is, that a language like Nim is 'competing' with other languages like Java, C# or Python where interactive debugging is a given. I would highly prefer a language which compiles down to C code, but it's hard to give up an IDE like Visual Studio or Eclipse.

I know that many strong developers do not care that much about debugging or can use GDB without thinking. But unfortunately I'm not one of them. And I fear that Nim will stay a niche language because of that..

Re: Nim in 2020: A Short Recap

#88

Post by GordonS »

the__alchemist wrote: post #59
leandot wrote: post #4

In what cases is Nim a better option than Rust? Would be great if anyone with more experience can share more information.

This is subjective, but I prefer Nim's python-like scoping syntax; ie no semilonons nor curlybraces. Someone else in this thread posted a comment to the opposite effect! That said, I don't see a compelling class of projects to use it on instead of Rust. I'll consider Nim next time I'm looking at making a python project. However - most of the times this happens is if I'm making a web backend or doing something numeric…

Funny how personal preference with regard to some syntax is so polarising - I'm coming from a primarily C# background and while Nim looks interesting, I find the lack of semicolon line endings and the whitespace-based scopes, to be really off-putting!

Re: Nim in 2020: A Short Recap

#89

Post by GordonS »

cb321 wrote: post #55
runald wrote: post #12

Too bad nim uses a whitespace-sensitive syntax like python, something I personally dislike.

This comes up all the time, but in Nim you can almost always use parenthesis instead of whitespace [1] if you really love that redundancy/style. [1] https://forum.nim-lang.org/t/6897#43184

Yeah, but having 2 ways is a cop-out, IMO - if I'm writing code in a language, or reading someone else's for that matter, there is an expectation of it being idiomatic.

Re: Nim in 2020: A Short Recap

#90

Post by cb321 »

GordonS wrote: post #89
cb321 wrote: post #55

Earlier quoted context omitted.

This comes up all the time, but in Nim you can almost always use parenthesis instead of whitespace [1] if you really love that redundancy/style. [1] https://forum.nim-lang.org/t/6897#43184

Yeah, but having 2 ways is a cop-out, IMO - if I'm writing code in a language, or reading someone else's for that matter, there is an expectation of it being idiomatic.

In this, and a great many other ways Nim provides a lot of syntactic choice. A pro to some. A con to others.
Post reply on HN