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

91–100 of 271 posts

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

#91

Post by ParetoOptimal »

Herbstluft wrote: post #35
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.

People have done (and are still doing) amazing work in Fortran too. Why should we use C or C++ when Fortran was already perfectly fine?

Exactly. They are just arbitrarily drawing the line of which language is sensible based upon what was hot when they made their choice.

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

#92

Post by georgelyon »

mlinksva wrote: post #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.

I can’t speak for the author, but I’ve had a similar feeling. Where (safe) Rust’s core principle is memory safety at all costs, I feel that Swift takes a more nuanced approach, prioritizing making good programming patterns easier while still being memory safe (though perhaps not as expressive as Rust).

Swift also is much more principled when it come to certain things like exceptions. Whereas Rust (if I remember correctly) allows arbitrary panic-ing and catching of panics, Swift forces you to acknowledge a possible panic at function call sites using “try”. Without “try” control flow can’t suddenly end.

Admittedly, I haven’t used Rust significantly in a couple years, but I wrote this a few years back and some of the points still have merit: https://gist.github.com/GeorgeLyon/c7b07923f7a800674bc9745ae...

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

#93

Post by throw827474737 »

bobbylarrybobby wrote: post #85
encryptluks2 wrote: post #70

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.

Why not? Making identation part of the syntax allows more for less?

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

#94

Post by pitaj »

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

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

#95

Post by __turbobrew__ »

pigsinzen wrote: post #88
thunky wrote: post #74

Earlier quoted context omitted.

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

> CI would fail on existing code that previously passed.

You problem isn’t that black changed formatting rules, your problem is that you didn’t pin CI dependencies. This isn’t a unique problem to black, any other tool used in CI pipelines can cause things to break if you don’t pin them.

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

#96

Post by lamontcg »

mikebenfield wrote: post #78
encryptluks2 wrote: post #70

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.

> causes pointless debates

yes, having languages establish an immutable standard for tabs vs spaces has clearly ended all debate over them.

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

#97

Post by [deleted] »

bobbylarrybobby wrote: post #86
mikebenfield wrote: post #78

Earlier quoted context omitted.

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?

[deleted]

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

#98

Post by lamontcg »

> Rust: I'm not afraid to admit it - Rust is just too complicated for use as an aging and cranky solo developer.

I'm nearly 51 and currently learning Rust.

The first 10 hours of it were horribly slow, but it isn't as steep of a learning curve as Optimal Control Theory.

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

#99

Post by tmtvl »

bobbylarrybobby wrote: post #85
encryptluks2 wrote: post #70

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.

I disagree: if we make languages have NWS (Non-optional WhiteSpace) then we can easily disambiguate between:

  let traversed-distance := yard-length;
And:

  let traversed-distance := yard - length;
Which is valuable as kebab-case is best case.

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

#100

Post by kibwen »

georgelyon wrote: post #92
mlinksva wrote: post #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.

I can’t speak for the author, but I’ve had a similar feeling. Where (safe) Rust’s core principle is memory safety at all costs, I feel that Swift takes a more nuanced approach, prioritizing making good programming patterns easier while still being memory safe (though perhaps not as expressive as Rust). Swift also is much more principled when it come to certain things like exceptions. Whereas Rust (if I remember corre…

> Whereas Rust (if I remember correctly) allows arbitrary panic-ing and catching of panics

While it is possible to "catch" a panic in Rust, this is not an error-handling strategy, it is a correctness fallback. The intent is that, if you're writing a Rust library that exposes a C ABI, you halt the panic at the boundary of your library, because there is no standardized cross-language unwinding scheme and so unwinding across an FFI boundary would be UB. It's not there for error handling (and it can't be, not only because the API is deliberately designed to discourage it, but also because Rust programs can be compiled in a mode where panics abort instead of unwind).

> Swift forces you to acknowledge a possible panic at function call sites using “try”. Without “try” control flow can’t suddenly end.

This is a bit inaccurate. You can absolutely do things like divide by zero in a Swift function that isn't marked as `try`, which will crash the program. This is the same behavior that is expected of panics in Rust.

Post reply on HN