I'm hearing this language just beat C, C++, Rust, Go and pretty much everything else. Is that true? The more I read about it the more it seems like the true winner of the programming languages of the 2000s.
>>106465531beat at what
>>106465531>I'm hearing this language just beat C, C++, Rust, Go and pretty much everything else. Is that true?never saw a benchmark where it was the case. I don't really pay attention to lang shills because they never have answers for what lacks in their language. the answer to what you should use just depends on the project and what sucks the least for the solution. other than that everything sucks at something. this is something any software engineer should come to terms with after 5+ YoE
>>106465531I constantly see people lying about that too or more likely they're comparing it to C++ written like Java
>>106465531>Is that true?No. It's irrelevant and always will be.
>>106465576in generally being best with all the plus vs. minus in the universe>>106465598nim seems pretty fast in comparisonI'm gonna start using this now. I've been thinking about Rust for some time but never started with it. I then thought about Odin but it seems too new. Zig has stupid name and reminds me of russians. Go seems to have unnecessary shit overall. C# is Microsoft shit. Java has the worst communities. Kotlin is good but you have to deal with Java libraries which is stupid. It's obvious that I will not be learning any more C or C++ since I'm not trying to cram the best software into the smallest device thinkable. I will go with Nim and make the best software in the world.
>>106465921Maybe in a vacuum, but the libraries, tools, code samples, autocompletion support etc. are just as important if not more important than the language itself.
>>106465531supposedly 'ok', sure but beats, no
>>106465531>I'm hearing this language just beat C, C++, Rust, Go and pretty much everything else. Is that true?Buy an ad or stop being dumb.
>>106465531>the true winner of the programming languages of the 2000s.Too many words to write "Julia"
>>106465921>nim seems pretty fast in comparisonwhat comparison? you know what, I don't care. way to prove my point retard
>>106466138in comparison to C and rust in benchmarks>>106466088I'm trying to avoid GC
>>106465921I use Odin for all my personal projects. I used it to learn how to do Raytracing following that Raytracer in a weekend website and the language generally stayed the fuck out of my way, which is nice given all the bullshit you have to deal with in C++ and Rust.
I'm not hearing anything.
>>106467511Get hearing aids.
>>106465531but I need libraries
>>106467982Just roll your own.
>>106466164>in comparison to C and rust in benchmarksnot once was any benchmark posted and I'll bet it's a cherry picked one. nim probably has trouble in other cases and you never talk about what the negatives of using nim might be. you still aren't looking at the larger picture which just makes you another annoying nocoder
it sometimes does, as nim has a few top-tier libraries like arraymancerhttps://github.com/mratsim/ArraymancerBut in general, naive nim 2.0 code will lose to naive c/c++ most of the time, but usually by a negligible amount. So you'll have to put in some work if you want to compete or beat.There are some release options since nim just compiles to c.Like using clang LTOhttps://forum.nim-lang.org/t/6295If you are a hardcore manual memory believer, you should be aware that it's highly coupled to its reference counting based memory management solution (which can be quite good sometimes)https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.htmlAnd while you can turn it off --mm:none, in my experience, it's a second-class experience, which makes sense considering how hostile the creator is for manual memory in nim.You should also be aware, that Nim 2 is in a sort of purgatory right now because they're in the middle of shipping Nim 3, which is a completely new compiler which makes some radical changes.https://github.com/nim-lang/nimonySo while Nim 2 is a great language (with a fair bit of oddities), you're coming in at an awkward time, and i believe you should only use it if you're okay with automatic memory management.If you want an alt lang with a better manual memory experience, or believe in the mixed-management strategy, i think D is a better choice, or you can try the other ones like Zig or Odin (which i have no experience with)
--mm:none
>>106465531our days of searching for a c replacement certainly are coming to a middle
>>106469455Did he already say that he's gonna make breaking changes for nim3?
>>106469710yeah, there's gonna be a fair bit.https://nim-lang.org/araq/nimony.htmlhttps://nim-lang.github.io/nimony-website/index.htmlI haven't looked too hard into nimony/3 yet since Araq (the creator) isn't expecting to publicly ship it for a few more months (which means probably next year Q1). And i have enough experience with nim (a bit before 1.0) to realize it will probably be radically different than the current docs.I'm expecting any large project port will probably be module by module.Anyway, you can read through his progress report threadshttps://forum.nim-lang.org/t/12693https://forum.nim-lang.org/t/12978https://forum.nim-lang.org/t/13357
>>106465531I hate whitespace blocks. I want braces or begin end style blocks. Python brain damaged people. I can't fucking %, # between start and end of a block nor do any block based operation. It's pure misery working with python like languages.
>>106466164>I'm trying to avoid GCnothing you're doing requires avoiding GC you're just posturing here
>>106465531Nim's best-in-class features:- Metaprogramming- Memory model- C interopBad stuff:- Module design is meh (however, it's partly due to UFCS)- LSP sucks monkey balls- Too many retards that spam Nim spaces with their niggerbabbel (you'll know that hatfag if you've been in the forums)And Nim 3 will mostly fix modules, further improve macros with type checking and hopefully standardise threading.>>106469455>it's highly coupled to its reference counting based memory management solution>If you want an alt lang with a better manual memory experience, or believe in the mixed-management strategy, i think D is a better choiceThis is completely false.Nim's manual memory management design is great and can even be done as an extension of ARC. There are no issues going GC, mixed GC or no GC, but there is in general never a reason to have no GC because it adds no overhead if you aren't using it.https://nim-lang.org/docs/destructors.html
>>106471650>Nim's manual memory management design is great and can even be done as an extension of ARC.manual memory implies --mm:noneGranularity in destruction/moves is one thing, but extension implies you're now managing and coupling two different solutions together, which is not a good idea, and Araq would agree with this as well. As he's pretty vocal about hating mixed-memory management. (Not that I agree with him)But this obviously reflects in Nim's design, as its clearly designed around Orc/Arc. Also, remember when he almost removed --mm:none before people spoke up?Nim has 1 intended memory solution, and it's pretty evident. Araq's mistake was actually keeping --mm:none if he also believes mixed is a bad idea.
>>106465531>indentation based scopingit wins nothing
>>106465921>Odin but it seems too newthe author has basically finalized the syntax for a few years already, now hes just working on improving tooling. its much further along than Zig
>>106471802refactoring or iterating on a curly block is misery compared to a white space one, i think python has unfairly poisoned the entire idea by being a shit lang.
>>106471791No, manual memory management implies ptr with alloc and dealloc and automatic memory management implies ref with new.Araq's whole thing is having to deal with the same clueless idiots like:>>106466164>I'm trying to avoid GCthat think "GC bad" without even knowing what the word "semantics" means. The language is designed around having ARC, but saying that it is in conflict with manual management is completely false. The whole point is that ARC is at a level which allows it to cleanly wrap manual management while not requiring the huge overhead of a normal GC.Insisting on --mm:none is what the brainless "GC bad" idiots do that have no clue why it's bad and how ARC is not equivalent. ARC, properly termed, is not really even a GC unless you consider mangement like RAII or Rust's to also be garbage collection. The "real" GC is ORC which just provides a runtime cycle collector over ARC to generalise the memory mangement.
>>106465531don't pick up nim and expect python or some c clone its completely different. While it does have a good standard lib you will quickly figure out that it doesn't quite map well to whatever you have learned before. Also I have a sense that there is a mixed style in the language as a whole not uniform idea on how to approach things so often you are left guessing how to do a certain thing. Take the inotify api for example read it and try to implement non blocking file watching you figure out thats its dogshit to translate. Can't blame it on nim that the C api is shit but still you will see the issue.
>Language does not have enough libraries>Go to github and find the desired library of other language and tell chatgpt to copy the library to your selected language function by function>Glue functions together with chatgpt>Your language now has same library as other more popular languageWhat do I win?
Oh, I didn't see you there from my mountain of rubygems. Maby need some rails someday for us to meet. Honestly, I'm glad that my favorite programming language and its predecessors inspired so much further language development.
>>106472248>using ruby when elixir exists
>beat CDoesn't this shit get transpiled into C?
>>106472718yes but it has a runtime
>>106465531I can never actually get the LSP to work when working with this
>>106472265Have fun debugging elixir while wrangling those Erlang VMs your elixir project is deployed to. Programming Ruby is enjoyable, and I can attest to that. If I need speed, I re-implement hot spots in C (happened about 5 times in 21 years of Ruby programming). Much less stressful.
>>106466164>I'm trying to avoid GCWhy?Do you understnand the cost of "avoiding GC"?Do you have an idea of how modern GC work and where do they impact performance and where they DON'T impact performance?
>>106471877>that think "GC bad" without even knowing what the word "semantics" means. The language is designed around having ARC, but saying that it is in conflict with manual management is completely false. The whole point is that ARC is at a level which allows it to cleanly wrap manual management while not requiring the huge overhead of a normal GC.>Insisting on --mm:none is what the brainless "GC bad" idiots do that have no clue why it's bad and how ARC is not equivalent. ARC, properly termed, is not really even a GC unless you consider mangement like RAII or Rust's to also be garbage collection. The "real" GC is ORC which just provides a runtime cycle collector over ARC to generalise the memory mangement.You are correct. ARC is not really GC.But however, ARC has its problems too with certain data structures so it's not a full substitute to a GC in certain cases.
>>106472248>Honestly, I'm glad that my favorite programming language and its predecessors inspired so much further language development.Young padawan:I believe you have never used Smalltalk, or Squeak, thus haven't realized Ruby is a maimed, emasculated derivative of them, lacking the key feature that makes Smalltalk (and Squeak, and Lisp) great: Interactive devleopment.
>>106474432I have used Sqeak, and I know Smalltalk's interactive environment from the Alto PC and other 1980s-era machines. I am old. Don't miss all that in Ruby. I'll give you one more: Ruby has quite some detailes from Lisp, but it doesn't has Lisp's powerfull macro stuff. Another thing I know from programming in Lisp and have never missed in Ruby. I implement and use DSLs withing Ruby.
>>106474408>But however, ARC has its problems too with certain data structures so it's not a full substitute to a GC in certain cases.Of course, it's not a problem that can be realistically solved at compile-time in the general case. That's the point of ORC: it is ARC + a cycle collector to plug ARC's hole of cyclic data structures.That said, most programs are not going to require cyclic data structures and, if you don't want to use ORC, there are multiple ways you can set up your own pool allocator like you would in C.Nim's ARC is the best (at least mainstream) implementation of the same idea that is in C++ and Rust. It isn't a tacked-on solution like in C++ and doesn't require you to cage yourself like Rust.
>>106471075stop projecting
>>106472718you can transpile any language into C plus maybe some minimal amount of assembly. C is not fast because of the compiler but because of the idiomatic way to write code allows some optimizations while also shunning some expensive abstractions. If you write dynamically typed code in C, it will always be slower than if you demand the types to be known in advance.
