I've been working with golang and Nim for side projects for a few months, and well... I really like both a lot. Having coded in Python for what seems like forever, Nim is feels like the fast Python without training wheels I've always wanted. Golang, nothing bad to say there, either, but I like reading Nim code more.
Nim Apocrypha, Vol. I
31–40 of 59 posts
Re: Nim Apocrypha, Vol. I
#32Earlier quoted context omitted.
> bounds checking enabled by default for arrays and strings You can make your own explicit bounds checks, or you can use valgrind (which, just like any type system, can understand only simple situations). You can use C++ which actually does allow you to do bounds checking by default, if you're into such things. > - real enumerations that aren't implicit converted into numeric types (fixed in C++11, if one bothers to…
> You can make your own explicit bounds checks, or you can use valgrind (which, just like any type system, can understand only simple situations). You can use C++ which actually does allow you to do bounds checking by default, if you're into such things. Yeah, apparently Google, Apple, Microsoft think otherwise. > Now tell me, why exactly is "new Foo[count]" safer than "ALLOCATE(Foo, count)"? Or just do this minimal…
> 1- Everyone needs to create their ALLOCATE macro
This is not an issue at all. It's one (!!) line. And the (huge) advantage is: Everybody can create their own allocation macros. Not all allocations are born equal: Some need specific contexts or arenas/pools where to allocate from, some want a specific alignment, some want zeroed memory...
And again, you don't even need this macro, it's just cosmetic. Better invest in some structure that reduces the number of required allocations to a small constant (per type or subsystem).
> and not everyone does it right
This is like saying, don't write code because not everyone is doing it right. This is almost the simplest type of code you can imagine.
> 2 - Actually it fails with certain kinds of type given as parameter
Which ones, then?
--- For the rest, trying to de-flame this and not to reply, and maybe be actually productive for an hour this afternoon :-)
Re: Nim Apocrypha, Vol. I
#33Earlier quoted context omitted.
> You can make your own explicit bounds checks, or you can use valgrind (which, just like any type system, can understand only simple situations). You can use C++ which actually does allow you to do bounds checking by default, if you're into such things. Yeah, apparently Google, Apple, Microsoft think otherwise. > Now tell me, why exactly is "new Foo[count]" safer than "ALLOCATE(Foo, count)"? Or just do this minimal…
> 1- Everyone needs to create their ALLOCATE macro This is not an issue at all. It's one (!!) line. And the (huge) advantage is: Everybody can create their own allocation macros. Not all allocations are born equal: Some need specific contexts or arenas/pools where to allocate from, some want a specific alignment, some want zeroed memory... And again, you don't even need this macro, it's just cosmetic. Better invest i…
I wear the scars from comp.lang.c with pride, old songs never go out of tune apparently.
Re: Nim Apocrypha, Vol. I
#34Earlier quoted context omitted.
> Undefined behavior UB in C has some unfortunate historic problems, and is _probably_ way too complicated. But UB per se is needed for a number of really important optimizations - for example, for array indexing using 32-bit integers you need to be able to assume that index-scaling operations (implemented as multiplications/shifts) don't overflow. > null terminated strings null terminated strings are like 10-50% spa…
Optimization war stories aside (which is cool, thank you!), this reads like the classic apologetics "C is fine if you just use it correctly". Whereas in practice large C and C++ projects and libraries regularly suffer from severe security vulnerabilities exploited in the wild specifically from buffer overflows and use-after-free bugs.
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 programming like C with training wheels and less performance".
;-)
Re: Nim Apocrypha, Vol. I
#35Earlier quoted context omitted.
Optimization war stories aside (which is cool, thank you!), this reads like the classic apologetics "C is fine if you just use it correctly". Whereas in practice large C and C++ projects and libraries regularly suffer from severe security vulnerabilities exploited in the wild specifically from buffer overflows and use-after-free bugs.
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.
Re: Nim Apocrypha, Vol. I
#36Excellent! 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…
> 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
There's also stdlib's with (https://nim-lang.org/docs/with.html), though for some reasons I'm not aware of it doesn't seem listed in the stdlib's ToC :/
Re: Nim Apocrypha, Vol. I
#37Earlier quoted context omitted.
Optimization war stories aside (which is cool, thank you!), this reads like the classic apologetics "C is fine if you just use it correctly". Whereas in practice large C and C++ projects and libraries regularly suffer from severe security vulnerabilities exploited in the wild specifically from buffer overflows and use-after-free bugs.
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…
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
Re: Nim Apocrypha, Vol. I
#38[deleted]
Re: Nim Apocrypha, Vol. I
#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 (they may already be now), this pattern will be able to describe more complex relationships.
Re: Nim Apocrypha, Vol. I
#40Earlier 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…
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.