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

Nim Apocrypha, Vol. I

blog.johnnovak.net

Post reply on HN
Print view View original

51–59 of 59 posts

Re: Nim Apocrypha, Vol. I

#51

Post by beagle3 »

skulk wrote: post #39

> 13 Taming circular type dependencies I really despise the 'common' module approach because it scatters code that should be in the same file. One workaround I use to avoid this is to break the cycle of type dependencies by replacing one of the dependencies with a generic parameter. This works great if the type that has a generic parameter only deals with opaque objects of that type. Once concepts are fully supported…

> I really despise the 'common' module approach because it scatters code that should be in the same file.

If you have circular dependencies then, in my opinion and experience, it unifies code that should be in the same file, and which was wrongly scattered among different ones.

I remember reading the release notes on Turbo Pascal 6 (or was it 5? or Borland Pascal 7) with a weird half-assed support for circular type dependencies among different units, and trying to find a case where putting all the definitions in one file (and avoiding all these issues) wouldn't make more sense to me. It's been 30 years since, and I haven't seen an example as such yet.

I acknowledge there's no accounting for taste, of course.

Re: Nim Apocrypha, Vol. I

#52

Post by beagle3 »

qmmmur wrote: post #49
himujjal wrote: post #15

> Unless if you’re one of those NodeJS wielding kids who thinks Electron is a good idea and the web is the ultimate application development platform… Ignorance is bliss! MIC DROP!! Wonderful article. Nim is a great programming language. I am using nim and c these days as my primary languages.

Any recommendations for GUI program development with Nim?

You can do pure Windows with wNim or Winim and its few helpers.

If you are looking for cross platform, very graphical, not necessarily accessible, there's NimX. I think there's also a port of Dear ImGui called Nimgui.

If you are ok with webby interface, there's a Nim port of zserge's webview.

There's a discussion on the Nim forum you might find interesting: https://forum.nim-lang.org/t/5632

Re: Nim Apocrypha, Vol. I

#53

Post by mratsim »

mhh__ wrote: post #22
mratsim wrote: post #19

Earlier quoted context omitted.

State machines can be metaprogrammed: https://github.com/mratsim/Synthesis You describe the events, transitions and even interrupts and this compiles to optimized goto statements with no allocation, no indirect function calls, no switch statement. There are compile-time checks to make sure you don't have state with no transition from and it also produce a visual graph of your state and transitions. It's been tuned to…

I've seen people do similar things in D (although the "D way" of doing it would probably be to parse some kind of textual description and turn it into code at compile time). The cost/benefit of making a metaprogramming library just to write a lexer is fairly bad, however. wrt to the SMT integration, it's something that I would very much like to try in D, but it's quite difficult to work out exactly where to start (an…

For a lexer/parser you should use a coroutine / suspendable function abstraction. Or a parser generator.

Re: Nim Apocrypha, Vol. I

#54

Post by blackrock »

atombender wrote: post #47
jstimpfle wrote: post #12

Earlier quoted context omitted.

Citation required. How can Wirth languages (e.g. Pascal, Modula) have "the same capabilities for low level programming", but without the traps, of C derived languages (e.g. C, C++)? The idea suggests itself that you can have one or the other, but not both. Personally from trying it out, I like the speed resulting from the stricter module system. And there might be a little additional protection against bad builds res…

I'm not sure why any "citation" is needed here. C is widely accepted as being deeply unsafe language, and C++ has inherited those traits, and is still working on plugging the weaknesses some 35 years later. Of course you can do things like bounds checking manually in C, and run with all sorts of warnings enabled, and you can use static code analyzers that uncover entie classes of bugs, but the whole point is to never…

The problem that I see with Nim, is that it transpiles down to C.

So, does it mean, that Nim can inherit these unsafe behaviors of C? Or did the Nim language creators safely avoid the pitfalls of C?

Whereas a language like Zig and Rust, compiles its code down to LLVM.

Re: Nim Apocrypha, Vol. I

#55

Post by pjmlp »

blackrock wrote: post #54
atombender wrote: post #47

Earlier quoted context omitted.

I'm not sure why any "citation" is needed here. C is widely accepted as being deeply unsafe language, and C++ has inherited those traits, and is still working on plugging the weaknesses some 35 years later. Of course you can do things like bounds checking manually in C, and run with all sorts of warnings enabled, and you can use static code analyzers that uncover entie classes of bugs, but the whole point is to never…

The problem that I see with Nim, is that it transpiles down to C. So, does it mean, that Nim can inherit these unsafe behaviors of C? Or did the Nim language creators safely avoid the pitfalls of C? Whereas a language like Zig and Rust, compiles its code down to LLVM.

That is an implementation detail, nothing prevents a future release of Nim compiler to directly generate machine code.

Re: Nim Apocrypha, Vol. I

#56

Post by blackrock »

pjmlp wrote: post #55
blackrock wrote: post #54

Earlier quoted context omitted.

The problem that I see with Nim, is that it transpiles down to C. So, does it mean, that Nim can inherit these unsafe behaviors of C? Or did the Nim language creators safely avoid the pitfalls of C? Whereas a language like Zig and Rust, compiles its code down to LLVM.

That is an implementation detail, nothing prevents a future release of Nim compiler to directly generate machine code.

Fascinating. When will they do it? I would prefer it generate direct machine code instead.

Re: Nim Apocrypha, Vol. I

#57

Post by nimmer »

blackrock wrote: post #54
atombender wrote: post #47

Earlier quoted context omitted.

I'm not sure why any "citation" is needed here. C is widely accepted as being deeply unsafe language, and C++ has inherited those traits, and is still working on plugging the weaknesses some 35 years later. Of course you can do things like bounds checking manually in C, and run with all sorts of warnings enabled, and you can use static code analyzers that uncover entie classes of bugs, but the whole point is to never…

The problem that I see with Nim, is that it transpiles down to C. So, does it mean, that Nim can inherit these unsafe behaviors of C? Or did the Nim language creators safely avoid the pitfalls of C? Whereas a language like Zig and Rust, compiles its code down to LLVM.

> Nim can inherit these unsafe behaviors of C?

Not at all. You could apply the same reasoning for assembly: just because you can write insecure assembly it does not mean that all assembly generated by compiler is using vulnerable coding patterns.

Re: Nim Apocrypha, Vol. I

#58

Post by nimmer »

blackrock wrote: post #56
pjmlp wrote: post #55

Earlier quoted context omitted.

That is an implementation detail, nothing prevents a future release of Nim compiler to directly generate machine code.

Fascinating. When will they do it? I would prefer it generate direct machine code instead.

> I would prefer it generate direct machine code instead.

Why? C has been the best choice for Nim so far.

Compiling with Nim+GCC is much faster than Rust, it generates applications with comparable performance, and it supports way more architectures.

Post reply on HN