Live data from Hacker News

A Programming Language Underdog

totallywearingpants.com

131–140 of 238 posts

Re: A Programming Language Underdog

#131
post #54

Earlier quoted context omitted.

I like the concept of Nim, as in: fast, statically typed, inferred, compiled etc. but I do not enjoy whitespace-sensitive languages, so am keeping an eye on Crystal more than Nim. If that doesn't bother you, Nim is really neat.

Actually, I'm curious why people don't like white space sensitive languages. I get the tab v space thing, and there are certainly a couple of other down sides, but none of these seem like deal breakers to me. Given that python was the second language I learned, it's possible that I drank the coolaid early and I'm blind to some things that are truly egregious. So the question is: why do folks completely avoid a langua…

> why do folks completely avoid a language for a single relatively bland syntactic feature?

Personal preference isn't a good enough reason?

I don't like white space sensitive languages because I've seen what happens in python when somebody accidentally adds a couple of lines formatted with spaces into a file formatted with tabs. I've seen git and svn mangle tabs. Long blocks are harder to track. Refactoring functions and nested ifs are much harder to keep track of. If you somehow lose all of the formatting in a block or a file, it's much more difficult to recreate the code if the only block delimiters are whitespace.

Essentially, white space delimiters are just one more thing that can go wrong and ruin my day. I try to keep those to a minimum. That said, Nim is my new go to for short scripts. I wouldn't write anything large in it for the reasons mentioned above.

Re: A Programming Language Underdog

#132
post #128
post #117

Earlier quoted context omitted.

Due to GC Julia will never be as fast as C, C++ or Rust.

This isn’t true. GC’d languages can be as fast or faster than C. Especially LuaJIT.

>Especially LuaJIT.

In the general case that can't really be true, because the Lua interpreter is written in C.

With regards to GC languages in general, if you spend a lot of time working around the GC by doing things like object pooling, which is really just reinventing manual memory allocation, you can get close to a non GC language in terms of performance.

GC languages are obviously fine for plenty of use cases, and for some use code snippets they can be faster, but there is no way to make a GC free--there's going to be some overhead no matter what you do.

Re: A Programming Language Underdog

#134

Earlier quoted context omitted.

This. But also "Javascript" is a way overloaded term. The JS community is quite fragmented. Same could really be said of all of them. "Just use those" may come with a caveat of "also be conservative about what tooling you adopt around the language you choose."

I almost left Javascript off the list because of it's peculiar (but interesting!), prismatic nature. Still, they all transpile to Javascript (I think?), so really it's all just javascript ;)

In that case Nim should make the cut since it transpiles to C, C++, Obj-C, and JavaScript. :)

Re: A Programming Language Underdog

#135
post #128

Earlier quoted context omitted.

This isn’t true. GC’d languages can be as fast or faster than C. Especially LuaJIT.

>Especially LuaJIT. In the general case that can't really be true, because the Lua interpreter is written in C. With regards to GC languages in general, if you spend a lot of time working around the GC by doing things like object pooling, which is really just reinventing manual memory allocation, you can get close to a non GC language in terms of performance. GC languages are obviously fine for plenty of use cases, a…

The point of a tracing JIT is that it runs code in an interpreter, then generates machine code for loops and hot spots. By doing this at runtime you can take advantage of knowledge that a C compiler doesn't have. This is why LuaJIT is often faster than C.

Re: A Programming Language Underdog

#136
post #3

Earlier quoted context omitted.

Yep. Concurrency is achieved via async await. Parallelism via `spawn`. Here is an example from my book that uses both: https://github.com/dom96/nim-in-action-code/blob/master/Chap...

Where is supporting use of multiple cores on the roadmap?

Compile with `--threads:on` and everything in the threadpool module are available. You can also use `CreateThread` for long-lived threads.

Alternatively, you have an open-mp for loop that you can use with `||`:

    for i in 0||1000:
      doParallelSomething()

Re: A Programming Language Underdog

#137
Nim is my favorite language right now. If you look at the different metrics that we use when discussing programming languages, it might not be the best of any category, but its "good enough" in every category. It might not have as powerful a type system as Haskell, but it's safe enough. It might not be as fast as C, but its fast enough. It might not be as easy as Python or Ruby, but it's pretty easy to get started with. It might not be the best web server / embedded / native UI language, but it can do all of those things. Its primarily procedural, but supports a lite version of FP and OOP, so you can program in a comfortable paradigm. It's truly a jack of all trades languages, and I think with a little time it might start mastering some.

Re: A Programming Language Underdog

#138
post #7

Earlier quoted context omitted.

What are Nim’s main weaknesses?

Post author here. A few things that make me sad in the pants: - js doesn't have source maps (kinda of a big deal to me) - some error messages are head scratchers (seem to remember trying to add things to an immutable array not being clear) - docs could use love (eg seeing more examples of macros in action) - devel (their nightly compiler) can be rough (e.g. i found the "strings cannot be null" cutover a bit rocky --…

The docs issue and devel being rough are both due to the pre-1.0 status and the smaller community. It's a little bit of a catch-22; you need adoption to gain contributors but people won't adopt until there's enough contributions to make it stable.

Re: A Programming Language Underdog

#139
post #66

I do not think all this language fragmentation is a good thing. A million little obscure languages that all at the end of the day do the same thing. Yeah, we need language research to keep devising new features and more efficient ways of programming, but this is different. I wish the world would get behind a couple well thought out languages that cover most programming needs (functional, systems/bare metal, scripting…

The honest truth is that it’s easier to be famous as a big dev in a small pond than a small dev in a big pond. As communities stagnate, it is harder to get your name known and becomes more political than technical.

It is a social problem, not a technical one.

Re: A Programming Language Underdog

#140
post #54

Earlier quoted context omitted.

Actually, I'm curious why people don't like white space sensitive languages. I get the tab v space thing, and there are certainly a couple of other down sides, but none of these seem like deal breakers to me. Given that python was the second language I learned, it's possible that I drank the coolaid early and I'm blind to some things that are truly egregious. So the question is: why do folks completely avoid a langua…

> why do folks completely avoid a language for a single relatively bland syntactic feature? Personal preference isn't a good enough reason? I don't like white space sensitive languages because I've seen what happens in python when somebody accidentally adds a couple of lines formatted with spaces into a file formatted with tabs. I've seen git and svn mangle tabs. Long blocks are harder to track. Refactoring functions…

Nim disallows tabs entirely, and in Python 3 it's an error to mix the two in the same file. So those errors can't happen anymore.

Out of your list, the only one that seems like a real problem is recreating blocks if the code lost all formatting.

Post reply on HN