Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nim 1.0

nim-lang.org

Post reply on HN
Print view View original

261–270 of 308 posts

Re: Nim 1.0

#261

Post by dixego »

qwerty456127 wrote: post #254
arc776 wrote: post #194

Earlier quoted context omitted.

I would say metaprogramming (and maybe the excellent FFI) is the huge stand-out feature for Nim. However whilst you can compare all these languages and find a particular niche or set of features that sell them, Nim is just good at pretty much everything. I know that sounds pretty bombastic, but you can practically pick any task and know that Nim will let you get there rapidly and performantly. That's it's ultimate st…

This sounds like everybody should be using Nim. Why do they still use Python, C# etc and why is Nim still so rare then?

Having had it's 1.0 release a day ago might have something to do with it.

Re: Nim 1.0

#262

Post by dom96 »

nunchuckninja wrote: post #255
arc776 wrote: post #194

Earlier quoted context omitted.

I would say metaprogramming (and maybe the excellent FFI) is the huge stand-out feature for Nim. However whilst you can compare all these languages and find a particular niche or set of features that sell them, Nim is just good at pretty much everything. I know that sounds pretty bombastic, but you can practically pick any task and know that Nim will let you get there rapidly and performantly. That's it's ultimate st…

Scala and rust both compile to JS too I think.

Do they have first-party JS backends though? I think that's what sets Nim apart, the Nim compiler includes the JS backend which means the JS backend is always up to date with the latest Nim developments.

Re: Nim 1.0

#263

Post by uryga »

littlestymaar wrote: post #226
uryga wrote: post #210

Earlier quoted context omitted.

i guess the argument is that you'll never read random garbage instead of a well-formed object; and given that random garbage could result in pretty much arbitrary "undefined behavior", it should at least guarantee that your program will behave roughly as intended, even if giving incorrect results (i'm not convinced that's a useful thing myself)

> and given that random garbage could result in pretty much arbitrary "undefined behavior" Nitpick: UB doesn't come from reading random garbage, it's quite the opposite: UB could result in reading random garbage, but it could also result in many worse things.

i put it in quotes because i meant "arbitrarily weird side-effects", but you're right that i should have used a different term

Re: Nim 1.0

#264

Post by yellowapple »

pjmlp wrote: post #242
balfirevic wrote: post #237

Earlier quoted context omitted.

Doesn't .NET (and C# with it) have stop-the-world GC, very similar to Java? Or do you mean something else?

CLR was designed for multiple languages execution models, including C++. In what concerns C#, besides GC, you get access to off heap unamaged allocations, low level byte manipulations, value types, inlined vector allocations, stack allocation, struct aligments, spans. All GCs have eventually to stop the world, but they aren't all made alike, and it is up to developers to actually take use of the language features for…

> All GCs have eventually to stop the world

Not entirely true. Erlang's BEAM definitely doesn't need to (unless you define "world" to be a single lightweight process). Perl6's MoarVM apparently doesn't need to, either.

Re: Nim 1.0

#265

Post by pjmlp »

yellowapple wrote: post #264
pjmlp wrote: post #242

Earlier quoted context omitted.

CLR was designed for multiple languages execution models, including C++. In what concerns C#, besides GC, you get access to off heap unamaged allocations, low level byte manipulations, value types, inlined vector allocations, stack allocation, struct aligments, spans. All GCs have eventually to stop the world, but they aren't all made alike, and it is up to developers to actually take use of the language features for…

> All GCs have eventually to stop the world Not entirely true. Erlang's BEAM definitely doesn't need to (unless you define "world" to be a single lightweight process). Perl6's MoarVM apparently doesn't need to, either.

Yes, I do define it like that, there is always a stop, even pauseless collectors actually do have a stop, even if a few microns.

Doing it in some local context is a way to minimize overall process impact.

Just like reference counting as GC algorithm does introduce pauses, specially if implemented in a naive way. More advanced ones end up being a mini tracing GC algorithm.

Regardless, having any form of automatic memory management in system languages is something that should have already become standard by now.

Re: Nim 1.0

#266

Post by arc776 »

arc776 wrote: post #253
marble-drink wrote: post #205

