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

231–240 of 271 posts

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

#231

Post by zozbot234 »

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.

These patterns are not "easy" at all - for one thing, they're non-compositional and anti-modular. They're exactly the kind of thing `unsafe {}` was intended for - though it would be nice if Rust came with a way of writing proofs of safety for these things, and this is a field of active research.

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

#232

Post by pclmulqdq »

urthor wrote: post #46
ilovecaching wrote: post #13

The best language to learn and use right now for systems programming is C/C++. It is by far the most marketable skill with 99.999999% of all low level systems written in C or C++. Large scale systems used by companies that pay top salaries for developers (Google/Meta) are written in C++. There is more material out there for learning and mastering these languages than any other language save maybe Python or JavaScript…

The Rust community is however, an excellent community to be part of. And it's future proof. Everyone knows Rust is the future. I'd say, for most college students, Rust would be the one you'd advise today.

I don't know it's the future. I was writing C and C++ when everyone was yelling that Go would replace them. I am still writing a lot of C and C++ while people yell that Rust will replace it. Chances are when Zig/Nim/Pony becomes the new hotness, I will still be writing a lot of C and C++.

Beyond Rust, Apple has swift, Google is working on "Carbon," and there's a ton of active work on improving the safety of C++. The future is exciting, but there is a lot more than just Rust in it.

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

#233

Post by rich_sasha »

anyfactor wrote: post #207
rich_sasha wrote: post #6

I'm choosing between learning Nim or Rust. Nim frankly looks like the nicer of the two, but also less marketable and with smaller community. Suck to say but it's true.

I honestly don't think your options should be between Nim and Rust. Nim has a very small community, and almost nobody is hiring for Nim experience. Going through Nim's forum, I think most developers tend to work on Nim projects alone. If marketability is your priority, learn the popular languages like java, c, c++, golang etc. Even people hiring Rust developers usually have some leeway to hire someone who can learn R…

I think you are jumping to conclusions about my choices. Why do you explain to me how to decide when you don't know my objectives and constraints?

My main language is Python, to that I'd like to add a compiled, native code, fast-ish, statically typed language with good Python interop. That takes away JVM and .net languages and leaves, roughly, C++, Rust, Nim, maybe Go. I take Go off because I don't like it. I also can't stand modern C++. What does it leave me with?

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

#234

Post by aprdm »

nu11ptr wrote: post #228
aprdm wrote: post #165

Earlier quoted context omitted.

Maybe you should try a language where people get a lot of work done in the day to day ? E.g: Python, Go... It seems crazy to me someone who code in Scala, now loves Rust. Brains are really something else :)

I've written extensively in about 10 languages including the two you mentioned. The current project I'm writing is migrating from Python to Rust. Python is not appropriate for large projects IMO and this one I wrote and am now porting to Rust is no exception. I do love Python for things up to 1000 lines or so, but after that you really need to test every single line, which is just a PITA. Mypy and now others help, bu…

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 a lot of those yourself.

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

#235

Post by kcartlidge »

TylerE wrote: post #156
anta40 wrote: post #154

Hmm.. wonder why Pascal isn't on the list

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 by the time you reach it you've tested your idea and got sales.

As for Pascal standards, I'm not entirely sure why there would need to be a recent one. Standards bodies have their place, but their activity is pretty much never something I ever give a thought to when deciding on software tooling.

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

#236

Post by kaba0 »

StillBored wrote: post #185

I tend to be a C with objects (compiled with a C++ compiler) type of person because I think things like the base string, memory blob, etc types in C should have the ability to have bounds checking built in at compile time if the programmer chooses. Simply fixing the few things "wrong" with C I tend to think gets you 95% of the way to a heavier weight environment like java/etc. So, I can't help but feel that all these…

> So, I can't help but feel that all these languages are trying to solve that last couple percent, and paying a huge price in perf or programmer productivity to do it, at the cost of basically close to 0% bugs actually being reduced

What about those “heavy” languages like Java, etc? Why don’t you use those then? I really don’t think that it has been true for the last 20 years to claim that they have a huge perf cost. And you really can’t go down the “safe” path in Java, even race conditions are well defined after all.

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

#237

Post by nu11ptr »

aprdm wrote: post #234
nu11ptr wrote: post #228

Earlier quoted context omitted.

I've written extensively in about 10 languages including the two you mentioned. The current project I'm writing is migrating from Python to Rust. Python is not appropriate for large projects IMO and this one I wrote and am now porting to Rust is no exception. I do love Python for things up to 1000 lines or so, but after that you really need to test every single line, which is just a PITA. Mypy and now others help, bu…

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 nothing to do with success of large projects,

Of course it does, but they do not exist in isolation either - it is just one component. There are many factors that would play in.

> it’s everything around it. The culture of the company, the cicd systems, the release system, the build system, packaging, documentation , rollback, dependencies.

My point about python is that it literally _requires_ you to make up for language deficiencies (aka dynamic typing + unchecked exceptions) by testing insane amounts to even make it possible. The things that work against you at large scale, work for you at tiny scale (aka scripts).

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

#238

Post by celeritascelery »

nu11ptr wrote: post #130
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

Rust lifetimes are just the lifetimes of the memory, exactly the same as C. The only difference is you simply need to (sometimes) tell Rust where the memory for a reference comes from explicitly, where as in C you don't (but in C if you get it wrong your program will segfault, unlike Rust, or worse it might not...sometimes).

> Rust lifetimes are just the lifetimes of the memory, exactly the same as C.

Rust lifetimes are only the lifetimes of the memory that are provable by the type system. There are many valid lifetimes that are not provable. For example lifetimes that change at runtime, and self referencing lifetimes, or cyclic lifetimes. Newer versions of the borrow checker enable it to prove more lifetimes correct, but it will never be able to express all valid lifetimes of the actual memory.

This means some patterns the are completely valid cannot be expressed in safe Rust due to the limitations of the type system, but can be expressed in C.

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

#239

Post by insanitybit »

celeritascelery wrote: post #238
nu11ptr wrote: post #130

Earlier quoted context omitted.

Rust lifetimes are just the lifetimes of the memory, exactly the same as C. The only difference is you simply need to (sometimes) tell Rust where the memory for a reference comes from explicitly, where as in C you don't (but in C if you get it wrong your program will segfault, unlike Rust, or worse it might not...sometimes).

> Rust lifetimes are just the lifetimes of the memory, exactly the same as C. Rust lifetimes are only the lifetimes of the memory that are provable by the type system . There are many valid lifetimes that are not provable. For example lifetimes that change at runtime, and self referencing lifetimes, or cyclic lifetimes. Newer versions of the borrow checker enable it to prove more lifetimes correct, but it will never…

And you can use unsafe.

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

#240

Post by nu11ptr »

platinumrad wrote: post #189
estebank wrote: post #168

Earlier quoted context omitted.

Anything you can express in C, you can in Rust. When it comes to pointer tricks you might have to use unsafe, but that is part of the language.

If only 50% of the community didn't think it was their job to scream at complete strangers for using that part of the language.

Agreed (unfortunately). There is too much of an obsession in avoiding unsafe at all costs in my opinion. When you consider all C/C++ is effectively written in an unsafe block then it seems a bit ludicrous to assume you would never ever use unsafe in tight, performant code.
Post reply on HN