The imports in Nim also soured me on it. Import a module and it puts a $ in your namespace for stringifying its types. It’s clever but Rust/Zig/Python import explicitness is preferable to Ruby/Nim/C imports.
Yeah I understand that Nim is statically checked so it’s not exactly like Python’s from foo import *.
Still, you have a bunch of imports and your code calls a function. There is no way from looking at the source text to determine where that function came from.
I think they’re referring to the fact that in Python/Rust/Zig import foo doesn’t import everything in foo into the current namespace, and instead names have to be qualified in order to reference them foo.bar, foo.baz, foo.etc.
Whereas in Ruby, as I understand it, the default behaviour is for require to pull everything from the referenced file into the current namespace.
Whereas in Ruby, as I understand it, the default behaviour is for require to pull everything from the referenced file into the current namespace.
Well, not quite “everything” - but true, if you require something that isn’t wrapped in a namespace (a top level module or class) you might get a surprise.
Any constants or globals within the loaded source file will be available in the calling program’s global namespace. However, local variables will not be propagated to the loading environment.
This can certainly be a surprise if you use global constants, like APPLICATION_LOGGER or something like that.
+1 Similar philosophy, although different decisions, to Go. And it’s again really refreshing.
The imports in Nim also soured me on it. Import a module and it puts a
$in your namespace for stringifying its types. It’s clever but Rust/Zig/Python import explicitness is preferable to Ruby/Nim/C imports.https://github.com/nim-lang/Nim/wiki/Nim-for-Python-Programmers#imports has a nice summary of Nim’s import syntax. https://narimiran.github.io/2019/07/01/nim-import.html discusses how the default (recommended) way is safer than Python’s
from x import *: tldr; Nim is statically typed so two functions with the same name but taking different arguments do not collide.Yeah I understand that Nim is statically checked so it’s not exactly like Python’s
from foo import *.Still, you have a bunch of imports and your code calls a function. There is no way from looking at the source text to determine where that function came from.
Could you expand on what you mean here? Do you mean the magic imports in Rails, or something in ruby itself?
I think they’re referring to the fact that in Python/Rust/Zig
import foodoesn’t import everything in foo into the current namespace, and instead names have to be qualified in order to reference themfoo.bar,foo.baz,foo.etc.Whereas in Ruby, as I understand it, the default behaviour is for
requireto pull everything from the referenced file into the current namespace.Thank you, that makes sense.
Well, not quite “everything” - but true, if you require something that isn’t wrapped in a namespace (a top level module or class) you might get a surprise.
https://ruby-doc.org/core-3.1.2/Kernel.html#method-i-require
This can certainly be a surprise if you use global constants, like APPLICATION_LOGGER or something like that.
Some more practical details here:
https://www.oreilly.com/content/ruby-cookbook-modules-and-namespaces/#rubyckbk-CHP-12-SECT-3
I liked the talk, but am left wondering if I’m supposed to know the guy. Is there more background besides what’s on YouTube?
All I know personally is that he’s an active member of the Nim community and has given a talk about a gamedev lib at FOSDEM 2022. That’s all I know.
https://www.youtube.com/watch?v=uYFEJUEOHPI