Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nim 1.6

nim-lang.org

Post reply on HN
Print view View original

121–130 of 179 posts

Re: Nim 1.6

#121

Post by mst »

akovaski wrote: post #106
mst wrote: post #87

Earlier quoted context omitted.

Within a specific project, you pick an approach and stick to it, just like you should do for any given convention within a project. The idea is to make it easier for projects using different conventions to be built on top of each other without making things harder to read - and in practice it actually works really well at that. On the upside, people freaking out over the style insensitivity makes for a nice change fr…

Ha, I wouldn't have thought to criticize the spacing, but I did see one person complain as I explored old Nim discussions. Nim being strict on tabs is something I see as a good feature for the same reason the style flexibility made me instinctively flinch back. I've experienced mixed tabs and spaces in Python code and I do not like it; the flexibility leads to inconsistency.

Tabs vs. spaces hides though.

Inconsistent naming is visible in diffs in any language, style flexibility or not :)

Re: Nim 1.6

#122

Post by plainOldText »

I wrote my first Nim app recently (an agent for reporting server data) and I must say, I like the language. It was a quick and painless learning experience. As of now my binary is about 400KB and uses about 1.3MB in memory consumption.

Indeed – as others have reported – Nim feels very much like Python, while the superfast compilation time means I can test code changes quickly during the development cycle.

For reference, I mostly write web apps in Elixir, but I needed another language in my toolbox that is statically compiled and lightweight.

I looked at Rust, Nim and Crystal. I ended up choosing Nim, because Rust is too complex for my taste, and Crystal’s syntax resembles Elixir (they both drew inspiration from Ruby) and it would be confusing when switching between the two languages.

Ultimately, they’re all cool, modern languages, so pick whatever fits your brain and helps you reach your objectives easier, while engaging in this social (or solitary) activity called programming.

Re: Nim 1.6

#123

Post by TheCoelacanth »

boardwaalk wrote: post #70
mumblemumble wrote: post #65

Earlier quoted context omitted.

I have decided that meaningful whitespace is an anachronism. 20 years ago, I liked it a lot . Today, after the invention and normalization of opinionated autoformatters, it means that the autoformatter can't figure out for me how my code should be indented. Which means that, assuming I am using an autoformatter, it creates one more thing that I have to do manually, because the editor can't accurately do it for me. An…

Some counterpoints: Your auto formatter can’t figure out where you missed braces either. Missing brackets in languages where they are optional for single statements (C) has been a source of serious bugs. Also, in Vim, indenting/dedenting a block is just highlighting the lines and using > or <.

> Your auto formatter can’t figure out where you missed braces either.

Correct, but I will notice the braces are wrong when the auto-formatter indents things differently than I expect.

Re: Nim 1.6

#124

Post by dbrueck »

mumblemumble wrote: post #65
wiremine wrote: post #55

