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

81–90 of 179 posts

Re: Nim 1.6

#81

Post by rattray »

1_player wrote: post #73
rattray wrote: post #69

Earlier quoted context omitted.

Sure, JS isn't ideal for compilers, but it is quite good - typescript is a better and more performant compiler than many languages have, as just one example. You wouldn't be crazy for choosing JS for a new compiler project, even for work that had nothing to do with JavaScript. (You would be pretty crazy to choose js to build a rich data science backend, in comparison). I do agree the GC rules out some use-cases like…

Please don't write a compiler, that has nothing to do with JavaScript, in JavaScript. It needs correctness, safety and speed, none of which are JS (nor TS) strengths. You can, but that's a prerogative of all Turing-complete languages. There are much better languages fit for the purpose, which is the point of this comment thread.

Hmm, we're discussing "just how general-purpose can your general-purpose language be?", no? Ie, if a company wanted to use one language for everything, where would they be essentially unable to?

Keep in mind "a compiler" may not be for "a widely used general purpose programming language" but something smaller with a specific use, especially in the context of a company.

JS has many quality libraries for parsing grammars etc, and is Fast Enough for the purpose unless you need incredible perf - Python or Ruby, for example, might be much worse choices.

Even C++ might be a worse choice depending on your project's objectives (sure it might be faster but it might be a lot less maintainable, especially compared to TS). I also don't buy the argument that TS would make it harder to write a correct/safe compiler than C++.

Rust and Haskell may be sexy for the purpose but would be much slower to get started with, especially if your team isn't already staffed with experts. The Sorbet team at Stripe chose C++ over Rust because they felt developing with the latter would be too slow.

Keep in mind that most people are sticking with pure-JS build stacks even as esbuild et al are coming on to the scene. And the TS team has stuck with a Node compiler despite having the resources and know-how to use something totally different.

Please don't tell people to avoid writing a compiler in JS/TS unless you really know the specifics. :)

