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

241–250 of 271 posts

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

#241

Post by mumblemumble »

moldavi wrote: post #169
mumblemumble wrote: post #160

Earlier quoted context omitted.

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, b…

It's not just doubly linked lists. They're just a basic example of borrow checking not being able to handle a lot of easy patterns that are perfectly safe in other languages.

Fair, but, if so, could we focus on one of those instead?

I'd be especially interested to see an example that's perfectly safe in C or C++, and for which there's no better way of doing the data modeling in Rust. Using the kinds of data patterns that have long been used to avoid circular references in functional programming languages, for example. Because we want to avoid getting too caught up in examples of things that should be hard in Rust because Rust is designed to favor different ways of doing things.

Or, to put it cutely, I'd want to be cautious about doing the equivalent of criticizing a Toyota for having a terrible glide slope.

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

#242

Post by [deleted] »

moldavi wrote: post #184
cropcirclbureau wrote: post #182

Earlier quoted context omitted.

Perfectly safe at the expense of a garbage collector. You can still do pointer soup and int handle based lists as you can do in any other low-level language with the same caveats. Rust is punching up from the manual memory management, zero-cost abstraction plane and competing with the garbage collected langs. It's still at it's core a tool for writing low level code.

GP was confused about why the doubly linked list case was so important, so I enlightened, it's an example of an entire class of the borrow checker's problems. Your response isn't really relevant in that context, and instead escalates to a much larger debate, so best I not engage. Appreciate the thought though =)

[deleted]

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

#243

Post by insanitybit »

mumblemumble wrote: post #152
insanitybit wrote: post #136

Earlier quoted context omitted.

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

I dislike when a discussion turns into "I have to teach you the basics now". I'm just not willing to engage in that most of the time with strangers on the internet because they usually don't want to be taught, they want to be right.

Explaining that you can express complex dynamic lifetimes in Rust using 'unsafe' and module-level safety is a waste of my time because it's empirically true.

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

#244

Post by mumblemumble »

moldavi wrote: post #198
pie_flavor wrote: post #192

Earlier quoted context omitted.

The easy pattern of graph structures is handled by the easy implementation of adjacency lists, which is how you should have been implementing it in other languages too. The specific incompatibility is with the naïve hand-implementations of these structures; the specific thing Rust does not optimize for is toy code.

You know nothing of what I'm programming. You don't know when, whether, or how my program accesses or deletes data. You don't know what domain I'm in, whether I'm on a team, or what our priorities must be. And yet, you proclaim that your approach is how I should always do it in any language, in any situation. It strikes me as particularly convenient, seeing as that's the only approach that the borrow checker can reas…

I agree with the sibling commenter that the parent poster was likely using the impersonal you. It is true that we don't know anything about you. You haven't volunteered any specifics, so we're kind of forced to guess if we want to try and respond in a productive manner.

To that end, I think that they chose a very good example. Abstractly, doubly linked lists are a special case of undirected graphs. So pointing out that a naive graph implementation is generally sup-optimal, and that usually one can more effectively model them using different data structures that Rust (and functional languages, and databases, and files, etc.) can handle just fine, neatly addresses problems that one might solve using a doubly linked list, as well as a whole host of other cases, in a single stroke.

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

#245

Post by TylerE »

kcartlidge wrote: post #235
TylerE wrote: post #156

Earlier quoted context omitted.

Because it’s 2022 not 1982? There hasn’t been a new Pascal standard in 34 years.

I do C#, Go, Python, Node, Ruby, etc., but Free Pascal with Lazarus is my #1 choice for any cross-platform desktop app that needs a decent GUI without using Electron. It's free, fast (enough), and exceptionally easy. If you need a supported system then even Delphi is back to being (not totally un)reasonably priced once you consider that they only charge when you begin earning from it. Their threshold is very low, but…

Standards can be overrated, sure, but some things like Unicode support really need to be done rihht

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

#246

Post by aprdm »

nu11ptr wrote: post #237
aprdm wrote: post #234

Earlier quoted context omitted.

Hm. Ok. Tell it to my previous company running 12 million LoC of Python. It was easier to make changes there than in the 500k loc c++ system I maintained later. Language has nothing to do with success of large projects, it’s everything around it. The culture of the company, the cicd systems, the release system, the build system, packaging, documentation , rollback, dependencies. And for large projects, you’re rolling…

> Hm. Ok. Tell it to my previous company running 12 million LoC of Python. Just because it can be done, doesn't mean it should be done. Just my opinion. > It was easier to make changes there than in the 500k loc c++ system I maintained later. I don't consider C++ a good language in any way, shape, or form. Now had you claimed the same about OCaml, Kotlin, etc. I would have a harder time believing it. > Language has n…

