What makes Nim practical? • Hacker News Board

Re: What makes Nim practical?

#111

Post by quotemstr » Sat, Jan 24, 2015, 2:41 AM UTC

filwit wrote: post #103

quotemstr wrote: post #74

Earlier quoted context omitted.

If a language's lexical structure is so tortured that I need a special tool to grep it, I'm going to skip it and go back to the sanity of C++.

Ridiculous. We use "special tools" for every other language (Visual Studios, Eclipse, etc).. Calling a language feature, which give programmers style freedom, a "tortured lexical structure" is not an objective argument. Especially since we have a tool (nimgrep) which addresses the issue and takes < minute to learn. Once Nim has better IDE support, no one will be grepping in the first place.

I don't need special tools to just _search_ a C++ or Java program.

Sure, I can use nimgrep, but I can't use _my_ grep, _my_ freetext indexer, _my_ editing constructs, and so on. I'm not going to make my environment, which works fine for almost all programming languages, bend over backwards to support your special snowflake of a language.

I'd rather just use something else.

Re: What makes Nim practical?

#112

Post by codexon » Sat, Jan 24, 2015, 3:26 AM UTC

fenollp wrote: post #105

codexon wrote: post #87

Earlier quoted context omitted.

There's 1 thing that can't be done in Nim that you can do in Go though. And that is the goroutine system. Something like that needs to be explicitly baked into the language. You can try to emulate it with your own thread pools but you will never get the same level of preemption. However few people will ever need this feature, and erlang/elixir probably does it better, though at a the cost of speed.

But but but Go's concurrent scheduler just isn't preemptive. It's cooperative (and that's meh).

It is preemptive on function calls just like erlang.

Re: What makes Nim practical?

#113

Post by girvo » Sat, Jan 24, 2015, 4:09 AM UTC

codexon wrote: post #85

def- wrote: post #70

Earlier quoted context omitted.

That's on its way!

Doesn't nim already have autocomplete?

Built into the Nim compiler, yeah, it has a `idetools` feature that makes integrating it into an IDE far simpler. I've been playing around lately with getting it into Textadept, now that Textadept has a better "call some particular binary and get input and output from it" story.

Re: What makes Nim practical?

#114

Post by girvo » Sat, Jan 24, 2015, 4:11 AM UTC

mVChr wrote: post #58

CyberShadow wrote: post #29

Nim has some good ideas but I can't get over the syntax: - Significant whitespace, but tabs are forbidden - No block comments, save for `discard """ ... """` - Identifiers are case and underscore-insensitive (FOO_BAR === fooBar === fo_ob_ar)

> - Identifiers are case and underscore-insensitive (FOO_BAR === fooBar === fo_ob_ar) In the language design stages who in the world thought this would be a good idea? Even PHP doesn't do that.

It's really nice when you're talking to a C library that use various prefixes and other stylistic choices that don't map well to the Nim code I want to write.

Re: What makes Nim practical?

#115

Post by SamReidHughes » Sat, Jan 24, 2015, 4:25 AM UTC

andybak wrote: post #34

wtf_is_up wrote: post #24

Earlier quoted context omitted.

> significant whitespace That's not an advantage

From my personal perspective - it's a major plus when choosing a language - under the general auspices of "readability counts". I find Python-like languages much easier to read and maintain - and significant whitespace is a not-insignificant factor in that.

It's not like code in other languages isn't indented.

Re: What makes Nim practical?

#116

Post by Jweb_Guru » Sat, Jan 24, 2015, 6:39 AM UTC

CyberShadow wrote: post #59

pcwalton wrote: post #55

Earlier quoted context omitted.

You can do it with a compiler plugin; I suspect that's what the parent comment was referring to. Admittedly compiler plugins are pretty experimental at this time.

Sorry about that. I haven't tried this myself, I was told by a Rust user that its CTFE was on par with D's. I guess he was mistaken.

Not even close, sadly.

Re: What makes Nim practical?

#117

Post by woadwarrior01 » Sat, Jan 24, 2015, 10:43 AM UTC