Of course, all of this does make me curious how Nim is for compilers (I imagine it'd be very, very nice).

Re: Nim 1.6

#82

Post by arc776 »

rattray wrote: post #52
sph wrote: post #41

Earlier quoted context omitted.

> I can't really imagine a single language that would be a good choice for "everything". Full stack Javascript enthusiasts are nowhere to be seen in this thread, but are writing their backend, frontend, desktop and mobile JS, WASM, Ethereum backend and the next ARM instruction set to speed up JS code natively, silently working towards total world domination. The nanomachines that will bring forth the end of the world…

JS is also great for scripting, but really isn't popular for ML or data science (no pandas/numpy/scipy equivalents I think, other than tensorflow.js). I'm curious how Nim fares for DS/ML.

Nim has a popular ML library "inspired by Numpy and PyTorch": https://github.com/mratsim/Arraymancer

One of the advantages of the language for DS/ML is the native "C like" performance with very low developer friction.

Another advantage from a library perspective is being able to automate fast, low level boiler plate code from easy to use DSLs using AST macros. For example a DSL could generate bespoke code for different data layouts and pipelines etc., giving you the best possible performance without the user worrying about it.

Re: Nim 1.6

#83

Post by kevin_thibedeau »

rgrmrts wrote: post #23
sp33der89 wrote: post #19

Earlier quoted context omitted.

Well no language is perfect, but Nim can be used in almost every domain because of it's compilation targets(C, C++, JS) and it's fast compile times(who needs interpretation when compile times are that fast!): * Shell scripting, I still assume most people will just use Bash tho: https://github.com/Vindaar/shell * Frontend: https://github.com/karaxnim/karax or you could bind to an existing JS library. * Backend: For so…

I haven’t used nim outside of some hello world toying a few years back. Is compiling actually that fast? I thought the nim compiler compiled to C and then called gcc (or whatever system compiler), isn’t that slow in practice? Any large nim projects that anyone can point me to would be helpful too, I’ll give the compiler a shot later today!

When using Nim for "scripting" it is recommended to use TCC for rapid compilation. It is genuinely fast.

Re: Nim 1.6

#84

Post by h2odragon »

pathsjs wrote: post #38
sp33der89 wrote: post #19

Earlier quoted context omitted.

Well no language is perfect, but Nim can be used in almost every domain because of it's compilation targets(C, C++, JS) and it's fast compile times(who needs interpretation when compile times are that fast!): * Shell scripting, I still assume most people will just use Bash tho: https://github.com/Vindaar/shell * Frontend: https://github.com/karaxnim/karax or you could bind to an existing JS library. * Backend: For so…

> who needs interpretation when compile times are that fast! Well, interpretation is pretty useful for a REPL. And a REPL is not just useful to avoid compilation, but also as a way to explore a new API. And, most importantly, to preserve the results of long computations when you do not know yet what to do with it. If computing a value takes half an hour, you certainly don't want to recompute it each time you change s…

> don't want to recompute it each time you change something

True... May I introduce you to the filesystem?

Re: Nim 1.6

#85

Post by ImprobableTruth »

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.

I mean, it kinda does? You get a result that's wrongly indented if you miss a brace.

Re: Nim 1.6

#86

Post by haxscramper »

akovaski wrote: post #80

I started looking at Nim a few months ago, but I didn't like the feature where it ignores underscores and capitalization. It seems to me that this would make grepping harder on larger projects. I suppose a linter or style-guidelines-and-not-making-mistakes invalidate this issue. For anyone that has used Nim, has this been a problem in practice?

No, never. Actually the most problem I've ever had with this feature is seemingly unending discussions that come up in almost every single HN discussion ever, like https://news.ycombinator.com/item?id=28651040

> would make grepping harder on larger projects

There is a built-in tool `nimgrep`, but honestly I never even need for that - `rg` worked perfectly fine each time I had to do something like that.

Re: Nim 1.6

#87

Post by mst »

akovaski wrote: post #80

I started looking at Nim a few months ago, but I didn't like the feature where it ignores underscores and capitalization. It seems to me that this would make grepping harder on larger projects. I suppose a linter or style-guidelines-and-not-making-mistakes invalidate this issue. For anyone that has used Nim, has this been a problem in practice?

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 from people freaking out over nim caring about whitespace, so at least we get some variety in our aesthetic worrying from people who've not had time to try the language yet :D

Re: Nim 1.6

#88

Post by Thaxll »

zoidb wrote: post #5
mrath wrote: post #2

I don’t know much about Nim, does it have a mandatory gc, like go? How good is Nim’s gc? Those who have written some Go and Nim, home does the code look like vs go?

I have written a bit of both, recently re-wrote a command runner for a side-project https://gitlab.com/jarv/cmdchallenge in Nim and found it very pleasant and much less verbose, which was a nice change from GoLang while keeping type safety. A good example is parsing JSON https://nim-by-example.github.io/json/ as you can do a lot with fewer lines of code. I think the main disadvantage of Nim is that there is less out…

That %* is really strange. Also in the example there is no notion of errors? Nim is exception based?

Re: Nim 1.6

#89

Post by enthus1ast »

sp33der89 wrote: post #19
turminal wrote: post #18

> Why use Nim? > One language to rule them all: from shell scripting to web frontend and backend, scientific computing, deep learning, blockchain client, gamedev, embedded, see also some companies using Nim. Does that work in practice? I can't really imagine a single language that would be a good choice for "everything".

Well no language is perfect, but Nim can be used in almost every domain because of it's compilation targets(C, C++, JS) and it's fast compile times(who needs interpretation when compile times are that fast!): * Shell scripting, I still assume most people will just use Bash tho: https://github.com/Vindaar/shell * Frontend: https://github.com/karaxnim/karax or you could bind to an existing JS library. * Backend: For so…

* Backend: For something Jinja/Twig-like: https://github.com/enthus1ast/nimja

Re: Nim 1.6

#90

Post by aEverr »

ImprobableTruth wrote: post #85
boardwaalk wrote: post #70

Earlier quoted context omitted.

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. I mean, it kinda does? You get a result that's wrongly indented if you miss a brace.

well yeah, then what? where would the missing brace be? you can't really tell since now the formatter clobbered your indentation, unless you remember, of course
Post reply on HN