Live data from Hacker News

Choosing Nim out of a crowded market for systems programming languages

forum.nim-lang.org

81–90 of 271 posts

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

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

Something I long assumed about Rust before really getting started is that it is /slower/ to develop with. And at first that is definitely true because it introduces some pretty big, powerful, and constraining things. When you learn to work with these things and have taken your lumps discussing your code with `rustc` it is a lot of fun. 1.) Moves / borrowing / memory model 2.) Adopting a more functional style [to supp…

Rust's sphere of necessary domain knowledge is higher than average. That's not a downside relative to the goal it has in mind, but it is a trade-off. When you're an indie developer working on a side project, there's a strong impulse to let go of a lot of the specific quality controls and customizations that you can use in a team setting where you're paid to know how to operate the inner workings, and instead look for something that is "prosumer" and lets you hack out a solution.

It's kind of the difference between "I want to make a camera" and "I want to mod a camera". Making means controlling the design from the beginning, and Rust is one of the best available tools for that. But modding is more like what you do when you want to bodge together some pieces of I/O and data processing. Apps dealing with audio and graphics in any fine-grained sense tend to want the latter: they aren't actually dealing with resource management issues that often, especially not in the "weekend hack" stage, they just need low latency device access and a fast-enough inner loop. And those requirements imposed a massive, non-obvious barrier to entry on stuff with a substantial VM runtime: writing bindings, remapping ABI semantics, etc. You had to learn a lot of concepts, possibly more than are needed for writing useful Rust code, to overcome that. Rust demands just that you use certain kinds of documented idioms to get through a typical coding problem, while fighting with compilers and linkers to create bindings is a no-mans-land of debugging the meaning of each error message, silent failure or crash, requiring you to know two languages, the build system, the binary formats, and the OS you're targeting simultaneously.

For a long time, C++, for all its faults, was the prosumer's tool of choice for coding near to the metal while still leveraging existing tech, because it was what the toolchains actually supported directly, which let you get ypur weekend hack working piecemeal, while using something else introduced unacceptable levels of overhead.

But I think there are now justifications to use Rust in some cases and Zig or Nim in others. I've kicked the tires on all three, and can vouch for Nim feeling productive in the sense of being both relatively C-friendly as a build environment(lots of features for high-permissiveness hacking) and also occupying a "default to high-level methods" mindset. D could have gotten there in an alternate reality, I think, but it was trying really hard to be big-systems code instead of hacker's glue, which has saddled it with an awkward design story. The things D wanted to do well, Rust now mostly occupies.

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

#83

Earlier quoted context omitted.

Something I long assumed about Rust before really getting started is that it is /slower/ to develop with. And at first that is definitely true because it introduces some pretty big, powerful, and constraining things. When you learn to work with these things and have taken your lumps discussing your code with `rustc` it is a lot of fun. 1.) Moves / borrowing / memory model 2.) Adopting a more functional style [to supp…

Rust's sphere of necessary domain knowledge is higher than average. That's not a downside relative to the goal it has in mind, but it is a trade-off. When you're an indie developer working on a side project, there's a strong impulse to let go of a lot of the specific quality controls and customizations that you can use in a team setting where you're paid to know how to operate the inner workings, and instead look for…

I like all of this thinking. I don't deal a lot with ABI and integrating Rust into things, just another programmer that has been writing a Go (and Python) over the last few years and gradually becoming disaffected with its constraints and design, though Go is still a great language to get things done with and much safer than say Python or other dynamic languages. I will say this, though, as an older programmer, even when scratching an itch, it is often worth Doing It The Right Way. It feels freeing to rush ahead, know you are making technical debt, but get a thing to seemingly work.

If you or anyone else ever has to maintain it that technical debt almost always comes calling and it can often be unpleasant. For personal projects, oh well, you move on, maybe you can throw it out. For even small professional projects you are now in the "Find Out" phase of technical debt. So I am just in this mindset of writing meaningful things and saving experiments for truly throw away code, which still has its place. I am gonna go ahead with Rust as my next 5+ year language, a role Go and Python filled. I think my litmus for Python vs. Rust is if it will take me more than a day (estimate) to write, I am going to suck it up and use Rust.

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

#84
Aside, curious what this bit of the post refers to:

> Pros for Swift are focus on secure programming outside of just obsessing over memory safety like Rust.

I've never used Swift at all but would enjoy learning what it brings to the "secure programming" table that I might be missing from the summary at https://www.swift.org/about/#safety

Another aside, the author gets some points for looking at Pony.

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

#85

If I recall Nim doesn't even allow tabs. Programming languages should not be overly opinionated in formatting, especially when it requires extra bytes to use spaces.

Programming languages shouldn't even consider whitespace (except perhaps new lines) syntactically important at all, so the whole discussion is silly. Once you've decided whitespace is important you might as well make emoji part of the syntax.

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

#86

If I recall Nim doesn't even allow tabs. Programming languages should not be overly opinionated in formatting, especially when it requires extra bytes to use spaces.

I disagree entirely. Ideally there should be one valid way to format your code, and robust tools to make that formatting happen automatically. Allowing alternatives yields zero benefit and causes pointless debates and diffs.

The benefit is, what if I don't like four spaces as indentation? What if I like two? Why do other get to force their aesthetic preferences on me when there already exists the tab character, whose apparent width is configurable?

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

#87
post #74

If I recall Nim doesn't even allow tabs. Programming languages should not be overly opinionated in formatting, especially when it requires extra bytes to use spaces.

> Programming languages should not be overly opinionated in formatting I think gofmt, python black, etc have demonstrated that it's usually better to have a single standard then it is to fight endlessly about these details.

It's funny you say that, because Go and Python are two of my least favorite languages, partially for reasons of formatting.

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

#88
post #74

If I recall Nim doesn't even allow tabs. Programming languages should not be overly opinionated in formatting, especially when it requires extra bytes to use spaces.

> Programming languages should not be overly opinionated in formatting I think gofmt, python black, etc have demonstrated that it's usually better to have a single standard then it is to fight endlessly about these details.

They have demonstrated that some people have interest in controlling formatting.

It would be a stretch to say they demonstrated that it’s better to enforce a standard.

Black, itself, changed rules many times within a 1-year period to the point our own CI would fail on existing code that previously passed.

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

#89

If I recall Nim doesn't even allow tabs. Programming languages should not be overly opinionated in formatting, especially when it requires extra bytes to use spaces.

If it helps, you can configure your text editor of choice to auto-swap tabs for spaces. However, I share your displeasure for the gesture.

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

#90
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…

It looks like gintro is a GTK binding - the Rust equivalent would be gtk-rs. https://www.gtk.org/docs/language-bindings/rust/

I'm curious whether you tried gtk-rs and if so what problems did you have?

Post reply on HN