I learned Nim last year by rewriting some of the core Arduino functionality in C, and then wrapping them in Nim. (I also wanted to better learn C and better understand how Arduino's internals work, thus the convoluted approach) A few observations: * The community was very helpful and responsive. I identified a bug in compiling Nim to bare metal C, and it was fixed in 24 hours. * The C/Nim bindings were a breeze to us…

I have decided that meaningful whitespace is an anachronism. 20 years ago, I liked it a lot . Today, after the invention and normalization of opinionated autoformatters, it means that the autoformatter can't figure out for me how my code should be indented. Which means that, assuming I am using an autoformatter, it creates one more thing that I have to do manually, because the editor can't accurately do it for me. An…

Definitely some subjectivity to this question, but I'm the opposite: to me the curly braces are the anachronism, a relic of a time when the programmer had to do lots of extra stuff to help the language parser/compiler.

For awhile it was awkward because it was up to the programmer to keep the redundant block delimiters in sync - the braces (for the computer) and the whitespace (for the human). The fact that modern editors and IDEs for those languages now do the housekeeping on behalf of the human is great, but it seems odd that it's needed at all, and it always feels especially cumbersome when returning to those languages that still require it if I've been away for awhile.

Re: Nim 1.6

#125

Post by b3morales »

hajile wrote: post #116
mumblemumble wrote: post #65

Earlier quoted context omitted.

I have decided that meaningful whitespace is an anachronism. 20 years ago, I liked it a lot . Today, after the invention and normalization of opinionated autoformatters, it means that the autoformatter can't figure out for me how my code should be indented. Which means that, assuming I am using an autoformatter, it creates one more thing that I have to do manually, because the editor can't accurately do it for me. An…

If I don't add a brace, I'll get an immediate error that something doesn't add up. If I mess up indentation, the program will carry on as if nothing had happened.

This is not really true in practice. It is the same thing as accidentally moving a line across a brace in a brace-delimited language.

The incorrectly-indented line will generally blow up at runtime or fail to compile, because it's in the wrong scope.

Re: Nim 1.6

#126

Post by elcritch »

wiremine wrote: post #91
PMunch wrote: post #62

Earlier quoted context omitted.

Oh it definitely can run on those devices! I wrote my own keyboard firmware from scratch in Nim, and the firmware sizes are vanishingly small compared to even simple "hello world" level stuff in Arduino. I did a talk on it for NimConf2021: https://www.youtube.com/watch?v=dcHEhO4J29U

This is great! I've wondered if Nim could be the foundation for a sort of "next-generation" Arduino. It's easy to learn, compiles to small binaries, and can wrap a ton of existing C code. My experiments taught me wrapping Arduino from scratch, while possible, might not be ideal. There's some cruft in that code base, and the abstractions could use some updating.

Yes, yes Nim could be. Actually I’ve been working on that idea for a while now. I’ve been working on getting an Embedded Nim project going on GitHub. Come stop by! Also some discussions on Nim forum: https://forum.nim-lang.org/t/7731#49050

PS I’m wrapping Zephyr as a basis, but working on better Nim abstractions on top.

Re: Nim 1.6

#127

Post by mumblemumble »

hota_mazi wrote: post #120
mumblemumble wrote: post #104

Earlier quoted context omitted.

But compare the ergonomics of: 1. yi{ To: 1. Find line number of start of scope. 2. Decide on easiest way to get there, and either: - kk - 5k - 37G 3. Find the end of the scope. 4. Decide how to grab it. Then: - y9G$ - y3j - V, jjj, y I hope maybe I've made my case that it's more awkward, right? That is not to say that I don't know how to do it. It's just that, in the one case, I can do the job in one thoughtless act…

You're both just making the case that you shouldn't use vim to write code. More modern editors (e.g. VS Code) and modern IDE's (e.g. IDEA, CLion, Visual Studio) make either indenting absolutely trivial.

I think you may have misunderstood?

My main editor is IDEA, followed by vscode and emacs. But all three are set to vim mode. Vim itself has actually never been my primary editor; I generally only use it when I'm sshed into servers.

The thing that vim mode gets me is twofold: It (mostly) unifies the editing interface among all of those editors, and it allows me to edit code more quickly.

The thing I was talking about above is not indenting - my autoformatter does that for me. The thing I was talking about is (a sort of hacky version of) syntactically aware editing that allows me to quickly do large-scale operations without having to explicitly fiddle with the cursor.

Re: Nim 1.6

#128

Post by sausage_dog »

iffycan wrote: post #119

Nim has been such a fun language to use. I make a money-earning desktop application (Electron for the GUI and Nim for the core logic) and companion web service (fully Nim). It has been a pleasure using Nim to make these and other things. Congrats, Nim team!

I would love to see this, what's the product?

Re: Nim 1.6

#129

Post by hota_mazi »

adgjlsfhk1 wrote: post #43
DeathArrow wrote: post #16

>Nim made its first entry in TIOBE index in 2017 at position 129, last year it entered the top-100, and for 2 months the top-50 (link). We hope this release will reinforce this trend, building on Nim’s core strengths: I wonder if it has chances to ever enter top 20.

why use tiobe when it is so clearly a bad metric? Pypl or the ieee index are much more reliable.

Not sure why you say these are much better when all these surveys pretty much give you the same result, if you look at these rankings in terms of brackets.

Basically, they pretty much all agree which languages are the top 3, top 5, top 10, etc...

Re: Nim 1.6

#130

Post by sergiotapia »

Nim needs that one killer framework and it's off to the races. A Rails or a Phoenix, batteries/ORM included for Nim. Imagine running a very scalable, productive project on peanuts hardware with very fast performance. Killer.
Post reply on HN