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

Show HN: “Nim in Action” is now available

nim-lang.org

Post reply on HN
Print view View original

131–139 of 139 posts

Re: Show HN: “Nim in Action” is now available

#131

Post by gokr »

masklinn wrote: post #122
gokr wrote: post #120

Earlier quoted context omitted.

See my comment https://news.ycombinator.com/item?id=10992077 It seems to me that a) Nim is (or at least is meant to be, but bugs can sidestep it) memory safe if you stay within the rules for it, and b) Nim is not throwing around vague claims of safety that are not documented in the language manual.

> It seems to me that a) Nim is (or at least is meant to be, but bugs can sidestep it) memory safe if you stay within the rules for it That's completely worthless. C is also memory-safe if you stay within the rules for memory safety. > Nim is not throwing around vague claims of safety that are not documented in the language manual. Of course not since nim is not posting on HN (as it's not a sentient being prone to pr…

IMHO it's not worthless. Nim has ptr and addr, but they are explicitly described as unsafe and only used "when you have to", like interfacing with C/C++ etc. I have never used them outside of C/C++ integration. Rust also has unsafe, but I presume you don't think that invalidates safety.

Re: Show HN: “Nim in Action” is now available

#132

Post by steveklabnik »

k__ wrote: post #130
steveklabnik wrote: post #110

Earlier quoted context omitted.

We have tried but the author has not gotten back the few times we've tried. Tried again today, check the issues there.

Can you say something about those points? I mean there aren' many... HTTP Server? DB Drivers? Frameworks? E-Mail? I mean on Node.js I use Hapi (+a few plugins) and Sequelize, which does pretty much everything for me. I would guess, that everything besides the DB drivers is available in Rust too...

It's not just about how many, but how mature they are. There's been a lot of work in the last year.

For servers, there's rotor and hyper. Database drivers, we have very good Postgres and MongoDB options, with some SQlite bindings too. Possibly others, I don't pay too much attention to this space. We have multiple ORMs, one of which is being written by the maintainer of Rails' ActiveRecord. As for frameworks, we don't have a ton of full-stack ones, but a number of the smaller ones, iron, nickel, etc. I haven't explored email yet, but I know that there's some work there.

Re: Show HN: “Nim in Action” is now available

#133

Post by steveklabnik »

patates wrote: post #117
steveklabnik wrote: post #35

Earlier quoted context omitted.

This website is _extremely_ outdated, please don't take it as accurate.

Sorry, I had no idea. Will update my comment. It's a pity, though. I really liked checking on the status of the latest work for web development in Rust from a single place. edit: It seems that I can't edit that comment anymore.

Yeah, totally not your fault. It was convenient, oh well...

Re: Show HN: “Nim in Action” is now available

#134

Post by pcwalton »

gokr wrote: post #120
masklinn wrote: post #74

Earlier quoted context omitted.

> I just wish we could look at Nim as a language with different design goals than Rust. Claims that Nim is memory-safe when it's not is not a difference of design goal though.

See my comment https://news.ycombinator.com/item?id=10992077 It seems to me that a) Nim is (or at least is meant to be, but bugs can sidestep it) memory safe if you stay within the rules for it, and b) Nim is not throwing around vague claims of safety that are not documented in the language manual.

Even with the threading/memory management issues fixed by enforcing shared-nothing, Nim isn't memory safe unless the undefined behavior issues that come from compiling to C (for example, dereferencing a null pointer) are sorted out.

As I understand things, though, solving them is a work in progress.

Re: Show HN: “Nim in Action” is now available

#135

Post by Jach »

dom96 wrote: post #126
Jach wrote: post #114

Earlier quoted context omitted.

I think the chapter has a good overview of other language comparisons, but the final table should probably include a few others like D and OCaml (and if you're including those you should also include Lisp via SBCL and Racket..) and stress that for Nim the GC is not only "Yes, multiple" but also optional/bypassable, which is of great importance to C/C++ people. Maybe an appendix for more details / more languages? Rust…

Thank you for this very thorough review :) I agree with many of your points and I will do my best to incorporate them into my book. The reason I have compared Nim to Python so heavily is for two reasons: 1) I used to be a Python programmer and chose Nim as a replacement. 2) I see a lot of Python programmer's trying out Go and saying describing it as a "better, faster Python". Perhaps that is just a HN illusion. I in…

I don't think I'll ever fully understand the Python --> Go transition, I sometimes have to shrug and attribute it to the power of big company backing. I think the drain has mostly been from Python web and networking programmers, probably a bunch of devops scripters too, but with web pretty much everything else that offers easy to use and high performance web servers out of the box is a cause for drain too, so I think the transition to Go directly is probably less severe than what one might think from HN submissions. Python is much more anyway and will remain a strong choice for many areas for years to come. For your point 2 I agree completely, for the few reasons that I can kind of understand why one would do Python --> Go, Python --> Nim (among several other viable options) ought to weigh in as a better choice based on the same reasoning, and Nim offers other extra reasoning criteria to sweeten the deal. I'm not sure how to target Go users other than to consistently show their favorite domains are done better with another language.

