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

31–40 of 179 posts

Re: Nim 1.6

#31

Post by ijlx »

BiteCode_dev wrote: post #4
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?

As a python dev, nim was much easier to get into than Go, Rust, or even Zig. If you squint, it looks like a toddler Python with strong typing, compilation and a few different API, espacially for managing finalisation.

I may be splitting hairs here but Python is actually a strongly typed language. It would be better to say nim has static typing: https://wiki.python.org/moin/Why%20is%20Python%20a%20dynamic...

Re: Nim 1.6

#32

Post by sp33der89 »

xet7 wrote: post #24

How to run those benchmarks? At that Nim release page: https://nim-lang.org/blog/2021/10/19/version-160-released.ht... Is link to this benchmark: https://web-frameworks-benchmark.netlify.app/result Where nim is 2nd with 200k req/s, but it is using httpbeast: https://github.com/dom96/httpbeast That says it would be more useful to use jester: https://github.com/dom96/jester Jester has 150k req/s. But, when looking at t…

The source code for the benchmarks is here: https://github.com/the-benchmarker/web-frameworks And the httpbeast code is here: https://github.com/the-benchmarker/web-frameworks/tree/maste... TechEmpower and TheBenchmarker are 2 different benchmarks and I'm not sure how they compare.

Besides that benchmarks rarely benchmark realistic code and the Nim blog doesn't mention being the fastest out there, but it mentions "native performance" which I feel like is a fair claim.

Re: Nim 1.6

#33

Post by indymike »

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.

It does, with the right libraries. I started a product last year in Go. If I had done so this year, it would have been with Nim. It's a really interesting language.

Re: Nim 1.6

#34

Post by mkl »

dunefox wrote: post #25
clusterfish wrote: post #17

Earlier quoted context omitted.

Could have just used a "JSON" keyword instead. Symbolic names are needlessly obscure and unfriendly. Hard to infer meaning, hard to pronounce, hard to search online, etc.

As if "json" is any more searchable. Operators have a meaning that you learn quickly when learning the language. You wouldn't do math with "multiply" instead of "*", so why would you want that in a programming language?

Multiply already has a symbol, and JSON already has a name. Making up a symbol %* to mean JSON is like making up a name Flurb to mean *. Sticking with what already exists seems much simpler.

Re: Nim 1.6

#35

Post by dandellion »

dunefox wrote: post #25
clusterfish wrote: post #17

Earlier quoted context omitted.

Could have just used a "JSON" keyword instead. Symbolic names are needlessly obscure and unfriendly. Hard to infer meaning, hard to pronounce, hard to search online, etc.

As if "json" is any more searchable. Operators have a meaning that you learn quickly when learning the language. You wouldn't do math with "multiply" instead of "*", so why would you want that in a programming language?

Because with a keyword the meaning is much more explicit, and I consider that to be more valuable. And I think "*" is a bad example because pretty much everyone who programs already knows it's multiplication.

Re: Nim 1.6

#36

Post by agent327 »

mrath wrote: post #7
sdmac99 wrote: post #6

Earlier quoted context omitted.

Check out this Nim talk. Addresses some of your questions. https://www.youtube.com/watch?v=d2VRuZo2pdA

Thanks I’ll check it out.

Once you're done with that one you can go on with more advanced subjects here: https://www.youtube.com/watch?v=cISmv0IGoQQ

From around 1:00 pointers are being discussed.

Re: Nim 1.6

#37

Post by benob »

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".

C interop is very easy, so you can do embedded dev by disabling memory management and standard lib, and staying very close to the generated C code.

Or you can do high level stuff thanks to well though generics and meta programming.

The js backend is not mature enough to cover high performance web apps. It is more like a gimmick currently. Maybe a wasm layer could be as successful as rust's...

Re: Nim 1.6

#38

Post by pathsjs »

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…

> 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 something. Rather, you keep an open session, such as a REPL or a notebook, and keep computing with the already existing value

Re: Nim 1.6

#39

Post by clusterfish »

dunefox wrote: post #25
clusterfish wrote: post #17

Earlier quoted context omitted.

Could have just used a "JSON" keyword instead. Symbolic names are needlessly obscure and unfriendly. Hard to infer meaning, hard to pronounce, hard to search online, etc.

As if "json" is any more searchable. Operators have a meaning that you learn quickly when learning the language. You wouldn't do math with "multiply" instead of "*", so why would you want that in a programming language?

Of course it is. It's descriptive and searchable.

Because * / - + is the common ground that essentially everyone is familiar with. And that's about as much math notation as makes sense in general purpose programming languages.

There is only one math but many programming languages. Multiplication is universal and fundamental. Creating JSON objects in nim is the opposite of that.

Re: Nim 1.6

#40

Post by vegai_ »

andybak wrote: post #8
zoidb wrote: post #5

Earlier quoted context omitted.

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…

I really like the look of Nim but every time I dig into it I find a really strange syntax decision. For example: > The json module provides the %* operator which is used to create JSON objects I'm curious what the benefits are here of an operator over some more readable syntax. I have a dislike of languages where ascii noise seems to be favoured over readable english tokens.

That's really good point. Also, I don't think it's the only weird operator they introduce in the stdlib without any good reason.
Post reply on HN