There are many third-party libs which make using Vulkan much easier, all the way up to Game Engines which abstract everything. That isn't a argument against Vulkan. A good graphics API, even a web one, is one that…
I'm not sure what you're implying.. you can turn on most optimizations and still keep nil-checks on in Nim (either the whole project via --nilChecks:one, or select portions of code via {.push.}). Unless you're claiming…
> I should clarify: What's confusing me is the indexing stuff. I'm not sure if this is referring to something about the `Option<T>` or something else. By indexing, I meant as an alternative to references.. For example,…
So I remembered correctly, Nim does not reach UB in non-release code (or rather, code without --boundCheck:on), it throws an exception. I still think this is a reasonable solution. We catch these errors during…
You prove to the compiler that the nilable var is not-nil via if statement. Eg: proc foobar(f:Foo not nil) = discard let f = Foo() # nilable ref let b: Foo not nil = f # Error, can't prove 'f' is not nil if f != nil:…
> there are strictly more steps involved when you have null pointers. Well yes, and both Nim and Rust have non-nil pointers.. I suppose I misread your original statement as "Rust is objectively better ..." when you…
I was measuring with pcwalton's ruler.
...because zebra's are not a universally useful modelling tool to programmers like references are. Thus, the absence of a reference, ie nil, also becomes a useful, commonly used modeling tool. If we all wrote software…
> It's not verbose. "Option" is 6 characters. ".map" is 4. I just want to note that verbosity isn't just about symbol length, but also about operator noise and the number of available or required commands used to…
No worries. I also wasn't implying you where trying to discourage Nim, and I hope my post didn't come off as accusatory. Cheers! EDIT: > The solution here is to just use a reference instead of an arbitrary index. Ah,…
> it is useful for the compiler to force you to handle the case in which pointers are null. Well I agree that it's very useful (and we have that in Nim), but.. > With constructs like Option::map the code is usually even…
> Rust's compiler prevents you from moving data into a method which then nulls it out Just for clarity, we have this in Nim too, eg: type Foo = ref object Bar = object val: Foo not nil let f = Bar() # Error, 'val' must…
I agree the concept of 'non-nil' vars is very useful (and we have that in Nim), but I'm not entirely convinced by the rest of that argument. Namely, I don't agree that nil is rare enough to justify the verbosity Rust…
So Rust has some cool safety features, especially for concurrent code. But, and perhaps I'm just uninformed, I never really understood the safety benefit of Rust's 'never nil' design. Nil is a useful modelling tool,…
Err... what you said just reminded me of something, and I realized all the code I just showed you is really over-complicated and that Nim has much more straight forward options using `const`, like this: static: # define…
> can static: sections assign to an array that will be available at runtime? The answer is yes, but it's a tad trickier than just accessing the compile-time list from run-time code (which doesn't make sense, and is…
I'm not sure exactly what you're asking, but I can answer at least part of it. You can build lists at compile time in Nim via the `static` statement or `compileTime` pragma. Eg: # using the pragma here, but we could use…
Not that it's even really needed... Just select the section of text and use your IDE's shortcuts to comment it out (which now works fine in any IDE due to comments no longer being part of the AST)
Ridiculous. We use "special tools" for every other language (Visual Studios, Eclipse, etc).. Calling a language feature, which give programmers style freedom, a "tortured lexical structure" is not an objective argument.…
In practice, resolving symbols is not really harder. Once you understand the symbols rules, your mind is very good at finding the match. Plus the real solution is proper IDE support with "goto definition". IMO, the…
There are many third-party libs which make using Vulkan much easier, all the way up to Game Engines which abstract everything. That isn't a argument against Vulkan. A good graphics API, even a web one, is one that…
I'm not sure what you're implying.. you can turn on most optimizations and still keep nil-checks on in Nim (either the whole project via --nilChecks:one, or select portions of code via {.push.}). Unless you're claiming…
> I should clarify: What's confusing me is the indexing stuff. I'm not sure if this is referring to something about the `Option<T>` or something else. By indexing, I meant as an alternative to references.. For example,…
So I remembered correctly, Nim does not reach UB in non-release code (or rather, code without --boundCheck:on), it throws an exception. I still think this is a reasonable solution. We catch these errors during…
You prove to the compiler that the nilable var is not-nil via if statement. Eg: proc foobar(f:Foo not nil) = discard let f = Foo() # nilable ref let b: Foo not nil = f # Error, can't prove 'f' is not nil if f != nil:…
> there are strictly more steps involved when you have null pointers. Well yes, and both Nim and Rust have non-nil pointers.. I suppose I misread your original statement as "Rust is objectively better ..." when you…
I was measuring with pcwalton's ruler.
...because zebra's are not a universally useful modelling tool to programmers like references are. Thus, the absence of a reference, ie nil, also becomes a useful, commonly used modeling tool. If we all wrote software…
> It's not verbose. "Option" is 6 characters. ".map" is 4. I just want to note that verbosity isn't just about symbol length, but also about operator noise and the number of available or required commands used to…
No worries. I also wasn't implying you where trying to discourage Nim, and I hope my post didn't come off as accusatory. Cheers! EDIT: > The solution here is to just use a reference instead of an arbitrary index. Ah,…
> it is useful for the compiler to force you to handle the case in which pointers are null. Well I agree that it's very useful (and we have that in Nim), but.. > With constructs like Option::map the code is usually even…
> Rust's compiler prevents you from moving data into a method which then nulls it out Just for clarity, we have this in Nim too, eg: type Foo = ref object Bar = object val: Foo not nil let f = Bar() # Error, 'val' must…
I agree the concept of 'non-nil' vars is very useful (and we have that in Nim), but I'm not entirely convinced by the rest of that argument. Namely, I don't agree that nil is rare enough to justify the verbosity Rust…
So Rust has some cool safety features, especially for concurrent code. But, and perhaps I'm just uninformed, I never really understood the safety benefit of Rust's 'never nil' design. Nil is a useful modelling tool,…
Err... what you said just reminded me of something, and I realized all the code I just showed you is really over-complicated and that Nim has much more straight forward options using `const`, like this: static: # define…
> can static: sections assign to an array that will be available at runtime? The answer is yes, but it's a tad trickier than just accessing the compile-time list from run-time code (which doesn't make sense, and is…
I'm not sure exactly what you're asking, but I can answer at least part of it. You can build lists at compile time in Nim via the `static` statement or `compileTime` pragma. Eg: # using the pragma here, but we could use…
Not that it's even really needed... Just select the section of text and use your IDE's shortcuts to comment it out (which now works fine in any IDE due to comments no longer being part of the AST)
Ridiculous. We use "special tools" for every other language (Visual Studios, Eclipse, etc).. Calling a language feature, which give programmers style freedom, a "tortured lexical structure" is not an objective argument.…
In practice, resolving symbols is not really harder. Once you understand the symbols rules, your mind is very good at finding the match. Plus the real solution is proper IDE support with "goto definition". IMO, the…