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

61–70 of 271 posts

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

#61

Post by alpaca128 »

ilovecaching wrote: post #20
tomrod wrote: post #15

Earlier quoted context omitted.

Nah, parent commentator and me both think Nim could be really large. The definition of "systems programming language" is defined by arbitrary lines.

Web apps are applications and are the opposite of systems software. Systems software would be the web server itself, or something that runs beneath the application layer. Yes definitions are sometimes nebulous but that doesn’t mean words should lose all meaning and we should stop trying. Systems programming is a useful label for the boot stack, kernel, protocol implementations etc. which support the application layer…

The "systems" label only means those languages can do a few more low-level things, nothing more. There's no reason not to use it for other things as well.

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

#62

Post by fsociety »

ilovecaching wrote: post #23
whage wrote: post #7

The author seems to be very knowledgeable about the different aspects of programming. Whether you agree with his opinions or not, this article I think is a great starting point for learning about many interesting topics. Definitely bookmarked for later.

They sound like someone that is attracted to chasing the high of the next technology to learn rather than picking a language like C/C++ that would have worked and given them way more career stability. Rather than mastering a bunch of programming languages they should have focused on one and built clout as a problem solver that doesn’t see a new shiny tool as a way to label their career. Boring popular language + focu…

Perhaps they care more about exploration and learning rather than career growth and solving business problems.

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

#63

Post by elcritch »

Cyph0n wrote: post #30

> [..] I decided that I need a safe, fast, and statically typed language that can be compiled and targeted to both mobile and desktop environments, as well as being made available to scripting languages via FFI. And you eliminated Rust because.. it’s too complicated? It meets these requirements to the letter! Since this is a greenfield effort, would it really be too expensive to invest some time to learn it? Anyways,…

The authors reasoning makes sense to me. Rust is powerful but also complicated and tends to encourage playing "language golf" as often as solving actual problems.

> there isn't a lot of reason to defer to Rust as an obvious choice outside of the usual focus on memory safety that dominates public opinion. 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.

Nim made me enjoy programming again, largely for these reasons. When I was younger I enjoyed mastering languages like C++ or learning complicated generics systems, but now I enjoy just building useful things with minimal fuss. I don't care as much about type soundness of my CTFE, just that I can parse a file at compile time to do something useful. Sure its on my to ensure my files are stable, but thats just part of programming.

> I don't want to have to think about the language, and that's all Rust wants you to think about. I see a lot of people attracted to Rust where there is no shortage of funding and developer focus tends to be competitive, often leaning towards academic purity over solving pressing customer facing problems. These aren't luxuries I have and, to be frank, is not the profile of developer that one should hire for in an early stage startup. Nim gets out of the way, and stays out of the way.

This is an interesting take.

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

#64

Post by elcritch »

npalli wrote: post #57

Would have liked to see an opinion on the large number of memory management techniques for Nim [1]. Seven types(!) ranging from GC's to manual. Surely this makes reasoning of performance very hard. Where do you focus - your program or the memory management options. Perhaps in practice everyone has settled on one of them(?) [1] https://nim-lang.org/1.4.0/gc.html

The default for the upcoming Nim 2.0 will be ORC. Its the default already on the dev branch since the Nim compiler was switched to use it. See Araq's talk from NimConf: https://youtu.be/aDi50K_Id_k?list=PLxLdEZg8DRwSQQaK0UVRd1Dae...

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

#65

Post by winrid »

_dain_ wrote: post #34
PixyMisa wrote: post #8

Earlier quoted context omitted.

Nim is also easier to learn - if you know Python and any conventional statically typed language, it's a walk in the park. I was producing fast, working code in a couple of hours. Learn Rust for your job, Nim for your side projects.

I'm learning Rust now, I can say Nim is much harder. Maybe the language itself is simpler, but the documentation is just not very good. Very unpolished and amateurish. I actually forked out fifty quid for Araq's "Mastering Nim" book; it is atrocious. Spelling and grammatical errors on every page. The very first code example did not compile. I also regularly run into utterly infuriating bugs while trying to accomplish…

Yeah, I wrote an equivalent service in Java and Nim, and I just couldn't get Nim to perform as well as Java, and it wasn't even easy to write. Random segfaults, depending on memory manager used, random libraries requiring different memory managers, ORC being talked about a lot despite causing random segfaults, and so on.

I really want to love Nim.

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

#66

Post by elcritch »

Escapado wrote: post #28

What’s the LSP and linter/formatter story these days? Last time I tried it the lsp was miles behind what I am used to from TypeScript land in vscode. I have gotten sooo used to all the auto completion, helpful error tooltips and auto imports and formatting on save that it felt tedious not to have that in a similar capacity. Maybe I was just doing things wrong and it’s been a while. In general I am super intrigued by…

Its ok. A developer was recently hired to work on it full time though!

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

#67

Post by Cyph0n »

elcritch wrote: post #63
Cyph0n wrote: post #30

> [..] I decided that I need a safe, fast, and statically typed language that can be compiled and targeted to both mobile and desktop environments, as well as being made available to scripting languages via FFI. And you eliminated Rust because.. it’s too complicated? It meets these requirements to the letter! Since this is a greenfield effort, would it really be too expensive to invest some time to learn it? Anyways,…

The authors reasoning makes sense to me. Rust is powerful but also complicated and tends to encourage playing "language golf" as often as solving actual problems. > there isn't a lot of reason to defer to Rust as an obvious choice outside of the usual focus on memory safety that dominates public opinion. As someone who actually hates to code for coding's sake and wants to Get Sh!t Done, Rust is just antithetical to m…

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

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

#69

Post by bitexploder »

solarkraft wrote: post #36
ilovecaching wrote: post #33

Earlier quoted context omitted.

That take detracts from the amazing work people have done over the decades to research and implement improvements to C and C++. We can innovate without throwing things away, even if it may seem boring to the uninitiated.

Sure. But we can also innovate with throwing things away, which has its own set of advantages.

I have been learning Rust so it is top of mind for me. Rust started with some really tough constraints:

1.) How can we eliminate undefined behavior?

2.) without sacrificing any performance

From there, they built a powerful programming language that has always honored zero cost abstractions and elimination of undefined behavior. This is like a 15 year development and the result is a little hard to understand at first but one of the most innovative things in the realm of systems programming [that people are actually using at scale]. I know Rust borrows a lot and is built on the shoulders of giants and is not a singular invention, but it is slowly winning hearts and minds in places where languages like Ocaml and Haskell never could. You really could not do something like this by saying "Hey, how could we eliminate UB in C++?" Starting anew was the solution :)

Post reply on HN