Earlier quoted context omitted.

Talk of metaprogramming intrigues me. I'd like to hear what a Lisp user makes of it because I find non-Lisp users are usually amazed by any metaprogramming at all and can't be as critical about it.

Metaprogramming is one of the core ideals in the birth of the language so is well supported. Personally I've not used Lisp, so can't comment there, but it is on the list of influences on the homepage. Essentially there's a VM that runs almost all the language barring importc type stuff, and you can chuck around AST node objects to create code, so metaprogramming is done in the core Nim language. You can read files so…

In hindsight maybe the "performers" table would be better named "resultVars", as that's what it really represents.

Re: Nim 1.0

#267

Post by greyfade »

qwerty456127 wrote: post #254
arc776 wrote: post #194

Earlier quoted context omitted.

I would say metaprogramming (and maybe the excellent FFI) is the huge stand-out feature for Nim. However whilst you can compare all these languages and find a particular niche or set of features that sell them, Nim is just good at pretty much everything. I know that sounds pretty bombastic, but you can practically pick any task and know that Nim will let you get there rapidly and performantly. That's it's ultimate st…

This sounds like everybody should be using Nim. Why do they still use Python, C# etc and why is Nim still so rare then?

Python has been around since, what, 1994? C# goes back to '99 or '00 or something like that.

Nim goes back to maybe 2008 and only hit 1.0 today.

Re: Nim 1.0

#268

Post by yellowapple »

pjmlp wrote: post #265
yellowapple wrote: post #264

Earlier quoted context omitted.

> All GCs have eventually to stop the world Not entirely true. Erlang's BEAM definitely doesn't need to (unless you define "world" to be a single lightweight process). Perl6's MoarVM apparently doesn't need to, either.

Yes, I do define it like that, there is always a stop, even pauseless collectors actually do have a stop, even if a few microns. Doing it in some local context is a way to minimize overall process impact. Just like reference counting as GC algorithm does introduce pauses, specially if implemented in a naive way. More advanced ones end up being a mini tracing GC algorithm. Regardless, having any form of automatic memo…

There's always a stop, yes, but there's not always a stop of the whole world, which is my point. "Stop the world" implies (if not outright definitionally means - explies?) that the execution of all threads (lightweight or otherwise) stops while the garbage collector runs - e.g. that of (the official/reference implementations of) Python and Ruby.

Erlang doesn't require stopping the world because every Erlang process is isolated from the others (no shared state at all, let alone mutable shared state). I don't know off-hand how Perl avoids it.

Re: Nim 1.0

#269

Post by Mikeb85 »

Fantastic news. I haven't done anything too serious with Nim, but I did find for the code I did write in it, that its extremely intuitive and easy to get going. It also has all the features I could ask for in a language and it never feels like you need to work around a limitation. Of course that's the initial impression, I haven't used it as much as languages that have batteries included for the specific tasks I do (most of the programming I actually do these days is around data analysis, economic forecasting, so R is pretty hard to beat).

Re: Nim 1.0

#270

Post by lmm »

c-cube wrote: post #249
lmm wrote: post #170

Earlier quoted context omitted.

The real question is what it offers over OCaml (1996). Nim people talk about GC being "optional" but have never been able to tell a clear story about what this does and doesn't mean (D has the same problem). Aside from that, even if the language puts everything together in a more polished package than its predecessors (and I've no idea whether Nim does or not), what's the unique selling point that would make it stand…

For me it's more: what does it offer over Crystal (apart from being freshly 1.0). Crystal seems a lot nicer and a bit more, hum, uniform. Nim seems to have a lot of features to be aware of, and doesn't have type-safe nil.

Well Crystal is newer than Nim and gives me even more of a "what is the unique advantage of this language" feeling. As to the specific point, Crystal may be nil safe but union types have many of the same problems as unchecked null (particularly when used with generics). Nim has compiler-enforced not-nil types plus true sum types (and therefore an option type), which make it possible to program in a completely safe way - though I'm not sure how well the standard library supports that approach; I would certainly prefer a language that didn't have null at all, as OCaml does.
Post reply on HN