untitaker_ wrote: post #47

moe wrote: post #2

I love how these new languages compile into a static binary and thereby avoid the deployment nightmares of Ruby/Python. More of that please!

I came across [pex]( https://github.com/pantsbuild/pex ) a while ago. It basically compiles your package and all its dependencies into a single zipped module. I never had the opportunity to try it out myself though.

If PEP-441[1] makes it to Python 3.5, pex like functionality will be a part of the standard library.

[1]: https://www.python.org/dev/peps/pep-0441/

Re: What makes Nim practical?

#118

Post by eatfish » Sat, Jan 24, 2015, 1:15 PM UTC

nkurz wrote: post #69

bpicolo wrote: post #62

Earlier quoted context omitted.

Let's be realistic. If you have somebody naming variables: foo_bar = blah foobar = blah fooBar = blah That's someone you really don't want to be coding anywhere near, because it leads to really, really confusing code. So nim is just enforcing not being able to do it it as a language.

I agree, but the problem is that you don't ever want to do this whether those are three different variables (or is that two?) or whether all are alternative forms of the same case/underscore insensitive name. Nim is going out it's way to make the syntax you have about legal (will all of these equivalent), which strikes me as a bad move. The best case for usability is that this "feature" never used, which makes it an…

I think it would be a lot more palettable if Nim enforced one of those coding conventions per module, while letting users of that module reference it any way they liked. e.g. my team could exclusively use camelCase and the compiler enforced that in our modules, while the same code could be handed off to some other team that exclusively uses snake_case.

Re: What makes Nim practical?

#119

Post by klibertp » Sat, Jan 24, 2015, 1:47 PM UTC

quotemstr wrote: post #111

filwit wrote: post #103

Earlier quoted context omitted.

Ridiculous. We use "special tools" for every other language (Visual Studios, Eclipse, etc).. Calling a language feature, which give programmers style freedom, a "tortured lexical structure" is not an objective argument. Especially since we have a tool (nimgrep) which addresses the issue and takes < minute to learn. Once Nim has better IDE support, no one will be grepping in the first place.

I don't need special tools to just _search_ a C++ or Java program. Sure, I can use nimgrep, but I can't use _my_ grep, _my_ freetext indexer, _my_ editing constructs, and so on. I'm not going to make my environment, which works fine for almost all programming languages, bend over backwards to support your special snowflake of a language. I'd rather just use something else.

> to just _search_ a C++

Please, be serious.

> but I can't use _my_ grep, _my_ freetext indexer, _my_ editing constructs

Oh, but you can! These are _your_ tools, you can easily extend them by either scripting or modifying source, no problems there. Really, how much of a problem is adding a switch for underscore insensitivity to your program? Because I assume case insensitivity you had already coded.

Oh, unless by "_your_ grep" you meant a tool that someone else wrote and you're using without any real understanding of how it works and without required skill or knowledge to modify it. Right, this can happen, you're a busy man, have many obligations and no time at all to fiddle with grep. I understand.

But that also makes you completely outside of a target group of early adopters of new programming languages. So maybe stop commenting on them?

Re: What makes Nim practical?

#120

Post by xkarga00 » Sat, Jan 24, 2015, 2:03 PM UTC

beeworker wrote: post #63

xkarga00 wrote: post #9

Earlier quoted context omitted.

Care elaborating on why is it a better Golang?

Just about everything is better than Go. Nim, Rust, OCaml, Haskell... Did you read the submission? And for further enlightenment, the link to the previous post on the blog about what makes Nim special? Here's a link to a rant comparing Go and Rust, which includes some links of its own highlighting further issues with Go: http://www.quora.com/How-do-Go-and-Rust-languages-compare

I've read both the submission and the articles that exist inside that Quora link you posted and I am still not convinced. IMO what makes a language better is end products and not features. When Rust becomes stable, its community will produce great software but I don't think all of the rest languages you mentioned have produced (or will do) better software than Docker, Kubernetes, OpenShift, etcd, btcd, and a ton of other Go software.