Heheh company with 14 million LoC barely had tests :)

I don’t know what kind of companies you worked on, but let me tell you that the code that runs the world comes from an era before tests, and some of it is too complicated to even be tested.

Test it in production is the only way for a lot of it. Then you need observability and easy ways of rolling back. That’s about it. Regardless of the language.

Read the latest google book — code architects at google I think it’s called ? Has a couple of great chapters on testing at scale and how unittests are useless

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

#247

Post by mumblemumble »

insanitybit wrote: post #243
mumblemumble wrote: post #152

Earlier quoted context omitted.

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.

I dislike when a discussion turns into "I have to teach you the basics now". I'm just not willing to engage in that most of the time with strangers on the internet because they usually don't want to be taught, they want to be right. Explaining that you can express complex dynamic lifetimes in Rust using 'unsafe' and module-level safety is a waste of my time because it's empirically true.

But you are engaging with strangers on the internet. You're just not doing it in a way that's particularly edifying. Indirectly insulting me and others doesn't help your case on that front.

Let me turn it back on you. By refusing to educate people on what you think they got wrong, you come across looking like just what you're worried about: someone who just wants to be right.

If your goal is to defend Rust, I would suggest you either teach for yourself, or share links to others teaching the thing you want to communicate but don't want to type out, or, if neither of those, then to simply keep your peace and let someone else do the responding. Speaking for myself as an on-and-off Rust learner, I've got to say that the single biggest frustration I've experienced with learning the language is wading through all the low effort gainsaying in order to find the nuggets of digestible, practical advice about how to effectively use the language for non-toy problems. It's not that I can't do so, per se. It's just that it's really hard, and perhaps even counterproductive, to work up the motivation to wade through all the snark and invective when my original purpose was to try and unwind at the end of the day.

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

#248

Post by mumblemumble »

moldavi wrote: post #158
pitaj wrote: post #94

Earlier quoted context omitted.

> 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,…

I think that it has to be?

I like Rust well enough, but thinking about memory management is a reasonably large effort that I generally don't have to make in most languages. Rust, in not having a GC, strictly adds to that load compared to most languages out there. The exceptions are languages like C, C++, and assembler, and there I agree that Rust seems to make things a fair bit easier.

(Though, disclaimer, I never got around to learning modern C++, which I gather is a huge improvement over the style of C++ I do know.)

I'd be willing to accept, though, that Rust's lack of full-blown OO features, and its strict controls on mutation, often makes things easier in large shared codebases. Perhaps not letting people do some particularly wild things that I'm used to seeing in Java and C# at my day job. I'm not in a position to have a worthwhile opinion on that claim, though.

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

#249

Post by anta40 »

kcartlidge wrote: post #235
TylerE wrote: post #156

Earlier quoted context omitted.

Because it’s 2022 not 1982? There hasn’t been a new Pascal standard in 34 years.

I do C#, Go, Python, Node, Ruby, etc., but Free Pascal with Lazarus is my #1 choice for any cross-platform desktop app that needs a decent GUI without using Electron. It's free, fast (enough), and exceptionally easy. If you need a supported system then even Delphi is back to being (not totally un)reasonably priced once you consider that they only charge when you begin earning from it. Their threshold is very low, but…

I think Pascal implementations are practically dominated by Delphi and FPC these days (FPC has Delphi compatibility mode).

On the other side, there are more players in C/C++ club: GCC, Clang, MSVC, Pelles C, LCC Win32, AMD C++, Intel C++, etc. Having a standard is certainly useful.

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

#250

Post by efnx »

sph wrote: post #201
dilawar wrote: post #112

Earlier quoted context omitted.

I agree but I tool functional programming course in college. It was hard! Someone who may not have invested enough in leaning basics of FP, I can totally see why Rust feels like a hard language. During the prototyping phase, I also avoid lifetimes and other esoteric features and often use unhealthy amount of Arc and Rc. Nothing beats Cargo and company and loves compiler messages. Have used NIM as python replacement,…

How would functional programming help with Rust? I am fluent in both, and having map and reduce in the Iterator trait does not make Rust anything like a functional language.

The things that make rust “functional” are features like a type system that supports sum and product types and functions as typed values that can be passed around. It really is a functional language (in the original ML sense of the word) but with another orthogonal type system bolted on (borrow checker).

It’s missing some features like higher kinded types but it’s functional nonetheless.

I’m interested to hear what your definition of functional is - it’s always interesting because it’s such a vague term, really.

Post reply on HN