Hacker News new | ask | show | jobs
by beagle3 4088 days ago
Have you tried Nim[rod]? Seems to be pythonesque in almost every way, except speed, in which it is goesque.
2 comments

Aside from having whitespace-sensitive syntax, Nim isn't Python-esque at all. Nim very much encourages TIMTOWTDI over Python's there-should-be-preferably-one-way-to-do-it. Nim also has extremely flexible syntax where Python is rigid. See Nim's pervasive use of metaprogramming via macros, or its inclusion of user-defined symbolic operators (as per Haskell and Scala), or the fact that it considers `foo` and `Foo` and `FOO` and `f_O__o` to be equivalent identifiers, or its inclusion of UFCS.

Nim is a neat language, but comparisons to Python solely because it has semantic indentation are completely shallow (especially so when you consider that Guido doesn't even think that whitespace sensitivity is an important feature).

I agree that idiomatic Nim (if there is such a thing) is very different than idiomatic Python.

What I meant (and did not express clearly) is that you can write mostly pythonesque code in Nim, and it will perform as well as Go. You don't have to modify the syntax, use macros, define symbolic operators, operational transforms, etc any more than you have to use metaclasses in Python.

At it's core, if you write "typed python" code in Nim, it will work, be readable, and perform well.

I haven't, but I have tracked Nim since announcement. It might be a great language, but I don't think it will ever be appropriate for my use case, which is reasonably performant mid-size codebases that junior/journeyman developers can be productive in almost immediately.

If you read the "Why Nim" posts, they are highly salient points for a 'journeyman' or better developer that wishes to be highly productive on a small project; I read the list of 'better than Go' stuff with that hat on, and it's very appealing.

But, there's too much rope to hang oneself in Nim for my use case. Getting a language stripped down just enough that team productivity over years is maximized is a very, very hard thing to do. I think the go folks have the best take on it right now, and it's run by courteous and responsive grownups who do what they say they'll do. That's a total win in my book.

Add in go fmt, a very good (not without warts) module import system, reasonable testing and a multi processor programming model that's easy to reason about, and it is a very, very good solution for my needs.