About the first simple generics example shown from VMath (I don't know if this was a simplified version) how can the type system allow arithmetic operation on any type T passed to it (as there are no constraints shown)?
How does path filling work for very large shapes? Do you still have to cast the scaline over the whoe bounds, or can this be limited to the viewport? I noticed that in Chrome, when you display very large SVGs, rendering becomes really slow, but only if convex shapes are included.
I’m just starting with nim but I’m already amazed not only by its unique feature set but also community which provides such a great solutions and presentations. Thank you for this video 🎉
Python standard library actually *recommends* using requests. Like how weird is that? It's like placing your stl in in a legacy box by definition. If its too complicated to be in the standard library sure, but requests in the year 2022 needs to be in a standard library or the stl is garbage.
You could just use () instead. Nim allows that You can go all the way from: proc hello(): void = ( echo("Hello Nim") ) To this: proc hello = echo "Hello Nim"
I disagree. Continuation passing style is something that looks like it doesn't belong into a language like nim & where one would use things like iterators or coroutines or another async flow control syntax.
Your libraries are pretty cool man, congrats. Im interested in doing something similar to Shady, where instead of GLSL it outputs VEX. I was wondering if with your current approach, is it feasible to use GLSL libraries via doing bingings? I guess you can do ad hoc substitution but not sure
Guys, ffmpeg has loudness normalization built-it. It's just a single command to bring your volume to a comfortable level before uploading. Step up your game.
Sorry don't use Rust. In Nim it just feels like an extra wrapper that annoys you. Isn't Rust is all about trading annoyance for safety so I can see how it fits well there?
@@treeform that is a perfect description of return monads in Rust. IMO Kotlin handles this better with syntax for marking nullability, null-coalescing, and an operator for "if (this == null)".
Andre, you convinced me on the case insensitivity issue. Flame wars are annoying. In fact, Nim needs some other changes to prevent even more flame wars: - Change imports to python-style imports, because python developers want to write python in Nim - HN doesn't like whitespace, so let's change Nim to use braces - Remove any memory management except manual, because HN taught me that's the only way to be fast - Rewrite the compiler in Rust, that would get endless upvotes on HN The roadmap is so clear now. With this approach, Nim will be popular in no time. Long live HN-oriented development! /s On a more serious note, I understand your frustration. I think the flame wars are a sign of people being interested enough to keep an eye on Nim, but not enough to actual learn how to use it. There's always a lot of excitment discussing things happening IN Nim itself. What's missing is exciting things being BUILT WITH Nim. We could look at Zig as a comparison. Where is Nim's Mach Engine or bun.sh? Not specifically, but in spirit. Nim has a ton of useful features and libraries, but not enough shiny ones.
The difference with the other flame wars you've listed is that there are other languages with such features *and* there are good reasons why Nim does things that way: - Change to Python-style imports: this would break Nim's UFCS, so we cannot do it. And there is plenty of other languages that do it the same way. - Whitespace: Python does it the same way (even Haskell has a bit of this!). Objectively it makes sense to use indentation (something which every programmer already does) to delimit scope. - Remove any memory management except manual: funny you mention this because that is kind of what's happening, with arc/orc Nim is following this hype. I personally feel that the gc is fine. But again, plenty of languages that just have a GC. Style insensitivity is only done by Nim. There are no other languages that do things this way. This means it puts off a significant majority of people and the objective benefits of this feature can be emulated using macros. Removing style sensitivity would also simplify Nim's implementation.
@@d0m96 It's not his conclusion I take issue with, I'm not sure where I stand on case sensitivity. Changing his mind based on HN-bikeshedding is what I think is counterproductive.
So I'll have to be honest and say that I commented before watching the video and based on how I read @Atlas' comment it read to me as "You've convinced me that style insensitivity makes sense" :) Please consider adding sections to the videos, skimming through a video to find the style insensitivity section wasn't easy. For those looking it starts around 26:50. Now that I've watched that segment I agree with your take @treeform. I've been seeing this come up for now almost 13 years, it's always the same arguments and honestly I have been of the opinion for a long time now that we will save each other a lot of time by just getting rid of this style insensitivity. The time I waste arguing about it with newcomers is not worth the benefit I gain from the feature. As you've alluded C wrappers are not usually what you want to use directly anyway, so you're writing a higher-level binding which will have the right style anyway. It's in Araq's hands to decide though. I hope he does so soon.
Even with braces you still use indentation. You now have two things to achieve one effect. I think it indention is more fundamental than braces if you are going to use ONE technique for describing structure it sure is not braces or parenthesis ))))))) (Lisp I am looking at you). Next!