Re: Show HN: “Nim in Action” is now available

#136

Post by ben0x539 »

masklinn wrote: post #122
gokr wrote: post #120

Earlier quoted context omitted.

See my comment https://news.ycombinator.com/item?id=10992077 It seems to me that a) Nim is (or at least is meant to be, but bugs can sidestep it) memory safe if you stay within the rules for it, and b) Nim is not throwing around vague claims of safety that are not documented in the language manual.

> It seems to me that a) Nim is (or at least is meant to be, but bugs can sidestep it) memory safe if you stay within the rules for it That's completely worthless. C is also memory-safe if you stay within the rules for memory safety. > Nim is not throwing around vague claims of safety that are not documented in the language manual. Of course not since nim is not posting on HN (as it's not a sentient being prone to pr…

> That's completely worthless. C is also memory-safe if you stay within the rules for memory safety.

It's really not any weaker of a guarantee than Rust makes, being memory-safe if you stay within the rules of not saying `unsafe`. Or opening /proc/self/mem for writing, anyway.

I'd also feel a lot better about Rust's moral highground of memory safety if its undefined behavior was actually spelled out a bit more rather than just punting the hard parts to llvm docs. I don't think every Rust user knows how to avoid aliasing problems between `&mut` and `*mut` either.

Re: Show HN: “Nim in Action” is now available

#137

Post by EugeneOZ »

k__ wrote: post #130
steveklabnik wrote: post #110

Earlier quoted context omitted.

We have tried but the author has not gotten back the few times we've tried. Tried again today, check the issues there.

Can you say something about those points? I mean there aren' many... HTTP Server? DB Drivers? Frameworks? E-Mail? I mean on Node.js I use Hapi (+a few plugins) and Sequelize, which does pretty much everything for me. I would guess, that everything besides the DB drivers is available in Rust too...

HTTP Servers - all is ok

Frameworks - all is fine

HTTP client - Hyper works fine.

Email - homemade email servers is a good way to go into blacklists, so mandrill/postman is the much better choice.

"Several hundred thousand things about the place" - not actual anymore, there are rare things which are not covered by crates. Just open crates.io and type name of thing you need.

Re: Show HN: “Nim in Action” is now available

#138

Post by dom96 »

mkesper wrote: post #103
dom96 wrote: post #15

Earlier quoted context omitted.

Thank you for the kind words! I'm happy that you can see the positives in Nim even though you dislike one of its most prominent features. Personally I love significant whitespace and have started using Nim because of this feature, basically back in the day I just wanted a Python alternative that was compiled. If you really dislike it that much, you may be able to convince Araq to bring back his old time idea of allow…

The first chapter talks too often about the Python2/3 problem, I'd say. Python users know this subject very well and others couldn't care less.

I will see about ensuring that that problem is only mentioned in the first chapter once. Thank you for your feedback!

Re: Show HN: “Nim in Action” is now available

#139

Post by pcwalton »

ben0x539 wrote: post #136
masklinn wrote: post #122

Earlier quoted context omitted.

> It seems to me that a) Nim is (or at least is meant to be, but bugs can sidestep it) memory safe if you stay within the rules for it That's completely worthless. C is also memory-safe if you stay within the rules for memory safety. > Nim is not throwing around vague claims of safety that are not documented in the language manual. Of course not since nim is not posting on HN (as it's not a sentient being prone to pr…

> That's completely worthless. C is also memory-safe if you stay within the rules for memory safety. It's really not any weaker of a guarantee than Rust makes, being memory-safe if you stay within the rules of not saying `unsafe`. Or opening /proc/self/mem for writing, anyway. I'd also feel a lot better about Rust's moral highground of memory safety if its undefined behavior was actually spelled out a bit more rather…

Well, I think there's a very big practical difference between being unsafe in general and unsafe only within clearly delimited boundaries (that you can forbid with a lint). The latter is pretty much necessary for any language other than strictly sandboxed ones like JavaScript, while the former is something I think all languages in 2016 should take as sacrosanct from the get-go. (We've been trying and failing for about 45 years to prove that programmers will avoid making the same basic memory management mistakes if they're just trained better; I think it's well past time to give up and delegate these checks to the machine.)

That said, I don't agree with the claim that Nim is less safe than Rust because Nim uses "ptr" types and Rust uses "unsafe" blocks to mark unsafe regions. I prefer Rust's approach, but it's pretty much just a question of UI, not anything substantive.

Post reply on HN