101–110 of 121 posts
This looks great. I’m loving nim for game dev right now. Godot 3.x bindings are working great. There is also a really nice looking binding for unreal engine 5 that is pretty far along
Any die-hard lovers of Nim? Or heavy users? Why do you use it over other languages? What was your ah-ha moment?
In no particular order, things I like about Nim:
- It has most of the benefits of a scripting language, without most of the tradeoffs. Hello World is a one-liner, there isn't much syntactic noise, and it's very easy to write short, simple, useful programs that look like pseudocode, live in a single file without any dependencies, and can be kicked off with a shebang line. However, unlike scripting languages, it scales very well to large projects.
- Progressive disclosure. You can use Nim effectively while knowing very few of its features, but there's a lot of functionality available when you're ready.
- The "if it compiles, it works" factor is quite high. Not as high as Rust or Haskell, but higher than Java or Go, in my experience.
- The "it compiles on the first try" factor is also quite high. Higher than any language I've tried. "I wonder if this will work..." code usually does, the advanced features of the language mostly stay out of the way until you need them, and I rarely find myself working just to make the compiler happy. Just as an example, unless you add specific constraints, generics are "duck typed". If I pass a type to a generic proc the compiler will verify that it has the properties and functions the proc needs, but I don't have to define a specific interface up front.
- Similar to the above, the productivity vs safety balance seems right, at least for me. Code is fairly safe by default, but it's easy to work around the compiler if you need to do something it doesn't want you to do. It's also pretty easy to enforce additional safety when you need it, like ensuring a function can't throw exceptions or have side-effects.
- It's very good at building abstractions and eliminating boilerplate. Nim templates and generics are easy to use and quite powerful, and macros are there if you need something more advanced. Many features that need explicit compiler support in other languages, like async/await and string interpolation, are implemented in the Nim sdlib with macros, not the compiler.
- Nim produces standalone binaries that are both small and fast.
- The compiler is faster than most.
- The compiler can be imported as a library, making it pretty easy to write tools that understand Nim code.
- Nim programs are usually compiled, but there's also an interpreter. The compiler uses this for macro evaluation and for running build scripts, and it's easy to embed if you want your program to be scriptable.
- Nim can run on pretty much anything.
- Nim can be used to build almost anything. You can use it for systems programming, webdev (frontend and backend), games, ML, scripting, scientific computing, and basically anything else. There are definitely some domains where library support is lacking currently, but the language itself is suitable for any type of program.
- It's very flexible. Most Nim code is imperative, but it's easy to write functional, declarative, or OO style code if that's your thing.
If you prefer languages like Go that favor an abstraction-free style, where everyone's code looks more or less the same, you probably won't like Nim. However, if you want something more expressive like Ruby or Lisp, but don't want to sacrifice performance or safety, Nim is definitely worth a look.
Well, crap. I just bought his book about version 1 lol.
Please share to me if you don't mind.
Honestly though, I'm a bit let down in that it doesn't seem to cover what I find the most interesting aspect of Nim : its ability to compile to multiple intermediate programming languages like C, C++ or Javascript and use their libraries. I was hoping to find out how to write VSCode extensions entirely in TypeScript (I know it's possible because the Nim vscode extension itself is now 100% Nim, but there seems to be no tutorial for how to do it online)
I had started reading "Nim in Action" and I might finish that first since it does cover FFI, it it is rather old (it was released before version 1.0)
You can find Nim in Action on the Mannings website : https://www.manning.com/books/nim-in-action
Default values and named parameters, thank you! Golang has neglected both of these. Both seemingly rare yet highly productive features to be found in a compiled language. Love the quick compile times and go-like single binary compilation. Case-insensitivity seems very cool for interoperability. Total underappreciated gem. My only hangup is the syntax feels wordy, but it's leagues better compared to Rust or Go in that…
Macros shouldn’t have any performance implications. The whole point is that they happen at compile time.
Earlier quoted context omitted.
> Is syntax really that big of an obstacle to learning a first programming language? Of course. Compare, at the extremes, languages like APL or Brainfuck to something like Python or Scratch. Syntax is a huge factor in people wanting to learn to code or not.
Those languages have actually very different semantics too. I would say lisp is a better example of the importance of syntax. People obsess (wrongly) about superficial details in my opinion.
Earlier quoted context omitted.
> Is syntax really that big of an obstacle to learning a first programming language? Of course. Compare, at the extremes, languages like APL or Brainfuck to something like Python or Scratch. Syntax is a huge factor in people wanting to learn to code or not.
Those languages have actually very different semantics too. I would say lisp is a better example of the importance of syntax. People obsess (wrongly) about superficial details in my opinion.
Another example, Gleam (an Erlang BEAM based language like Elixir) [0]:
> Shot in the wind, but is there a plan for different syntax? For those who've become comfortable in different fp camps, I can't really see myself picking up curly brackets and C-style code again. I really like the idea(s) of this project, but it's the thought of staring at that kind of code that's just a bit too much. I'd rather do something like [Nim,Scala,Clojure,F#]->JS if I needed to have that.
> > Unlikely I'm afraid. We used to have an ML style syntax but once we switched to a more mainstream syntax we had a big surge in popularity and interest.
> > I am very fond of the ML syntax, but I think it is the semantics and type system that really matter, so I am very happy to sacrifice syntax in order to make Gleam more widely accessible.
Any die-hard lovers of Nim? Or heavy users? Why do you use it over other languages? What was your ah-ha moment?
The simple answer is this: anything I want to do, I can do in Nim easier than other languages, while also having direct access to C/C++/JS ecosystems as well.
Productivity:
1. I write pseudocode, it compiles fast and runs at C speeds. Programming is fun again!
2. No `::!>>^3. Procedural: only data types and code. No need for OOP/Trait abstractions to be forced into everything (it's there if you must).
4. UFCS and overloading by parameter types make everything naturally extendable: `len("string")` can also be written `"string".len` or `len "string"` - you don't have to remember which way round it goes, and 99% of the organisational benefit of OOP emerges from this lexing rule. A compile time error if you use the same name and parameter types, so no ambiguity.
5. Sensible defaults everywhere: type inference, stack allocated and pre-zero'd variables by default, extend with GC/manual management by type (`type HeapInt = ref int`), GC is deterministic with scope based destructors and move semantics as an optimisation rather than a straight jacket, detailed opt-in control down to assembly as you wish.
6. Arguably the best compile time support of any language.
7. AST procedural metaprogramming is a core language feature. It's hard to express how powerful and well integrated this is. You can just chuck code around and recombine it effortlessly. Whether it's simple DRY replacements, automating serialisation from types, custom DSLs at your convenience, or even generating entire frameworks at compile time from data, you effectively have another dimension to programming. I can't go back to flatland, now.
8. Flexible static typing that's as strict (`type specialId = distinct int`) or generic as you want, with concepts matching any statement against a type. You can also calculate or compose types from static values which is really nice.
9. Low overhead and high control makes it great for embedded: https://github.com/EmbeddedNim
10. Fantastic FFI that can even use C++ templates, along with loads of converters/wrappers like c2nim, futhark, pas2nim that add even more sugar to FFI interop.
Portability and glue:
- Single portable executable output.
- Compiles to C89/C99, which covers basically every piece of hardware.
- Compiles to C++ so you have C++ ABI compatibility.
- Compiles to JavaScript.
- Compiles to ObjC.
- Compiles to LLVM.
- Excellent Python interop (see: Nimpy).
- Libraries for interfacing with C# and .Net.
I haven't heard of Nim until now. I've been a Go programmer for years now, and I see a lot of potential. I wonder why Nim hasn't taken off. What's the catch?
they are missing a cute mascot like gophers for go, crabs for rust, dinosaurs for zig
I was hoping case sensitivity would be implemented but it seems like it was too controversial. I'm thinking at this point there might be too much resistance.
Similarly, case insensitivity, of course, means `foo == fOO == fOo == foO`. Reducing these to one identifier means less ambiguity to the programmer and encourages either using sensible names that can't easily be confused, and/or unambiguous mechanisms like the type system designed for this purpose.
Say you have a constant for 'light enabled' Instead of naming it `lEn`, it's better to use `type LightState = enum disabled, enabled` and write `light.set enabled` for so many reasons. Same goes for pretty much everything. It's worth noting as well that the language is very good at resolving overloads by type, so if you have your own object and create a `len` for it, it's not going to get confused with the string `len` or even a `lEn` constant. Even if you have a `lEn` and `len` that are used in the same context with the same types (why though), you can qualify it anyway with `module1.lEn` or `module2.len`.
The language has so many easy tools to make things more explicit and easier to read at the same time. Ultimately, case sensitivity only really ends up encouraging bad naming practice without adding anything back.
Earlier quoted context omitted.
It's apparent from the RFC discussion that there is no consensus on the topic. With little (proven) tangible benefit of making the change, and a large potential for backlash within the small existing community, I'm not certain it's worth the risk for Nim to make this move. https://github.com/nim-lang/RFCs/issues/456
Anyone who wants to use grep will just keep ignoring nim. Case insensitivity is pretty silly, and underscore insensitivy is just really silly. The way that modern languages force a single style is great, and it's a big strike against nim, which is an otherwise nice language.