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

41–50 of 59 posts

Re: Nim Apocrypha, Vol. I

#41

Post by jstimpfle »

earwaxauditor wrote: post #35
jstimpfle wrote: post #34

Earlier quoted context omitted.

There is also "Rust is fine once you know how to not get burnt by the type system, and if you carefully choose your dependencies it will maybe still be able to start a build of your project a month from now, and if you're lucky it will build in less than a lifetime". Or "Java is fine if your fingers aren't sore yet and if you don't mind the latency spikes for your interactive application or if you're basically progra…

At least “this code doesn’t compile” isn’t a potential security vulnerability.

Sure, and projects that never ship aren't either.

Re: Nim Apocrypha, Vol. I

#43

Post by wffurr »

earwaxauditor wrote: post #35
jstimpfle wrote: post #34

Earlier quoted context omitted.

There is also "Rust is fine once you know how to not get burnt by the type system, and if you carefully choose your dependencies it will maybe still be able to start a build of your project a month from now, and if you're lucky it will build in less than a lifetime". Or "Java is fine if your fingers aren't sore yet and if you don't mind the latency spikes for your interactive application or if you're basically progra…

At least “this code doesn’t compile” isn’t a potential security vulnerability.

That's exactly the point I was trying to make.

Re: Nim Apocrypha, Vol. I

#44

Post by elcritch »

simias wrote: post #11
mhh__ wrote: post #7

Earlier quoted context omitted.

https://dlang.org/spec/statement.html#WithStatement D also has withs. Definitely in the "not necessary but nice to have" category of features, particularly when implementing state machines (i.e. statment soup)

I seem to be in the minority but I really dislike this type of sugar. I find that it always makes code harder to read because you can't disambiguate what the code is doing without some heavy context, and changes to the class can profoundly change the way the code is behaving without triggering as much as a warning. For this same reason I really dislike that in C++ you can just implicitly drop the "this->" to target c…

The Nim `with` macro by @zevv doesn't modify functions or methods (that'd require explicit handling in the macro to do so and would be a nightmare to do correctly). Which means that example from D is not applicable to the Nim version at all.

My preference is Nim over D primarily since Nim compiles to C, but also overall the community appreciates syntax sugar but also has a decent sense as to when and how to use it. Most "sugar" in Nim needs to be explicitly imported. Literally `import sugar` is one of my first lines in many files.

    let v = &mut some_annoyingly.long.thing();
    v.foo = bar;
    v.baz();
In the example you list (is that Rust, or D?), if it was in C or Nim and those were structs-within-structs and not pointers/refs then `.thing` would be copied to a new `v` (if I recall the semantics correctly). So you'd end up with a weird "logic" bug where updates would disappear. The Nim `with` macro solves that by modifying the generated code,

Re: Nim Apocrypha, Vol. I

#45

Post by elcritch »

zevv wrote: post #10
masklinn wrote: post #6

Earlier quoted context omitted.

> The `with` syntax is new to me, but it looks useful for dealing with lots of subfields. It's not syntax, but rather a third-party macro[0], which it should be noted is inspired by a rather horrible feature of the same name in javascript. Though I guess the devil would be in the details. [0] https://github.com/zevv/with

And I'm not even ashamed!

Thanks @masklin for pointing that out -- sloppy language on my side, but I also didn't realize it was a third party library. Thanks @zevv for the macro!

Re: Nim Apocrypha, Vol. I

#46

Post by elcritch »

jstimpfle wrote: post #40
kaba0 wrote: post #37

Earlier quoted context omitted.

As for the latter: Or you know, most applications don’t need manual memory management because more often than not, programmers WILL get it wrong. Unless you really need that level of control over the hardware, you ARE better off with a good runtime env

That may be, but personally I am interested in those applications - GUI work, signal processing, low-latency networking.

Nim, with the new ARC garbage collector works well for those situations now (well within a few percent usually). Especially with the `move` and `sink` semantics.

I'm using it in embedded devices and needed a few tight loops a week or two back. With a bit of work and a few odd contortions, I got it to compile to almost the exact type of C code I'd write by hand to run a fast inner loop using preallocated arrays, etc. It turns out that code wasn't noticeably faster than more idiomatic Nim code with a few tweaks to ensure move's were able to be used. So I ended up going back to the more readable/idiomatic version while still roughly doubling the overall speed.

The new `move` semantics with Nim's ARC system really do help make it easier to write fast code. Now I understand why the C++ ecosystem is so bullish on `move` in the C++ stdlib now. It really can take code which looks like straightforward C code but performs closer to painstakingly optimized C code. Mainly since it result in less copying of objects/structs and reducing the number of malloc's. Overall it means less effort to design a fast system.

Re: Nim Apocrypha, Vol. I

#47

Post by atombender »

jstimpfle wrote: post #12
pjmlp wrote: post #4

Earlier quoted context omitted.

Nim is heavily inspired by Wirth languages, where you have the same capabilities to do low level programming, without the traps of C derived languages.

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 get that far in the first place.

I worked with Borland's Pascal dialect for 10+ years, and it offered a great deal of protections while still allowing you to use unsafe constructs when you needed to get close to the metal (e.g. pointer arithmetic and even embedded assembly code). But "safe by default" solves a lot of problems.

Re: Nim Apocrypha, Vol. I

#48

Post by jstimpfle »

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…

Pascal's low-level semantics are comparable to C's. That's why I dispute that it doesn't have the same traps.

I agree that if you program C by emulating higher-level object systems, it becomes unmanageable and a lot of bugs around object lifetimes appear, and they're very hard to fix.

I personally don't have a great interest in such object systems, but fail to see how C++ should be any worse than Pascal in terms of perceived safety resulting from the higher level of abstraction.

Re: Nim Apocrypha, Vol. I

#49

Post by qmmmur »

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?

Re: Nim Apocrypha, Vol. I

#50

Post by beagle3 »

elcritch wrote: post #3

Excellent! Lots of good tips. The `with` syntax is new to me, but it looks useful for dealing with lots of subfields. Its also a good point that while Nim looks like Python, it very much isn't. Nim is overall much better designed from a computer science perspective with saner scoping rules, etc, IMHO. That means that while Nim as a language is relatively complex, overall its easier to work with than C++ or even Pytho…

Nim is a huge language, but it is very well designed, and unlike e.g. C++, you can use and discover its feature gradually - including when using 3rd party libraries. It has lispy macros (except reader macros - you start with a parsed-to-ast text), closures, effect tracking, C/C++ level performance &interop and a lot more - but somehow, somewhat by language design and somewhat by community standards, you don't need to fully understand these things (and hardly to be aware of them) when writing your own Nim code or when using 3rd party libraries.

(Whereas in C++, you can pick your own subset for your own code, but as soon as you pull in a 3rd party library, you HAVE to understand the preprocessor, templates, often template metaprogramming, lambda capture rules if that library is built for them, etc).

Post reply on HN