Nim has become too complex, although the complexity may be optional and avoidable until necessary. I don't know if this is a plus or a minus, but it is starting to scare people.
@@ViaConDias I'd say it's the other way around. It can take me anywhere from an hour to a day trying to setup build environment for C and C++. 20% of dependencies I'd use in Rust I'll end up just writing from scratch in C++ because including them in the project is not worth the effort. And then I have to run the code every 5th file I edit so I can locate the seg-fault.
The presenter focused on the 2.0 release notes which are just the latest rough edges in the language to be rounded out. . . and that completely misses the primary strengths and really neat features of Nim. The shortest explanation of Nim I'd make is: as easy to learn as Python, 95% of the type safety as Rust without the unusual syntax, dirt simple C/C++ interop, fast builds and freaking easy to install on the big 3 platforms.
The main problem Nim's trying to solve is that of a programmer wanting a single language that's very elegant and expressive, that's also crazy performant, and gets out of their way so they can solve the other problems they come across.
I believe it's THIS.. THIS right here. So that people who have coded in Python and even others who haven't, can start coding right away with almost all the features of C++ without any complex syntax to throw them off their prime motive, which is to build really fast, powerful and lightweight applications.
Nim is literally for low-level systems programming; it tries to follow the same niche as C as a general purpose language, but with more modern concepts and quite a bit more memory safety. It runs as fast as Rust in some cases, and it can be easily modularized. I think the more adoption it has, the more of its merits you'll be able to see. Personally, I think Nim could use a more dedicated support for networking, with packet encapsulation and other things that would truly make it stand out in embedded systems programming.
I started learning Nim a few days ago. I'm enjoying it tremendously. I would describe it as a pleasant language. It's easier to get into for me than Python was, let alone Rust.
"Nim is a good language for everything." You may be skeptical while reading this, but I really think this is true. Yes, there is a steeper learning curve, but if you're already familiar with C and Python, it is not really that hard. You can use it to program CLI programs, GUI programs, servers, microcontroller firmware, OS kernel, websites (Nim can also be compiled to JavaScript), etc. It may have a bit strange sytax at first but I really like it the most of all languages I tried. It writes easy like Python but has a C performance. Yes, there is are a few new concepts which can be harder to understand at first, but you don't need to really worry about them at first or at all if you don't need them (like macros/metaprogramming). However you can do wonders when you try to learn them. Things on which I would like to see improvements on are a little better docs / tutorials and more mature ecosystem (comes with time).
"It writes easy like Python but has a C performance", I think this is hands down the best thing about Nim. Development is so quick while its performance matches that of C++. The only thing holding me back from fully committing is that it doesn't support cyclic imports, which is especially awkward for gamedev.
@@Miaumiau3333I go to tremendous effort to ban cyclic imports in JavaScript. No other languages I use really support them. Why do you want cyclic imports?
@@Miaumiau3333 Cyclic imports are coming (possibly this year but more likely next year), but until then I'm using a hack I made that basically concatenates all types and puts everything in one file. There's an experimental feature called package level objects to deal with this, but since the feature will be removed with cyclic imports and my hack works for now, I'm not bothering to use it.
anything that focuses on metaprogramming is shit it leads do incomprehensible and slow code, while also wasting a load of time thinking how to make the code even more cute
Nim can produce extremely small binaries so it's probably the nicest way of writing for embedded devices. Outside of that Nim doesn't solve much, but combines the best of multiple languages as it tries to be simple but still universal. Nice Python like syntax, but with a strong type system, proper async implementation, compiled, powerful compile time macros and not far behind Rust and C in speed. The main problem of Nim is the small adoption and everything that comes with it.
@@JulzaaI wrote the same program in Nim and Go. Nim used 22KB after stripping the binary and Go uses 925KB after stripping. Both of them used a release build.
"Why do you use Nim?" for me I am using Nim Lang because it feels like compiled lightning fast python, rusts memory safety, with the modern bells like types people lose their mind over in TS (I hate TS tho). It feels like I can write C code as a python/JS dev basically, and have it run in all kinds of places. No more JIT compilers like JS/python and having to use docker to ship my code.
@@davidoffonly well go is definitely more popular so you will have more luck with it, but i would recomment sticking to more traditional backend languages such as java or node, or god forgive php.
I've not written a lot of nim, but the bit I have aha been very fun. I think the core idea is the same performance as C with more abstraction, and without having to do manual memory management. The "killer feature" is probably making macros a normally part of programming. Having macros be type safe and easy to write let's you do lots of cool things at compile time.
The impression I got from Nim, in general, is a macro assembler, or Lisp. Its a Wirth family language (like pascal or delphi) but where anything can literally mean anything in the right context. And on top of this, it comes with a buffet of features that don't seem to be added to the language with any consideration of consequences or their relationship to other language features. You just go around farting pragmas into the ether to turn on and off various parts of the compiler and various places in your code. These things are great if you are hacking away at something all by yourself. As soon as you add a second person to your project though, you are fucked.
Not wrong. It's also that a lot of features are added to the language completely blindfolded by the consequences in the compiler complexity. The features work in test examples, but as soon as you compose it with other featuers, you hit a lot of compiler bugs.
About the C++ thing: I think the C++ interop targets people that don't like C++ but are forced to use it if they want to use a certain library that is only available for C++. If you like C++ better use it directly :)
I don't think that people who actually like C++ are not that many. I am not talking about people who only know C++ and are forced to like it if they don't want to hate their lives.
@@krux02 I see your point. A place where I think Nim could shine is greenfield projects that need to interface with things that are released only via C++ APIs (like Qt, for example), since Nim can use APIs and doesn't need to use ABIs to interact with C++ (which are known to break from a compiler to another since are not standardized), since it compiles to C++ source code and can use C++ directly. For example Nim exceptions are compiled to C++ exceptions at C++ source level so catching a C++ exception from Nim can be trivial, while doing so in other languages is not trivial since they communicate with C++ via a binary interface and need to speak the Itanium C++ exception ABI which is painful.
@@lorenzogabriele9533 Regarding Qt interop. Nim can be used to interact with the Qt metaobject ecosystem perfectly. Just port the Qt moc to nim macros and write everything signals and slots in Nim. This will give you a much better integration of the language into the Qt world than the C++ moc does as the moc relies on C macros that expand to nothing and have to be paced into a predefined header file structure that may not use templates. With the moc ported over to Nim, you can write whatever you want, nim generics just work. I've once started a proof of concept of this, and it got so far that I would say, totally possible. But I stopped at some point, mostly because I don't actually use Qt anymore. But totally possible. At that time I thought it was more attractive than their own scripting language.
I chuckled when he said OCaml is "getting faster industry adoption". Dude, OCaml is 1 year younger than JavaScript. OCaml is not getting wide adoption in some "blowing up sense." It's pretty obvious to me good ol' Prime is listening to his some-times co-host a bit too much 😅
@@jobahd3626 yeah but he is scoffing (as I am, in jest, too) at things like Haskell and F# et al, for not being mainstream, when those have more industry adoption than OCaml. The OCaml community is much, much smaller than Haskell - and compared to other languages both are niche. He asked "what's the point" (for good reason) when it comes to Nim (or any language really) - the same can absolutely be said about OCaml, a FP language that is less flexible and due to being not-fully-FP actually is worse. Haskell, when asking people who do FP, comes across as quite a lot better. So, I said this comment in jest, but there's a bit of truth in there too. He obviously listens a bit too much to his "co host", who is simply just a OCaml-evangelist.
@@simonfarre4907 I've always thought of F# as the upstream of C# as C# keeps adopting features from it. Thus, never going to gain the popularity it deserves.
I think ocaml has wider or perhaps thicker adoption than nim right now. What I mean by thicker is that it has a more entrenched community. And there's less a chance that people using ocaml rn will switch to something else. Not so much with the other languages mentioned I guess. That said I mostly agree with everything said here in this comment section.
It isn't conceptually difficult, it's just that Ocaml is a old ass language and the syntax is ugly af. A lot of the overall syntax/semantics can be grossly simplified and that's why you see modern FP languages have much simpler looking syntax (e.g Lean).
Nim is for people who like Python and it's syntax (or are simply used to it), but want it faster and with some additional features, for certain programs.
I haven't actually written anything in nim for like a year now (school taking my time and now I'm working as a dev), and woah totally forgot we were still waiting for Nim 2.0! I should take a look when I have the time to update QRgen to use this new version!
How about instead of having a language that "solves a niche-problem" having a language that fits most use cases. And can be adapted to fit pretty much every use case instead of having to learn or create a new language each time. You can write C and Javascript libraries in it, you can interop with C/C++, Python or JS. It compiles fast, runs fast and is about as productive as Python.
In order for OCaml it to see mass adoption, it will require 40-year old tech leads who passed it by 27 years ago when it was new to admit that they were wrong. That will never happen in the near future.
nim is like "what if we took pascal and added compile time macros and common lisp condition system" ocaml is great, but last time I've checked (mid-22) cross compiling with dune was really, really bad to the point F# is fine but using it in big projects is a pain because the compiler is linear, slow and doesn't support proper incremental builds yet
Hmmm still skeptical. Is the exception handling a lot better than Rust? And does NIM not have a GC? (Dont like GC's) because mostly don't need them and if you nees them u can use an Arena.
incremental builds ~kinda work~ the main project will have to redo type checking even when only a dependency changed and it will take a while to rebuild (at last 3 seconds to do it here) watch mode is also not properly implemented, using it will restart the app on any chance instead of reloading the code I love the F# language, but using it for GUI is awful due to the build times
the guy literally goes against his own claims.. that everyone wants to be first to make yt content for easy traffic about some new tech or news/release..
Nim has great potential but think its doomed to always be very niche. Andreas Rumf is an absolute genius, but he's also a bit of a dictator with Nim, similar in a way to Ryan Carniato with SolidJS. In order for these projects to really fulfil their potential, they have to be allowed to outgrow their creators, and its not easy to hand over your baby for the greater good.
Nim is good for writing malware but it’s still simple enough to quickly prototype and get the idea down. Also python needs an interpreter as you know versus nim creating an executable. But yeah, mostly known for malware but I think it’s a cooler python. My favorite thing is you can pipe method similar to bash. Lots of coolness here
What's the source on the "mostly known for malware" statement? I'm curious because I haven't heard this and I've been flirting with Nim for a few years now.
@@UxerUospra lot of new malware and ransom ware out in the wild is written in nim. A lot of AV’s actually fire on any nim code being compiled because its so heavily signatured. Check out the Offensive Nim repo
The same thing happened to go for a while. If your language does anything novel it becomes harder to reverse with traditional tools so malware devs will use it just for that little layer of obfuscation for a bit.
@@UxerUospr Because up until recently the compiler and many binaries made with nim were flagged by some antivirus software, since they had unique signatures of some malware found in the wild that was not frequently found in legit software. Also because it's very easy to write a small static binary that has no dependencies.
Two main problems that Nim solves at the same time, Large Memory Usage and Easy to program. Nim is a C with Python syntax. The software world does not have something like that.
@15:00 The problem with OCAML, at least historically, was its lack of good concurrency. As I recall one of the main devs was very anti-concurrency in the platform and argued it couldn't be done well. Whereas that's exactly what Erlang is and proves the contrary. I really wish there was an Erlang like platform with strong typing. Erlang syntax/matching/actors/binary type/etc. + OCAML typing. I know a lot of people dislike Erlang's syntax but I enjoy it. The language itself is very simple and can be completely understood without too much effort. Reminds me of C or base Lua in that sense. It is hard to do truly crazy shit with the language that makes someone else unable to follow the code.
@@ModinthalisJust read over the changelog. Eh. Yeah. They added threading in the form of "domains". It's pretty simplistic from what I can tell. And really not surprising given that one of the main OCaml devs years ago was very openly against a complex system like Erlang. OCaml has some really nice features but this "domain" thing feels like a hack.
What would make me want to switch from C++, personally, is a language that has similar power to build efficient and effective abstractions as C++, but has more regular syntax and concepts (C++, in its attempts to please everyone, creates lot of rules with lots of little special cases, which ultimately helps no one), more modern ecosystem and tooling, and less UB in silly places. I don't think it's a huge ask, but for some reason nobody seems to have tried it. You either get something like Zig, that got rid of much that was bad about C++ but also everything that was good, or Rust, which retains more of the good things but is opinionated in bizarre ways. I don't think it's impossible for a language to be multi-paradigm but just remove some of the archaic stuff, like the C syntax with all its problems, the issues with parsing templates, or weird limitations that come from the language having compilers running on the weirdest hardware. C++'s biggest problem, the committee model, does present an incentive for jumping ship, it's just that there aren't any real alternatives yet.
@@jugurtha292 As far as I've seen, it's meant as a successor for C++ written with the Google C++ style guide in mind, that is, a C++ that neuters or removes many of the things that are good about C++ in favor of making it more accessible to large numbers of (potentially poorly vetted) programmers in a huge enterprise. It's not so much what I'm looking for. I'm interested in Herb Sutter's cpp2 project, but my optimism is much guarded because some complexity seems to be creeping in due to the need for compatibility with current C++, and I don't know how much of an improvement the final product will be when all's said and done. But a lot of the 'heart' seems to be in the right place at least.
Seems like Nim would be pretty much up your alley. It has almost all the C++ features that make it powerful but it is also simpler. The syntax is far away from C++, but the semantics are pretty close. Generics are C++ templates. The `when T is bool` you have template specialization. There is no distinction between method and free standing function. And most importantly, no header files. There wasn't something from the c++ that I missed. And if I would miss something, Nim compiles to c++ and you can somehow make that feature accessible with emit statements.
@@krux02 Semantic whitespace is a deal breaker. Seems petty, but when I'm blocking out/prototyping I don't want to bother with indentation when making quick changes. I'm also very happy letting clang-format take care of 99% of my formatting needs. The experience writing python and manually managing indentation is very clunky by comparison, and I don't want to deal with that for my daily driver. Also, isn't Nim garbage collected? That's the wrong default for me.
@@isodoubIet I don't like this Argument. There are many good reasons to avoid Nim (in its current state), but superficial details such as indentation based blocks is not one of them. It is at worst a bit annoying, but it would never cause major bugs or prevent you from doing something.
Be careful with the wording. GC means stop-the-world to many people. Automatic memory management is the generalized term. ARC/ORC (the default mm as of 2.0) are reference counting and fast enough for hard real-time.
@@dwhall256 Yea, I know, unfortunately, But people are just going to have to wake up to the new world and understand running highly optimized code on today's hardware with a GC is as fast as a C just a few years ago, so the convenience, speed of development, and safety far far FAR outweighs the tiny impact on performance. The performance impact that, in some cases isn't even measurable. But thank you, I will try to use AMM in the future for the slow people in the crowd 😅
The allure to me as a beginner noob is that nim looks like a Family of languages. The way you might pick a Debian-based Linux and you have transferable skills for A LOT of other distros. The transpiling/cross compiling makes it appear to be a bargain, five languages for the price of learning one.
i'll tell you nims niche, it can interop with python and transpiles to c, so basically it can be used to extend python and make it efficient very easily without shooting yourself in the foot. and since it transpiles to pure c you can port it anywhere you want. just think out of the box
It's even better than that. Because it compiles to C, it means that every **single** c library can be seamlessly used with nim, the process of building a wrapper is so simple that a lot of automated tools exist to take a header file and automatically write a nim wrapper for it. Nim doesn't really try to appeal to a niche. It tries to be a general all purpose programming language. Which is hard and probably the wrong approach because the main question will be: why use a new, niche programming language when we could use something like c++, java, rust, c#, ect
@@dolorsitametblue Yep, I use them for both. Always isolated to one procedure or abstracted in some way to isolate unmanaged memory as much as possible.
Nim is nice but the tooling is just horrible and maintainers do not seem to care nor do they try to onboard people into contributing which makes me think nim will have a hard time finding its place
This is so true. Araq does't care about tooling at all. If anything he accepts PRs that fix something tooling related, because he gets pressured to do so. But he doesn't care and often makes things even more complicated for tooling.
@@krux02 yep. For instance at some point learning nim I wanted to improve nimsuggest and first the codebase is just horrible second no documentation third when I build it on MacOS without touching anything it just randomly segfaults and the worst part is that I asked for help both and discord and GitHub and nobody seemed to care. So even if the language has some good points coding in it makes me super unproductive because the tooling is lagging behind. Been with rust since then and I'm happy lol.
Sadly its creator acts like an old man who shouts at the clouds... When people reach out to help with the documentation or ask if they can use it for production, the replies they get is borderline mind-blowing. they point blank get attacked! Good luck getting anywhere with that attitude Nim seems like a very good language but the way things are now, it is never gonna get widely adopted
What tooling do you lack in Nim? Here's my setup: Atlas for workspaces and package management. Nimble tasks for building, testing. Neovim with 'alaviss/nim.vim' for smart syntax highlighting and tab completion. Inim repl for small experiments. GDB - debugging, Valgrind - profiling. It's not perfect, but I don't see it as horrible either.
8:10 Not by retunging stuff from expressions. Just try it in rust. let x; // not mutable if true { x = 1; } else { x = 2; } println!("{x}"); x = 3; // error: x needs to be mutable
I've never liked treating paths at special. Just write good path manipulation functions, and users won't feel the need to split or join path strings nonportably.
If you know python then Nim is probably the easiest starting point. I like that it's syntactically super easy while being statically typed and dynamically compiled with C++like performance. It's just easier than similarly powerful and performant languages.
I tried Nim because the code is more reminiscent of Python and Pascal than C++. I stayed for the Universal Function Call syntax ("func1(func2(var1))" is the same as "var1.func1.func2"), easy overloading, and generics. Why the easy C/C++ interop? Because they have the libraries already developed.
Reads change log, claims to not understand the language it had never ever seen before. Still spouts baseless opinions. You can bet it happened on Twitch.
Nim looks strange and is kinda cool, but I think I'm not gonna learn it... not because It's bad, but because learning Go or maybe C++/Rust looks like a better idea
Рік тому+6
Unless you already know Rust and Go. A third is not that bad.
@@krux02 Im learning and its a really nice language. I can be productive in it even been new. Later I'm gonna try Rust, maybe after 5 reasonable projects in Go
I would say C++ particularly if you are interested in gaming and graphics. Nim also has interoperability with all the major gaming and graphics libraries.
I have to say that the argument of "what is Nim even for" is a piss-poor argument. It is less a valid question, and more unfair criticism. From the looks of it, it can be for a very wide spectrum of uses.
One of the issue that Jonathan blow and Casey moratori, have talked about a lot and I really agree with is that modern languages tend to do the same mistake. Instead of nailing the fundamentals of the languages, meaning (performance, readability, expressiveness, tooling, compiler control / good error messages, flexibility) languages people try to be the Jack of all trade, but end up being the master of none, I know this go against what a lot of people seem to think, but to me languages like C and Go, Zig and potentially JAI or Odin, should be the end goal, languages that are simples, that follows sort of sensible syntax conventions, have good toolings, languages that are readable and expressive, languages that don't rely on unmaintainable obfuscated syntax and abstraction to make it look like your doing some real work when all you do really is niching and fighting the languages quirk. Like in languages like C if you want a behaviour or something you just need to write more C, same with Go but modern languages are doing the weirdest things, to try to cater to all audiences, instead of focusing on the fundamentals. I don't belive nim will go anywhere.
Can someone explain Nim to me? I watched his stream for the first time yesterday (always just seen him in clips) and he spent roughly 80-90% of the stream talking about forsen and his viewers. Is that what all his streams are? Does he not do anything else but talk about another streamer all day?
Yea, I couldn't watch it either. He clearly wasn't interested in Nim, he just did it because it was a community request and wasted to have that part done. But he din't do Nim justice at all. I can sum up Nim for you. It's an algamation of Pascal, C++, Python-syntax and lisp macros with a buggy compiler, that has tons of surprise features that are documented nowhere but has a single test somewhere in the test suite, horrible code quality in the compiler, denial towards actual problems that need to be worked on and hostility towards anybody who exposes these bad conditions to the public. It has an interesting feature set, that allow really productive working. But also a lot of unstructured mess in the standard library.
@@krux02 Nimskull is promising; But anytime a community that size is fractured to this degree -- it's extremely worrying. So much of small-scale language-dev (if you want to get popular at least) is social-engineering and there's a LOT of social-problems that need to be solved a long time ago and kicking out very productive but quirky/dysfunctional core devs (Disruptek) over a few really-not-big-at-all incidents in the grand-scheme of things, and two-to-three years later you still don't have the incremental-compiler delivered, amongst other things. Deep technical issues only get fixed (or are radically improved) when there's enough social-cohesion to hold stuff together. Again, think Nimskull is pretty promising on this front, and they're doing some important work (technically) but this needed to happen YEARS ago. People still see Nim as mostly "cooler python" and that value-proposition starts to look a looot weaker with things like Mojo and maybe even GIL-less Python on the horizon. So if time hasn't already ran out already... really feels like it's about to. Which is tragic, still think it's a really unique and interesting language; With not much else out there like it. There's a lot of value there, but that doesn't mean people / groups are able to capitalize on it sadly. Still crossing my fingers.
@@krux02 so, would you say that apart from just giving the language a try for fun, the language would - at the moment - be worth a try to use for a small customer-project or maybe for tools to be used in-house? But not something to invest in for using long-term in production?
@@stevepositivdon't listen to that guy. Lots of ppl shit on nim mainly cause the creator isn't politically correct enough so there was some drama with forks a la ayo.js. It's not popular but used for some production software. Nim's main sponsor currently is an eth node implementation (another reason some might hate nim) using it for the insane networked algorithms that eth now requires after moving from mining to staking - it's a very high stakes environment yet it works completely fine, nim is production ready. Some studio used it for gamedev as well. The official website, docs and forum are all almost completely implemented in nim as well (except for databases and nginx), including the frontend (javascript is one of the compiler targets, also custom SPA framework), there's even an email client in the standard library which is used for the forum's verification emails, so it's good enough for all those things as well.
@@stevepositiv If you need to write small (few hundred lines at most) command line utility or something then it can be used instead of python. If you will need to debug or maintain that code for a long time, forget it.
Nim's selling point is that it has Python-like syntax, but actually statically typed (with good type inference and metaprogramming too) and obviously faster than python (everyone is faster than python, right? =P). That's my take. It's not a niche though. It's more like a 'flavor' instead of a targeted niche. But Odin is not niched for games or graphics. It's more like a general purpose language. Imagine if C and Golang had a baby... that baby just got a Zig's haircut but his genes are from C and Golang. The idea is so much more awesome but the stdlib just need to mature a little bit more (as well as ecosystem, like dependency management and stuff)
Odin is still pretty much targeted for graphics. Why do I say this? For example GB won't add operator overloading, instead he just add the types you would need operators for to the language and makes the operators built in. Namely vector types. But other domains, where you need your own BigInt, or Rational type, you are out of luck. He will never see the need for metaprogramming, because he own the compiler and can just add whatever he needs for his graphics and simulation focused application, built into the language. The language is great if your application is in the same domain as GBs application. If you differ, the language is solid (solid is still very good, but not great).
I'm enjoying Odin, actually. It's being an aspirin for my Nim headaches. I fundamentally disagree with the notion that _"data is just data, and data has no behaviors",_ which is the reasoning for the lack of support for OOP, but I very much like the tendency for simplicity and many other things. I also like that it uses "snake_case" as its preferred style convention.
I think that the (short) history of computer programming has shown that humans are bad at talking to computers. A great deal of the progress software development has made since Assembly was invented in 1947 has been about abstracting away the computer’s architecture from human input. Compiler design has improved so much that expert manual instruction will only beat it 1/1000 times. For 99.9% of programmers we will never be able to beat a good compiler. The next step in this evolution is manual memory management: good automatic memory management is now safe but an expert programmer can beat it for performance. That’s not going to be the case forever.
I don't get why people are saying Nim is easy for Python devs - Nim is so overloaded with features that it's probably easier to learn something like Java. (Not saying it's bad tho)
Rewriting micro services from Python to Nim is easy. For scaling up in Kubernetes the cost starts adding up if you wrote everything I. Python and really embraced the micro service Pattern.
The creator of the language itself is saying Nim is not for everyone when people ask for better documentation or examples :D It is for people who have enough time to dive into the Nim source code to be able to write a simple program
My main disappointment about Nim is that it has this multicase variables thing going on; I don't know what it's called. Basically, it's something like a variable called foo_bar is the same as fooBar - super weird. But the main selling point for Nim, I think, is that it uses Python-like syntax. So, the target users are those who use Python and want more power. I use Python for small CLI scripts, window manager stuff, etc., but I'm not yet convinced (interested) enough about Nim.
It's called style-insensitive (instead of case-insensitive). The first letter is case sensitive. It allows you to write all your code in your preferred style even when using libraries that use the other style.
At first I thought this might be a nice idea, but over time I started to hate it. It ended up being completely useless to me, because I find it more of a hassle to keep code consistent with my _snake case_ style, than to just go with whatever code completion gives me. And it's also annoying because it gets in the way of my own preferred naming conventions, and of the original styles of some library bindings. In the case of raylib bindings, for example, raylib uses PascalCase, but you shouldn't do that in nim because it will make your editor highlight the functions as if they were type names. Personally, I used to love nim, but not anymore. Having to constantly keep fighting the language was driving me crazy. Odin has been a relieving breath of fresh air.
There are some good use cases for it, as DiThi already mentioned. It may seem somewhat counterintuitive at first, but when used with discretion it can actually increase your style consistency. That being said, it is a feature, you don't have to use it. If you want you can explicitly disable it with --styleCheck:usages --styleCheck:error.
The only thing I know about Nim is a guy having a meltdown in a Discord server about how it was excusable for the then-unstable Nim compiler to leak memory from a hello world. I think it was version 0.6, not 0.0.1 or something.
I don't know if it changed by now, but back then the attitude towards compiler memory leaks were pretty much: "who cares, the compiler is a short live executable anyway that collects all garbage of process exit"
I've spent some time playing with Nim sometime ago. I was excited because Nim looked like everything that Python3 failed to accomplish. I was just willing that Nim could gain more adoption, more popularity and more libraries. Nim was actually fine. Now I see Nim 2.0 and... honesty... I think the designers killed off the language. Why I should use Nim when Python, which is simpler, is already here and when Rust, which is far more powerful, is already here? Introducing Nim 2.0 which is far more complex than Python and not as powerful than Rust seems like the developers are looking for an audience which simply does not exist.
What? It's actually quite fast. It builds the whole tooling, consisting of the compiler, package manager (nimble), nimsuggest, test runner (testament), alternative package (atlas) manager in under 4 minutes in a 2020 laptop.
Generally I would say yes. But it also prevents people from creating bullshit identifier names, such as `__name__` in the first place. So I guess it is not just negative.
@@krux02 dude, you can still create stupid names like `var_____x` or `varX_XxXx`. I've seen people throwing that argument around for such a long time that it boggles my mind how people don't see it holds no water. Case/underscore insensitivity prevents nothing. Also, `__name__` isn't a stupid thing at all. It's very much a requirement in python and lua and some others to avoid name clashes with user defined keys, because internally python classes are dictionaries, and in lua they're tables, and users can easily create a property or method called `init` or `name`.
@@skarutsbut it still prevents some people from creating intentionally (newbies) or by mistake identifiers like: varX, var_x, var___x and var_X *in the same project*. A good example of bad practices is X server where some function names only differentiate by case - you can't do this in Nim. And if you import library that uses some weird style you can still use your preferred style to interact with it. var______x = varX, varFoObAr=varFoobar Nim doesn't stop fevelopers from OBFUSCATING their code, but it doesn't claim to do this.
@@dolorsitametblue that's like saying the broken vacuum cleaner is still sucking 0.00001% of the dust on the floor, so it's working great. It's useless. It prevents nothing. It's like you read my comment without reading it. It's the easiest thing to circumvent. var______x =/= varXx varFoObAr =/= varFoobar2 That argument doesn't hold any water, and never did, and never will. And in my experience, it's just as useless for style consistency, unless you're, for some odd reason, really so bothered about lib code not looking like yours, that you're willing to keep going through the trouble of making code style consistent over and over. The way I see it, the cons vastly outweigh the pros. It gets in the way of personal conventions a whole lot, and that's one of the many reasons I ended up ditching Nim. Used it since 2017, and so far I haven't found an actual good reason for style-insensitivity to exist. (At first I thought it was a good idea.)
It's funny to watch you kinda crap on Nim towards the end then be like Ocaml makes so much sense after you've already written things with it. Who cares if a language is a general language and it's not designed for some specific niche use case. Some languages just click better mentally with people. For me I'm liking coding in Nim that's probably all that matters now to me. At one point I would watch stuff like this and literally change languages but yeah not now.
Nim is a higher level C that compiles to C/C++. Zig wants to fix C, but Nim already did - you can even compile Nim emitted C code with the Zig compiler... Zig wont be done for a long, long time but Nim is mature with a host of libraries and an excellent package manager. Nim is extremely simple to use - unless you want it complex: then you can have it complex; to the point where you start sweating profusely, gasp for air and ask for mama. So Prime: grow some hair on that bony chest, become a real man and start learning you some Nim - would ya?
"Nim fixed C - by transpiling to it..." Yeah, it doesn't fix or replace C in that case. It just relies on it. Which makes Zig a superior replacement for C by default, just because Zig actually replaces C and Nim doesn't.
honestly, this is the first time I got bored, there is too much prepossessing before understanding what you are actually doing, 4 months tops not visiting the language everything goes poof!!!
Nim is for people who don't want bloated binaries like Rust and want system performance with safety even faster than Rust and as a bonus they aren't politically motivated like Rust
Obviously if your first contact with the language is via a release note which tackles improvements about the specificities of a language and thus meant to be checked by seasoned nim programmers you won't find it really readable
![[UPDATE] Mojo Is Faster Than Rust - Mojo Explains More](http://i.ytimg.com/vi/MDblUyz0PtQ/mqdefault.jpg)
Nim is for when you want to write low-level systems code but you don't hate yourself and aren't a masochist.
i know who is those words for
Yup
Rust is for when ASM and C is just to easy and to fast to develop in and you are paid by the hour so you need to work slowly 😉😅
Nim has become too complex, although the complexity may be optional and avoidable until necessary. I don't know if this is a plus or a minus, but it is starting to scare people.
@@vcool I hope your fears don't become a reality." 😂😢
@@ViaConDias I'd say it's the other way around. It can take me anywhere from an hour to a day trying to setup build environment for C and C++. 20% of dependencies I'd use in Rust I'll end up just writing from scratch in C++ because including them in the project is not worth the effort. And then I have to run the code every 5th file I edit so I can locate the seg-fault.
Nim is great for writing code without being distracted by all the language features. If you need more power, it's there, but you don't have to use it.
The presenter focused on the 2.0 release notes which are just the latest rough edges in the language to be rounded out. . . and that completely misses the primary strengths and really neat features of Nim. The shortest explanation of Nim I'd make is: as easy to learn as Python, 95% of the type safety as Rust without the unusual syntax, dirt simple C/C++ interop, fast builds and freaking easy to install on the big 3 platforms.
The main problem Nim's trying to solve is that of a programmer wanting a single language that's very elegant and expressive, that's also crazy performant, and gets out of their way so they can solve the other problems they come across.
It also compiles to 1/10 to 1/100 the size of rust and go programs, which is a killer feature for embedded stuff.
I believe it's THIS.. THIS right here. So that people who have coded in Python and even others who haven't, can start coding right away with almost all the features of C++ without any complex syntax to throw them off their prime motive, which is to build really fast, powerful and lightweight applications.
@@user-hk3ej4hk7m I was shocked by how big the executables are in Go even for a small rudimentary program. 40 times bigger than Nim.
Nim is literally for low-level systems programming; it tries to follow the same niche as C as a general purpose language, but with more modern concepts and quite a bit more memory safety. It runs as fast as Rust in some cases, and it can be easily modularized.
I think the more adoption it has, the more of its merits you'll be able to see. Personally, I think Nim could use a more dedicated support for networking, with packet encapsulation and other things that would truly make it stand out in embedded systems programming.
I love the ORC name. The “O” is a visual pun because ORC is ARC + a cycle collector and the “O” is a circle, like a cycle.
What is the R for? 🤔
@@T1Oracle ORC is short for Cycle Reference Counting.
@@xeschire706 why not just CRC
@@KimberlyWilliamsch That can be confused with cyclic redundancy check.
I started learning Nim a few days ago. I'm enjoying it tremendously. I would describe it as a pleasant language. It's easier to get into for me than Python was, let alone Rust.
Rust is not a language its a joke on “smart” spoiled brats!
@@aftalavera rust aimed to be the new c++ and in a way, it is
"Nim is a good language for everything." You may be skeptical while reading this, but I really think this is true. Yes, there is a steeper learning curve, but if you're already familiar with C and Python, it is not really that hard.
You can use it to program CLI programs, GUI programs, servers, microcontroller firmware, OS kernel, websites (Nim can also be compiled to JavaScript), etc.
It may have a bit strange sytax at first but I really like it the most of all languages I tried. It writes easy like Python but has a C performance.
Yes, there is are a few new concepts which can be harder to understand at first, but you don't need to really worry about them at first or at all if you don't need them (like macros/metaprogramming). However you can do wonders when you try to learn them.
Things on which I would like to see improvements on are a little better docs / tutorials and more mature ecosystem (comes with time).
"It writes easy like Python but has a C performance", I think this is hands down the best thing about Nim. Development is so quick while its performance matches that of C++. The only thing holding me back from fully committing is that it doesn't support cyclic imports, which is especially awkward for gamedev.
the whole effects tracking system and the way exceptions work just seems hacked on with clunky annotation syntax
@@Miaumiau3333I go to tremendous effort to ban cyclic imports in JavaScript. No other languages I use really support them. Why do you want cyclic imports?
@@Miaumiau3333 Cyclic imports are coming (possibly this year but more likely next year), but until then I'm using a hack I made that basically concatenates all types and puts everything in one file. There's an experimental feature called package level objects to deal with this, but since the feature will be removed with cyclic imports and my hack works for now, I'm not bothering to use it.
anything that focuses on metaprogramming is shit
it leads do incomprehensible and slow code, while also wasting a load of time thinking how to make the code even more cute
Nim can produce extremely small binaries so it's probably the nicest way of writing for embedded devices. Outside of that Nim doesn't solve much, but combines the best of multiple languages as it tries to be simple but still universal. Nice Python like syntax, but with a strong type system, proper async implementation, compiled, powerful compile time macros and not far behind Rust and C in speed.
The main problem of Nim is the small adoption and everything that comes with it.
Is it just a bit more complex and tinier footprint Go then?
@@JulzaaI wrote the same program in Nim and Go. Nim used 22KB after stripping the binary and Go uses 925KB after stripping. Both of them used a release build.
@@djiekamjskskwks very impressive! I'm really struggling to get below 1MB with Go already (compiling for Linux)
@@Julzaa I wrote a small program to call a SaaS API endpoint and stream files in chunks and Nim was 200KB and Go was 7.5 MB.
"Why do you use Nim?" for me I am using Nim Lang because it feels like compiled lightning fast python, rusts memory safety, with the modern bells like types people lose their mind over in TS (I hate TS tho). It feels like I can write C code as a python/JS dev basically, and have it run in all kinds of places. No more JIT compilers like JS/python and having to use docker to ship my code.
is nim or GO is better on backend what do you think i am trying to get into web development
@@davidoffonly well go is definitely more popular so you will have more luck with it, but i would recomment sticking to more traditional backend languages such as java or node, or god forgive php.
Nim might be what i have been looking for
I've not written a lot of nim, but the bit I have aha been very fun. I think the core idea is the same performance as C with more abstraction, and without having to do manual memory management.
The "killer feature" is probably making macros a normally part of programming. Having macros be type safe and easy to write let's you do lots of cool things at compile time.
The impression I got from Nim, in general, is a macro assembler, or Lisp. Its a Wirth family language (like pascal or delphi) but where anything can literally mean anything in the right context. And on top of this, it comes with a buffet of features that don't seem to be added to the language with any consideration of consequences or their relationship to other language features. You just go around farting pragmas into the ether to turn on and off various parts of the compiler and various places in your code.
These things are great if you are hacking away at something all by yourself. As soon as you add a second person to your project though, you are fucked.
Not wrong. It's also that a lot of features are added to the language completely blindfolded by the consequences in the compiler complexity. The features work in test examples, but as soon as you compose it with other featuers, you hit a lot of compiler bugs.
One of the biggest usecases nim has it's seamless integration with python when python itself is too slow.
Thats gonna be less relevant when Mojo comes out
This is interesting. Thanks!
@@LiveErrors That will take quite a while. Hopefully, it will meet expectations.
About the C++ thing:
I think the C++ interop targets people that don't like C++ but are forced to use it if they want to use a certain library that is only available for C++.
If you like C++ better use it directly :)
I don't think that people who actually like C++ are not that many. I am not talking about people who only know C++ and are forced to like it if they don't want to hate their lives.
@@krux02 I see your point.
A place where I think Nim could shine is greenfield projects that need to interface with things that are released only via C++ APIs (like Qt, for example), since Nim can use APIs and doesn't need to use ABIs to interact with C++ (which are known to break from a compiler to another since are not standardized), since it compiles to C++ source code and can use C++ directly. For example Nim exceptions are compiled to C++ exceptions at C++ source level so catching a C++ exception from Nim can be trivial, while doing so in other languages is not trivial since they communicate with C++ via a binary interface and need to speak the Itanium C++ exception ABI which is painful.
@@lorenzogabriele9533 Regarding Qt interop. Nim can be used to interact with the Qt metaobject ecosystem perfectly. Just port the Qt moc to nim macros and write everything signals and slots in Nim. This will give you a much better integration of the language into the Qt world than the C++ moc does as the moc relies on C macros that expand to nothing and have to be paced into a predefined header file structure that may not use templates. With the moc ported over to Nim, you can write whatever you want, nim generics just work. I've once started a proof of concept of this, and it got so far that I would say, totally possible. But I stopped at some point, mostly because I don't actually use Qt anymore. But totally possible. At that time I thought it was more attractive than their own scripting language.
Unreal Engine developers sad noises
I chuckled when he said OCaml is "getting faster industry adoption".
Dude, OCaml is 1 year younger than JavaScript.
OCaml is not getting wide adoption in some "blowing up sense." It's pretty obvious to me good ol' Prime is listening to his some-times co-host a bit too much 😅
I feel like any technology compared to JavaScript gets overshadowed by it tho
@@jobahd3626 yeah but he is scoffing (as I am, in jest, too) at things like Haskell and F# et al, for not being mainstream, when those have more industry adoption than OCaml. The OCaml community is much, much smaller than Haskell - and compared to other languages both are niche.
He asked "what's the point" (for good reason) when it comes to Nim (or any language really) - the same can absolutely be said about OCaml, a FP language that is less flexible and due to being not-fully-FP actually is worse. Haskell, when asking people who do FP, comes across as quite a lot better.
So, I said this comment in jest, but there's a bit of truth in there too. He obviously listens a bit too much to his "co host", who is simply just a OCaml-evangelist.
@@simonfarre4907 I've always thought of F# as the upstream of C# as C# keeps adopting features from it. Thus, never going to gain the popularity it deserves.
yep, ocaml is not getting wide adoption. jane street is not "wide adoption"
I think ocaml has wider or perhaps thicker adoption than nim right now. What I mean by thicker is that it has a more entrenched community. And there's less a chance that people using ocaml rn will switch to something else. Not so much with the other languages mentioned I guess. That said I mostly agree with everything said here in this comment section.
the niche for nim is writing dsl specific programming language with powerfull macros
That ocaml code looks more confusing than the nim samples I've seen.
Absolutely
It isn't conceptually difficult, it's just that Ocaml is a old ass language and the syntax is ugly af. A lot of the overall syntax/semantics can be grossly simplified and that's why you see modern FP languages have much simpler looking syntax (e.g Lean).
I've played around with ocaml and nim before... I call it a tie on syntax/semantics complexity (obviously IMHO. everyone has its own perceptions)
Confusion is stupid leaving the mind.
Nim is for people who like Python and it's syntax (or are simply used to it), but want it faster and with some additional features, for certain programs.
Nim is everything Python tried to be
I haven't actually written anything in nim for like a year now (school taking my time and now I'm working as a dev), and woah totally forgot we were still waiting for Nim 2.0! I should take a look when I have the time to update QRgen to use this new version!
Nim is awesome
How about instead of having a language that "solves a niche-problem" having a language that fits most use cases. And can be adapted to fit pretty much every use case instead of having to learn or create a new language each time. You can write C and Javascript libraries in it, you can interop with C/C++, Python or JS. It compiles fast, runs fast and is about as productive as Python.
then it is not a language, it is a RPC framework
you're describing nim
@@pencilcheck❤ yes but it is also a language- good description
@@DiThiyes, that was the point of the comment
In order for OCaml it to see mass adoption, it will require 40-year old tech leads who passed it by 27 years ago when it was new to admit that they were wrong. That will never happen in the near future.
I read the release and was confused with tags. Now i understand it. Thanks for the sample use case!
nim is like "what if we took pascal and added compile time macros and common lisp condition system"
ocaml is great, but last time I've checked (mid-22) cross compiling with dune was really, really bad to the point
F# is fine but using it in big projects is a pain because the compiler is linear, slow and doesn't support proper incremental builds yet
Hmmm still skeptical. Is the exception handling a lot better than Rust? And does NIM not have a GC? (Dont like GC's) because mostly don't need them and if you nees them u can use an Arena.
incremental builds ~kinda work~
the main project will have to redo type checking even when only a dependency changed and it will take a while to rebuild (at last 3 seconds to do it here)
watch mode is also not properly implemented, using it will restart the app on any chance instead of reloading the code
I love the F# language, but using it for GUI is awful due to the build times
once you do a spa with nim and html you understand why we need nim
I just watched the Fireship's video on Nim and then I immediately see the Prime's one lol.
the guy literally goes against his own claims.. that everyone wants to be first to make yt content for easy traffic about some new tech or news/release..
Nim has great potential but think its doomed to always be very niche. Andreas Rumf is an absolute genius, but he's also a bit of a dictator with Nim, similar in a way to Ryan Carniato with SolidJS. In order for these projects to really fulfil their potential, they have to be allowed to outgrow their creators, and its not easy to hand over your baby for the greater good.
Definitely needs the Foundation organization model with suitable sponsors and marketing to become widespread.
yea been on a language binge for a few months now & im considering nim next when i have some time.
Nim is easy to code and very fast
And consume very very few memory
Nim is good for writing malware but it’s still simple enough to quickly prototype and get the idea down.
Also python needs an interpreter as you know versus nim creating an executable.
But yeah, mostly known for malware but I think it’s a cooler python. My favorite thing is you can pipe method similar to bash. Lots of coolness here
What's the source on the "mostly known for malware" statement? I'm curious because I haven't heard this and I've been flirting with Nim for a few years now.
Never heard it being used for malware on the nim discord server but maybe in the shadyer parts if the net it is lol i have no idea
@@UxerUospra lot of new malware and ransom ware out in the wild is written in nim. A lot of AV’s actually fire on any nim code being compiled because its so heavily signatured. Check out the Offensive Nim repo
The same thing happened to go for a while. If your language does anything novel it becomes harder to reverse with traditional tools so malware devs will use it just for that little layer of obfuscation for a bit.
@@UxerUospr Because up until recently the compiler and many binaries made with nim were flagged by some antivirus software, since they had unique signatures of some malware found in the wild that was not frequently found in legit software. Also because it's very easy to write a small static binary that has no dependencies.
Nim is a beautiful language.
nimmy nimmy nim nim, nim nim nimmidy nim nim
“It doesn’t feel like a normal language!”. This comes from the bunch who love Rust! Go figure!
lol
Two main problems that Nim solves at the same time, Large Memory Usage and Easy to program. Nim is a C with Python syntax. The software world does not have something like that.
@15:00 The problem with OCAML, at least historically, was its lack of good concurrency. As I recall one of the main devs was very anti-concurrency in the platform and argued it couldn't be done well. Whereas that's exactly what Erlang is and proves the contrary.
I really wish there was an Erlang like platform with strong typing. Erlang syntax/matching/actors/binary type/etc. + OCAML typing. I know a lot of people dislike Erlang's syntax but I enjoy it. The language itself is very simple and can be completely understood without too much effort. Reminds me of C or base Lua in that sense. It is hard to do truly crazy shit with the language that makes someone else unable to follow the code.
OCaml 5.0 added true parallelism if I am not mistaken. Very recently released
@@ModinthalisJust read over the changelog. Eh. Yeah. They added threading in the form of "domains". It's pretty simplistic from what I can tell. And really not surprising given that one of the main OCaml devs years ago was very openly against a complex system like Erlang.
OCaml has some really nice features but this "domain" thing feels like a hack.
What would make me want to switch from C++, personally, is a language that has similar power to build efficient and effective abstractions as C++, but has more regular syntax and concepts (C++, in its attempts to please everyone, creates lot of rules with lots of little special cases, which ultimately helps no one), more modern ecosystem and tooling, and less UB in silly places. I don't think it's a huge ask, but for some reason nobody seems to have tried it. You either get something like Zig, that got rid of much that was bad about C++ but also everything that was good, or Rust, which retains more of the good things but is opinionated in bizarre ways.
I don't think it's impossible for a language to be multi-paradigm but just remove some of the archaic stuff, like the C syntax with all its problems, the issues with parsing templates, or weird limitations that come from the language having compilers running on the weirdest hardware. C++'s biggest problem, the committee model, does present an incentive for jumping ship, it's just that there aren't any real alternatives yet.
Have you checked carbon?
@@jugurtha292 As far as I've seen, it's meant as a successor for C++ written with the Google C++ style guide in mind, that is, a C++ that neuters or removes many of the things that are good about C++ in favor of making it more accessible to large numbers of (potentially poorly vetted) programmers in a huge enterprise. It's not so much what I'm looking for. I'm interested in Herb Sutter's cpp2 project, but my optimism is much guarded because some complexity seems to be creeping in due to the need for compatibility with current C++, and I don't know how much of an improvement the final product will be when all's said and done. But a lot of the 'heart' seems to be in the right place at least.
Seems like Nim would be pretty much up your alley. It has almost all the C++ features that make it powerful but it is also simpler. The syntax is far away from C++, but the semantics are pretty close. Generics are C++ templates. The `when T is bool` you have template specialization. There is no distinction between method and free standing function. And most importantly, no header files. There wasn't something from the c++ that I missed. And if I would miss something, Nim compiles to c++ and you can somehow make that feature accessible with emit statements.
@@krux02 Semantic whitespace is a deal breaker.
Seems petty, but when I'm blocking out/prototyping I don't want to bother with indentation when making quick changes. I'm also very happy letting clang-format take care of 99% of my formatting needs. The experience writing python and manually managing indentation is very clunky by comparison, and I don't want to deal with that for my daily driver.
Also, isn't Nim garbage collected? That's the wrong default for me.
@@isodoubIet I don't like this Argument. There are many good reasons to avoid Nim (in its current state), but superficial details such as indentation based blocks is not one of them. It is at worst a bit annoying, but it would never cause major bugs or prevent you from doing something.
Is there a compiler-speed comparison benchmark for various compiled languages? The code samples must be 1K, 10K, 100K, and 1M lines.
Nim is transpiled to c which makes it much easyer to use on embeaded or gaming consoles
Nim elevator pitch for me: Close to C/C++ execution speed with a garbage collector..!
Be careful with the wording. GC means stop-the-world to many people. Automatic memory management is the generalized term. ARC/ORC (the default mm as of 2.0) are reference counting and fast enough for hard real-time.
@@dwhall256 Yea, I know, unfortunately, But people are just going to have to wake up to the new world and understand running highly optimized code on today's hardware with a GC is as fast as a C just a few years ago, so the convenience, speed of development, and safety far far FAR outweighs the tiny impact on performance. The performance impact that, in some cases isn't even measurable.
But thank you, I will try to use AMM in the future for the slow people in the crowd 😅
The allure to me as a beginner noob is that nim looks like a Family of languages. The way you might pick a Debian-based Linux and you have transferable skills for A LOT of other distros. The transpiling/cross compiling makes it appear to be a bargain, five languages for the price of learning one.
i'll tell you nims niche, it can interop with python and transpiles to c, so basically it can be used to extend python and make it efficient very easily without shooting yourself in the foot. and since it transpiles to pure c you can port it anywhere you want. just think out of the box
It's even better than that.
Because it compiles to C, it means that every **single** c library can be seamlessly used with nim, the process of building a wrapper is so simple that a lot of automated tools exist to take a header file and automatically write a nim wrapper for it.
Nim doesn't really try to appeal to a niche. It tries to be a general all purpose programming language. Which is hard and probably the wrong approach because the main question will be: why use a new, niche programming language when we could use something like c++, java, rust, c#, ect
I completely agree with POV on 12:00 - as a C++ dev it’s hard to switch on other language even trying
Embedded Nim gang!
nim 2.0 is out! finally
is it blazingly fast?
Yes + compiles to C
faster than rust
It's as fast as C with small executables and that's good enough! 🙂
Star in proc name is NOT pointer - it means that this proc is exported outside of module. For pointers, you need to use 'ref' ;)
That's the safe pointer, the reference. There's also the unsafe pointer type (ptr) that is not handled by the memory manager.
@@DiThito be fair, you shouldn't use raw pointers unless you really need them for performance or C interop.
@@dolorsitametblue Yep, I use them for both. Always isolated to one procedure or abstracted in some way to isolate unmanaged memory as much as possible.
Nim is nice but the tooling is just horrible and maintainers do not seem to care nor do they try to onboard people into contributing which makes me think nim will have a hard time finding its place
This is so true. Araq does't care about tooling at all. If anything he accepts PRs that fix something tooling related, because he gets pressured to do so. But he doesn't care and often makes things even more complicated for tooling.
@@krux02 yep. For instance at some point learning nim I wanted to improve nimsuggest and first the codebase is just horrible second no documentation third when I build it on MacOS without touching anything it just randomly segfaults and the worst part is that I asked for help both and discord and GitHub and nobody seemed to care. So even if the language has some good points coding in it makes me super unproductive because the tooling is lagging behind. Been with rust since then and I'm happy lol.
Sadly its creator acts like an old man who shouts at the clouds...
When people reach out to help with the documentation or ask if they can use it for production, the replies they get is borderline mind-blowing. they point blank get attacked!
Good luck getting anywhere with that attitude
Nim seems like a very good language but the way things are now, it is never gonna get widely adopted
What tooling do you lack in Nim?
Here's my setup:
Atlas for workspaces and package management.
Nimble tasks for building, testing.
Neovim with 'alaviss/nim.vim' for smart syntax highlighting and tab completion.
Inim repl for small experiments.
GDB - debugging,
Valgrind - profiling.
It's not perfect, but I don't see it as horrible either.
That has changed a lot in a year at least if you are using VSCode. It's great now and langserver, VSCode extension, and Nimble work well.
8:00 That let assignment is nothing new. It also works like this in rust.
8:10 Not by retunging stuff from expressions. Just try it in rust.
let x; // not mutable
if true {
x = 1;
} else {
x = 2;
}
println!("{x}");
x = 3; // error: x needs to be mutable
I would love to see a video when you try out Scala!
I've never liked treating paths at special. Just write good path manipulation functions, and users won't feel the need to split or join path strings nonportably.
If you know python then Nim is probably the easiest starting point. I like that it's syntactically super easy while being statically typed and dynamically compiled with C++like performance. It's just easier than similarly powerful and performant languages.
OK now write some DLang tho... 😉
I tried Nim because the code is more reminiscent of Python and Pascal than C++. I stayed for the Universal Function Call syntax ("func1(func2(var1))" is the same as "var1.func1.func2"), easy overloading, and generics.
Why the easy C/C++ interop? Because they have the libraries already developed.
Reads change log, claims to not understand the language it had never ever seen before. Still spouts baseless opinions. You can bet it happened on Twitch.
The Nim advertise you could write a Nim code and compile it into other languages, like javascript, C and others.
I've always waited for v2 to make nimm2 puns (the name of a famous German candy).
Nim is just pleasant and easy to learn
Nim looks strange and is kinda cool, but I think I'm not gonna learn it... not because It's bad, but because learning Go or maybe C++/Rust looks like a better idea
Unless you already know Rust and Go. A third is not that bad.
Learn Go. The value per line of tutorial to dig through you get is right now the highest in all of programming languages.
@@krux02 Im learning and its a really nice language. I can be productive in it even been new. Later I'm gonna try Rust, maybe after 5 reasonable projects in Go
I would say C++ particularly if you are interested in gaming and graphics. Nim also has interoperability with all the major gaming and graphics libraries.
I have to say that the argument of "what is Nim even for" is a piss-poor argument. It is less a valid question, and more unfair criticism. From the looks of it, it can be for a very wide spectrum of uses.
One of the issue that Jonathan blow and Casey moratori, have talked about a lot and I really agree with is that modern languages tend to do the same mistake. Instead of nailing the fundamentals of the languages, meaning (performance, readability, expressiveness, tooling, compiler control / good error messages, flexibility) languages people try to be the Jack of all trade, but end up being the master of none, I know this go against what a lot of people seem to think, but to me languages like C and Go, Zig and potentially JAI or Odin, should be the end goal, languages that are simples, that follows sort of sensible syntax conventions, have good toolings, languages that are readable and expressive, languages that don't rely on unmaintainable obfuscated syntax and abstraction to make it look like your doing some real work when all you do really is niching and fighting the languages quirk. Like in languages like C if you want a behaviour or something you just need to write more C, same with Go but modern languages are doing the weirdest things, to try to cater to all audiences, instead of focusing on the fundamentals. I don't belive nim will go anywhere.
Can someone explain Nim to me? I watched his stream for the first time yesterday (always just seen him in clips) and he spent roughly 80-90% of the stream talking about forsen and his viewers. Is that what all his streams are? Does he not do anything else but talk about another streamer all day?
Yea, I couldn't watch it either. He clearly wasn't interested in Nim, he just did it because it was a community request and wasted to have that part done. But he din't do Nim justice at all. I can sum up Nim for you. It's an algamation of Pascal, C++, Python-syntax and lisp macros with a buggy compiler, that has tons of surprise features that are documented nowhere but has a single test somewhere in the test suite, horrible code quality in the compiler, denial towards actual problems that need to be worked on and hostility towards anybody who exposes these bad conditions to the public. It has an interesting feature set, that allow really productive working. But also a lot of unstructured mess in the standard library.
@@krux02 Nimskull is promising; But anytime a community that size is fractured to this degree -- it's extremely worrying. So much of small-scale language-dev (if you want to get popular at least) is social-engineering and there's a LOT of social-problems that need to be solved a long time ago and kicking out very productive but quirky/dysfunctional core devs (Disruptek) over a few really-not-big-at-all incidents in the grand-scheme of things, and two-to-three years later you still don't have the incremental-compiler delivered, amongst other things.
Deep technical issues only get fixed (or are radically improved) when there's enough social-cohesion to hold stuff together. Again, think Nimskull is pretty promising on this front, and they're doing some important work (technically) but this needed to happen YEARS ago. People still see Nim as mostly "cooler python" and that value-proposition starts to look a looot weaker with things like Mojo and maybe even GIL-less Python on the horizon. So if time hasn't already ran out already... really feels like it's about to.
Which is tragic, still think it's a really unique and interesting language; With not much else out there like it. There's a lot of value there, but that doesn't mean people / groups are able to capitalize on it sadly. Still crossing my fingers.
@@krux02 so, would you say that apart from just giving the language a try for fun, the language would - at the moment - be worth a try to use for a small customer-project or maybe for tools to be used in-house? But not something to invest in for using long-term in production?
@@stevepositivdon't listen to that guy. Lots of ppl shit on nim mainly cause the creator isn't politically correct enough so there was some drama with forks a la ayo.js.
It's not popular but used for some production software. Nim's main sponsor currently is an eth node implementation (another reason some might hate nim) using it for the insane networked algorithms that eth now requires after moving from mining to staking - it's a very high stakes environment yet it works completely fine, nim is production ready. Some studio used it for gamedev as well. The official website, docs and forum are all almost completely implemented in nim as well (except for databases and nginx), including the frontend (javascript is one of the compiler targets, also custom SPA framework), there's even an email client in the standard library which is used for the forum's verification emails, so it's good enough for all those things as well.
@@stevepositiv If you need to write small (few hundred lines at most) command line utility or something then it can be used instead of python. If you will need to debug or maintain that code for a long time, forget it.
This remembers me mouthy python, The Knights who says NIM!! hahhaah
Nim caught my attention a time ago, so it deserves a try. After all, everything is better than Python or Ruby anyways, isn't it?
Except JS
@@heroe1486 Except TomJS
No!
Not really.... 😀
Nim's selling point is that it has Python-like syntax, but actually statically typed (with good type inference and metaprogramming too) and obviously faster than python (everyone is faster than python, right? =P). That's my take. It's not a niche though. It's more like a 'flavor' instead of a targeted niche.
But Odin is not niched for games or graphics. It's more like a general purpose language. Imagine if C and Golang had a baby... that baby just got a Zig's haircut but his genes are from C and Golang. The idea is so much more awesome but the stdlib just need to mature a little bit more (as well as ecosystem, like dependency management and stuff)
Odin is still pretty much targeted for graphics. Why do I say this? For example GB won't add operator overloading, instead he just add the types you would need operators for to the language and makes the operators built in. Namely vector types. But other domains, where you need your own BigInt, or Rational type, you are out of luck. He will never see the need for metaprogramming, because he own the compiler and can just add whatever he needs for his graphics and simulation focused application, built into the language. The language is great if your application is in the same domain as GBs application. If you differ, the language is solid (solid is still very good, but not great).
Odin still doesn’t have inline asm.
I'm enjoying Odin, actually. It's being an aspirin for my Nim headaches. I fundamentally disagree with the notion that _"data is just data, and data has no behaviors",_ which is the reasoning for the lack of support for OOP, but I very much like the tendency for simplicity and many other things. I also like that it uses "snake_case" as its preferred style convention.
I think that the (short) history of computer programming has shown that humans are bad at talking to computers. A great deal of the progress software development has made since Assembly was invented in 1947 has been about abstracting away the computer’s architecture from human input.
Compiler design has improved so much that expert manual instruction will only beat it 1/1000 times. For 99.9% of programmers we will never be able to beat a good compiler. The next step in this evolution is manual memory management: good automatic memory management is now safe but an expert programmer can beat it for performance. That’s not going to be the case forever.
OCAML is the most amazing type system! 😂😂😂😂
Do a vid about Factor 🙂
I love nim but i hate the syntax
That's quite a rare opinion
nim = metaprogramming
I don't get why people are saying Nim is easy for Python devs - Nim is so overloaded with features that it's probably easier to learn something like Java. (Not saying it's bad tho)
Nim just has PYthon syntax. But it is pretty far away from python semantics.
I use both C and Python at work, so Nim is the best language for me when programming something as a hobbyist.
Rewriting micro services from Python to Nim is easy. For scaling up in Kubernetes the cost starts adding up if you wrote everything I. Python and really embraced the micro service Pattern.
@adamkoxxl You guys hiring?
C+Python what a dream job.
The creator of the language itself is saying Nim is not for everyone when people ask for better documentation or examples :D
It is for people who have enough time to dive into the Nim source code to be able to write a simple program
Prag-ma Balls!
#ThePrimeTime why ocaml? Because you can decifer Standard ML code 😂
My main disappointment about Nim is that it has this multicase variables thing going on; I don't know what it's called. Basically, it's something like a variable called foo_bar is the same as fooBar - super weird.
But the main selling point for Nim, I think, is that it uses Python-like syntax. So, the target users are those who use Python and want more power.
I use Python for small CLI scripts, window manager stuff, etc., but I'm not yet convinced (interested) enough about Nim.
It's called style-insensitive (instead of case-insensitive). The first letter is case sensitive. It allows you to write all your code in your preferred style even when using libraries that use the other style.
At first I thought this might be a nice idea, but over time I started to hate it. It ended up being completely useless to me, because I find it more of a hassle to keep code consistent with my _snake case_ style, than to just go with whatever code completion gives me. And it's also annoying because it gets in the way of my own preferred naming conventions, and of the original styles of some library bindings. In the case of raylib bindings, for example, raylib uses PascalCase, but you shouldn't do that in nim because it will make your editor highlight the functions as if they were type names.
Personally, I used to love nim, but not anymore. Having to constantly keep fighting the language was driving me crazy. Odin has been a relieving breath of fresh air.
There are some good use cases for it, as DiThi already mentioned. It may seem somewhat counterintuitive at first, but when used with discretion it can actually increase your style consistency. That being said, it is a feature, you don't have to use it. If you want you can explicitly disable it with --styleCheck:usages --styleCheck:error.
@@TB-tv2zf I'm afraid not many people are aware of the switches available, get hysterical and complain a lot about it.
Probably malware? But rust is growing in that front to
Nim isn't
The only thing I know about Nim is a guy having a meltdown in a Discord server about how it was excusable for the then-unstable Nim compiler to leak memory from a hello world. I think it was version 0.6, not 0.0.1 or something.
I don't know if it changed by now, but back then the attitude towards compiler memory leaks were pretty much: "who cares, the compiler is a short live executable anyway that collects all garbage of process exit"
@@krux02 No, I mean the produced executable. The other guy also mentioned issues about how perfectly valid code wouldn't compile.
I've spent some time playing with Nim sometime ago. I was excited because Nim looked like everything that Python3 failed to accomplish. I was just willing that Nim could gain more adoption, more popularity and more libraries. Nim was actually fine. Now I see Nim 2.0 and... honesty... I think the designers killed off the language. Why I should use Nim when Python, which is simpler, is already here and when Rust, which is far more powerful, is already here? Introducing Nim 2.0 which is far more complex than Python and not as powerful than Rust seems like the developers are looking for an audience which simply does not exist.
Sadly the slow compile time is a dealbreaker
What? It's actually quite fast. It builds the whole tooling, consisting of the compiler, package manager (nimble), nimsuggest, test runner (testament), alternative package (atlas) manager in under 4 minutes in a 2020 laptop.
Very fast compile times actually.
Nim names being case and underscore insensitive is BS
Generally I would say yes. But it also prevents people from creating bullshit identifier names, such as `__name__` in the first place. So I guess it is not just negative.
It's not case insensitive, it's style insensitive.
@@krux02 dude, you can still create stupid names like `var_____x` or `varX_XxXx`. I've seen people throwing that argument around for such a long time that it boggles my mind how people don't see it holds no water. Case/underscore insensitivity prevents nothing.
Also, `__name__` isn't a stupid thing at all. It's very much a requirement in python and lua and some others to avoid name clashes with user defined keys, because internally python classes are dictionaries, and in lua they're tables, and users can easily create a property or method called `init` or `name`.
@@skarutsbut it still prevents some people from creating intentionally (newbies) or by mistake identifiers like: varX, var_x, var___x and var_X *in the same project*.
A good example of bad practices is X server where some function names only differentiate by case - you can't do this in Nim.
And if you import library that uses some weird style you can still use your preferred style to interact with it.
var______x = varX, varFoObAr=varFoobar
Nim doesn't stop fevelopers from OBFUSCATING their code, but it doesn't claim to do this.
@@dolorsitametblue that's like saying the broken vacuum cleaner is still sucking 0.00001% of the dust on the floor, so it's working great.
It's useless. It prevents nothing. It's like you read my comment without reading it. It's the easiest thing to circumvent.
var______x =/= varXx
varFoObAr =/= varFoobar2
That argument doesn't hold any water, and never did, and never will.
And in my experience, it's just as useless for style consistency, unless you're, for some odd reason, really so bothered about lib code not looking like yours, that you're willing to keep going through the trouble of making code style consistent over and over.
The way I see it, the cons vastly outweigh the pros. It gets in the way of personal conventions a whole lot, and that's one of the many reasons I ended up ditching Nim. Used it since 2017, and so far I haven't found an actual good reason for style-insensitivity to exist. (At first I thought it was a good idea.)
It's funny to watch you kinda crap on Nim towards the end then be like Ocaml makes so much sense after you've already written things with it. Who cares if a language is a general language and it's not designed for some specific niche use case. Some languages just click better mentally with people. For me I'm liking coding in Nim that's probably all that matters now to me. At one point I would watch stuff like this and literally change languages but yeah not now.
Finally...
Nim is a higher level C that compiles to C/C++. Zig wants to fix C, but Nim already did - you can even compile Nim emitted C code with the Zig compiler... Zig wont be done for a long, long time but Nim is mature with a host of libraries and an excellent package manager. Nim is extremely simple to use - unless you want it complex: then you can have it complex; to the point where you start sweating profusely, gasp for air and ask for mama. So Prime: grow some hair on that bony chest, become a real man and start learning you some Nim - would ya?
"Zig wants to fix C, but Nim already did "
Yeah but it has semantic whitespace so that's a no.
"Nim fixed C - by transpiling to it..."
Yeah, it doesn't fix or replace C in that case. It just relies on it. Which makes Zig a superior replacement for C by default, just because Zig actually replaces C and Nim doesn't.
@@arnontzori I would choose Zig over Nim. But am mostly using Rust + Python.
@@arnontzori Also a completely immature language - have a good wait then...
@@isodoubIet Why? Braces - sorry, brackets are completely unnecessary.
honestly, this is the first time I got bored, there is too much prepossessing before understanding what you are actually doing, 4 months tops not visiting the language everything goes poof!!!
Nim - Just a toy language
About time burh
Yea, he didn't do it justice though.
Nim is for people who don't want bloated binaries like Rust and want system performance with safety even faster than Rust and as a bonus they aren't politically motivated like Rust
All great selling points
so this the language that many people said it's as easy/easier than python
Obviously if your first contact with the language is via a release note which tackles improvements about the specificities of a language and thus meant to be checked by seasoned nim programmers you won't find it really readable
I started learning Nim a few days ago. It's easier to start learning than Python.
@@bdjnk Is the tooling easier than python's tooling? (Be honest)
@@HermanWillems Haha, no, tooling is not great. But that isn't a top priority for me right now.
@@HermanWillems Tooling is now okay with Nimble, Atlas, and VS code extension and nimlangserver.
nimmy nimmy nimmy nips