Discussing Nim 2.0

Подписаться 292

Просмотров 6 тыс.

50% 1

Nim 2.0 has been a hot discussion topic lately. In this video we share our thoughts on the many things being discussed for the upcoming new version.
0:00 Intro
2:20 --mm:orc
4:32 --threads:on
8:00 overloadableEnums
10:18 dotOperators
3:00 -d:ssl + puppy
17:38 zlib + zippy
19:35 async stack traces
21:37 Backward compat cleanup
22:35 Optional and not nil
26:52 Style insensitivty
30:16 Big vs small standard lib
34:35 Concurrency in Nim
39:50 Closing
Video is discussing this post: forum.nim-lang.org/t/9266
Open source Nim repos mentioned in this video:
github.com/treeform/vmath
github.com/treeform/puppy
github.com/treeform/zippy
github.com/treeform/windy

Опубликовано:

8 авг 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 31

@ZoomRmc 2 года назад

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.

@micycle8778 2 года назад

I'm watching this video at 153% volume 😄

@henrikholst7490 Год назад

RU-vid have this built in by now?

@TechnologyBudda Год назад

Subscribed. Keep it coming

@Nox3x3 2 года назад

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.

@d0m96 2 года назад

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.

@Nox3x3 2 года назад

@@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.

@treeform 2 года назад

@dom96, I super agree with you. Style insensitivity is just an odd thing to have.

@d0m96 2 года назад

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.

@henrikholst7490 Год назад

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!

@renghenkow 2 года назад

continuation passing style should be in the nim standard, from there, we can build any construct, the nim cps is a great example of that

@FrankHarwald Год назад

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.

@renghenkow Год назад

@@FrankHarwald cps can be used to build those control flows in libraries.

@henrikholst7490 Год назад

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.

@CTimmerman Год назад

Ikr? And neither does resume. There are pip and poetry patches in limbo for that.

@hammer86_ 2 года назад

Complaining about style insensitivity is even worse than complaining about white space -- it's optional.

@treeform 2 года назад

Exactly, I am just tried of seeing comments (like yours above, and mine right here) mentioning it all the time.

@_slier Год назад

@@treeform still gonna say it, white space sensitive language is weird as hell

@CTimmerman Год назад

@@_slier It sucks at oneliners, but code should normally be indented, anyway.

@matthiasschuster9505 Год назад

@@_slier I wouldn't use any other one

@bigtymer4862 2 года назад

Option type is a godsend… have you guys never used rust??

@treeform 2 года назад

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?

@SJMG 9 месяцев назад

@@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)".

@bokunochannel84207 Год назад

talk about nim with complain about windows in between, good job, so professional.

@user-vj4ql5ul7q Год назад

LOL windows

@_slier Год назад

if only nim is curly based language.. i cant get through the white space sensitive

@CTimmerman Год назад

Then add curlies as comments.

@matthiasschuster9505 Год назад

You could like Haxe

@YodoJakamodo Год назад

Odd wish -- aren't the majority of choices for similar scope languages curly based? Why wish one out of twenty or so that isn't to be curly based?

@ViaConDias 5 месяцев назад

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"