Thread 106465531

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.

>>106465531 (OP)
beat at what

>>106465531 (OP)
>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

>>106465531 (OP)
I constantly see people lying about that too or more likely they're comparing it to C++ written like Java

>>106465531 (OP)
>Is that true?
No. It's irrelevant and always will be.

>>106465576
in generally being best with all the plus vs. minus in the universe

>>106465598
nim seems pretty fast in comparison

I'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.

>>106465921
Maybe in a vacuum, but the libraries, tools, code samples, autocompletion support etc. are just as important if not more important than the language itself.

>>106465531 (OP)
supposedly 'ok', sure but beats, no

>>106465531 (OP)
>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 (OP)
>the true winner of the programming languages of the 2000s.

Too many words to write "Julia"

>>106465921
>nim seems pretty fast in comparison
what comparison? you know what, I don't care. way to prove my point retard

>>106466138
in comparison to C and rust in benchmarks

>>106466088
I'm trying to avoid GC

>>106465921
I 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.

>>106467511
Get hearing aids.

>>106465531 (OP)
but I need libraries

>>106467982
Just roll your own.

>>106466164
>in comparison to C and rust in benchmarks
not 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 arraymancer
https://github.com/mratsim/Arraymancer
But 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 LTO
https://forum.nim-lang.org/t/6295
If 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.html
And 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/nimony
So 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)

>>106465531 (OP)
our days of searching for a c replacement certainly are coming to a middle

>>106469455
Did he already say that he's gonna make breaking changes for nim3?

>>106469710
yeah, there's gonna be a fair bit.
https://nim-lang.org/araq/nimony.html
https://nim-lang.github.io/nimony-website/index.html
I 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 threads
https://forum.nim-lang.org/t/12693
https://forum.nim-lang.org/t/12978
https://forum.nim-lang.org/t/13357

>>106465531 (OP)
I 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 GC
nothing you're doing requires avoiding GC you're just posturing here

>>106465531 (OP)
Nim's best-in-class features:
- Metaprogramming
- Memory model
- C interop
Bad 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 choice
This 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:none
Granularity 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 (OP)
>indentation based scoping
it wins nothing

>>106465921
>Odin but it seems too new
the author has basically finalized the syntax for a few years already, now hes just working on improving tooling. its much further along than Zig

>>106471802
refactoring 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.

>>106471791
No, 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 GC
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.

>>106465531 (OP)
don'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 language

What 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 C
Doesn't this shit get transpiled into C?

>>106472718
yes but it has a runtime

>>106465531 (OP)
I can never actually get the LSP to work when working with this

>>106472265

Have 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 GC

Why?

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.

>>106474432

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

>>106471075
stop projecting

>>106472718
you 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.

>>106465531 (OP)
>undefined behavior
bye

>>106469455
>And 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.
this is exactly why I switched from that hot garbage, Nim supposedly had custom allocators and arena allocators, except everything about it was broken. You literally can't use any standard library with it, hell, you can't use basic syntax of the language itself like sequences and other things.
I was having a gigantic issue with it because
1 - the http implementation had some exponential growth problem and refuse to return memory back to OS so I had to restart my server the moment i try to serve something big.
2 - nimRTL was also a fucking meme so you can never have both the host executable and the dynamic library made in Nim, so goodbye hotreloading.

It doesn't help that any library ever is a gigantic unreadable mess due to how much they rely on macro magic, I was having magical compiler errors that lead nowhere because it's macros, it literally turned to a lisp where every single library is practically its own language.
I thought it was cool at first doing a DSL for html but it I never hated a feature so fast.

>>106476922
>waaaaah, why no dynamic memory data structure when I turn off the dynamic memory management?
>waaah, turning off the memory management... disables syntax?
>waaaah, I can't understand how shared libraries work
>waaaah, why am I too incompetent to properly validate and structure macros
Holy shit are you retarded. Stick to Python/JS.
C semantics obviously require a 3-digit IQ.