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

Choosing Nim out of a crowded market for systems programming languages

forum.nim-lang.org

Post reply on HN
Print view View original

151–160 of 271 posts

Re: Choosing Nim out of a crowded market for systems programming languages

#151

Post by anon7725 »

j16sdiz wrote: post #137
Cyph0n wrote: post #67

Earlier quoted context omitted.

> tends to encourage playing "language golf" as often as solving actual problems. Is this your perception, or are you actually seeing this being encouraged by the Rust community? > This is an interesting take. I personally don’t agree with OP’s take on Rust at all, but I respect their decision to use whatever language works best.

Not GP. In my experience, “language golf” is very popular in Rust, Scala and Haskell communities.

“language golf” will sour me to a language/community very quickly. I especially despise implicits, as they make source code utterly unreadable without the help of tools.

Re: Choosing Nim out of a crowded market for systems programming languages

#152

Post by mumblemumble »

insanitybit wrote: post #136
francasso wrote: post #128

Earlier quoted context omitted.

Oh boy, that is so not true. Anything where the boundaries of the lifetimes are easily determined at runtime but unknown at compile time is extremely easy to model safely in C, and a nightmare in Rust. At least if you want the same level of performance and a similar modeling of the data

> Anything where the boundaries of the lifetimes are easily determined at runtime but unknown at compile time is extremely easy to model safely in C, I don't even know how to respond to this seriously. I guess just imagine me pointing to every blatant instance of this not being true.

With all due respect to Michael Palin, "this isn't an argument ... it's just contradiction."

Perhaps, for the benefit of those of us observing if nothing else, it might be beneficial to identify some concrete examples to discuss before proceeding.

Re: Choosing Nim out of a crowded market for systems programming languages

#153

Post by rbetts »

lamontcg wrote: post #149
julianeon wrote: post #124

Earlier quoted context omitted.

I'm close in age to you but that was one part of the article that resonate w me. I'm often writing little scripts for my computer or things that a dozen people will use, if I'm lucky. If the program 'crashes' it barely matters. It feels like, in Rust, I have to carefully choose my data type and use the applicable methods (not always intuitive), whereas in Nim or Go, I can basically just slap something together and th…

I mean "unwrap()" and "panic!() are right there for "blow up and don't care", if you're really just doing throwaway scripting that should be enough. And the "?" operator is way more ergonomic for throwing actual errors up a level than all the boilerplate in Go. The pattern matching with `match` `if let` and `let else` are pretty easy to use to unwrap Result and Option enums. And then the "anyhow" or "thiserror" crate…

Kind of an ironic reply - naming 10 Rust features and libraries vs. an `if` check in Go to argue that Rust has simpler ergonomics for throw-away code.

Re: Choosing Nim out of a crowded market for systems programming languages

#157

Post by TylerE »

cdaringe wrote: post #132

> I feel inferior for not being fluent in OCaml I learned OCaml recently, on my own, for myself. It’s actually a pretty easily language to use and learn, but historically there weren’t EXCELLENT resources for learning it. There are now excellent resources, predominantly: https://cs3110.github.io/textbook/cover.html When OCaml 5 settles, its general applicability will be (imho) much larger. Do I recommend it for every…

Ocaml is a (mostly) good to great language with horrible tooling that completely kills any desire I have to work with it.

Re: Choosing Nim out of a crowded market for systems programming languages

#158

Post by moldavi »

pitaj wrote: post #94
127 wrote: post #41

I have done non-trivial things both in Rust and Nim. For big projects Rust seems a little more robust, but for medium and small projects Nim is an order of magnitude faster to develop for. There are still many rough edges, but it's exactly the tradeoffs I would personally pick for my one person small business making tools for artists. So far I have been using Rust and it's alright, but looking very much into Nim to s…

> looking very much into Nim to see if I can replace Rust because of the high cognitive load to keep all of the Rust stuff in my head, as I don't really need safety. Personally I find that Rust has less cognitive load, because so much of what you'd generally worry about in other languages is covered by language features in Rust: static typing, algebraic data types, etc

I'm sometimes a bit confused when people say that Rust has less cognitive load. I assume that's compared to something like C or C++, right?

I've used Rust and (imperative-style) Scala a lot, and I have to say, Scala is way easier since it doesn't have to deal with the borrow checker, but it still has an amazing type system.

Nim is statically typed and has algebraic data types, so I imagine it's also as easy as Scala, easier than Rust.

Re: Choosing Nim out of a crowded market for systems programming languages

#159

Post by moldavi »

nu11ptr wrote: post #115

> Rust: I'm not afraid to admit it - Rust is just too complicated for use as an aging and cranky solo developer. ... > As someone who actually hates to code for coding's sake and wants to Get Sh!t Done, Rust is just antithetical to my relationship with computers. I don't want to have to think about the language, and that's all Rust wants you to think about. My guess: the author hasn't even tried it other than a curso…

Can we please not do this?

It's fine to give a different viewpoint, but it's surprisingly common that whenever someone says anything bad about Rust, a Rust user comes in to say that they just haven't used it enough.

It's like saying "If you don't like my favorite movie, you just haven't watched it enough."

Re: Choosing Nim out of a crowded market for systems programming languages

#160

Post by mumblemumble »

nu11ptr wrote: post #139
cdaringe wrote: post #132

> I feel inferior for not being fluent in OCaml I learned OCaml recently, on my own, for myself. It’s actually a pretty easily language to use and learn, but historically there weren’t EXCELLENT resources for learning it. There are now excellent resources, predominantly: https://cs3110.github.io/textbook/cover.html When OCaml 5 settles, its general applicability will be (imho) much larger. Do I recommend it for every…

OCaml is great. One of my favorite languages. I think the only thing hard about it is the fact that it is solidly FP, and that is not a familiar paradigm to many. One of these days I want to check out F# so I can use the whole .NET set of libs as well (the only bad thing about ocaml is the small ecosystem of libs). > These jokers in this thread “oh rust isnt hard! Ohhh they probably didnt try much.” Respectfully, get…

The doubly linked list thing strikes me as more of an illustration of cultural differences between C programmers an the rest of the world than as a straightforward criticism of Rust.

I've no doubt that doubly linked lists are an awkward hassle to implement in Rust. But the same is true in functional languages, and you never hear people criticizing, e.g., Haskell over this. I have a couple guesses as to why that is, but I'm guessing the main one is that Rust being touted as a C replacement results in people assuming that Rust should be amenable to the same kind of (for lack of a better way to put it) hyper-imperative approach to problem solving that C basically forces upon people.

But I'm also pretty sure that I've never, in my 30 years of programming, used a doubly linked list in anger in a language that wasn't C. (Maybe Pascal?) I have never used Rust in anger, either, but, based on my little bit of dabbling, it seems like yet another language where I would be likely to choose any number of different data structures first. I certainly wouldn't be implementing my own in any case. These days, implementing doubly linked lists from scratch seems to be very nearly the sole province of C programmers and undergraduates.

Post reply on HN