Live data from Hacker News

Choosing Nim out of a crowded market for systems programming languages

forum.nim-lang.org

101–110 of 271 posts

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

#101
> OCaml, Haskell, F#, and other weirdos: I personally can't do it. I tend to not like functional programming languages. I want to, but my brain lacks the plasticity to relearn everything.

Why would you find OCaml hard to learn if you know Nim? Isn't Nim a functional programming language as well?

Also, how is Nim for writing real-time games that run via JavaScript where you want to avoid garbage collection pauses?

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

#102

I really can’t understand where this idea that rust is ‘hard’ comes from. Everything that it formalizes is something that you should already be conscious of . If not, well… you have a different, bigger problem.

It's not an 'idea'. Many people find it hard (I do). You might not understand why this is the case, but that they (we) do is an empirical fact.

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

#103

Earlier quoted context omitted.

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?

Because indentation-based languages have very limited formatting they can do. They can't do any indentation formatting.

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

#104
post #46

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.

> The Rust community is however, an excellent community to be part of.

I honestly haven't found this to be the case. There is a constant denial that some people might find Rust difficult (with a very strong implication that if they do, it's because of inferiority on their part), and extreme thin-skinnedness towards even the possibility that Rust might not be for everyone. Indeed, a bluff assertion that it is for everyone is part of its official tagline. The community keeps up a surface politeness, but it always looks to me that it achieves this by keeping a tight lid on dissent (or appearance thereof).

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

#105

> OCaml, Haskell, F#, and other weirdos: I personally can't do it. I tend to not like functional programming languages. I want to, but my brain lacks the plasticity to relearn everything. Why would you find OCaml hard to learn if you know Nim? Isn't Nim a functional programming language as well? Also, how is Nim for writing real-time games that run via JavaScript where you want to avoid garbage collection pauses?

Nim is not really functional. Like most modern languages, you could probably pull of a functional style with it, but it's mutable, imperative, etc.

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

#106

Earlier quoted context omitted.

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.

Indeed. Something wihout security impact will use pointless resources when you update. Do it rarely (or never if possible).

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

#108
post #47

Earlier quoted context omitted.

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?

Fortran us better than C and even C++ for its domain, high-performance numerical code. The guaranteed lack if aliasing allows for optimizations not always possible in C code. Built-in handling of stuff like complex numbers and even range types in modern Fortran (that is, supported for last 25-30 years), along support for parallelization, and with robust structured / procedural programming, is just the right tool for…

None of this is true or very important anymore.

For aliasing, in C, there's the restrict keyword, although it isn't used that often. If you take a look at BLIS or even BLAS, restrict isn't used. C++ doesn't have restrict, but that hasn't stopped the development of great numerical linear algebra libraries like Eigen or Armadillo.

C++ has had std::complex for... forever. And C99 has support for complex numbers.

Range types are handy, but not having them typically isn't a show stopper when designing libraries of numerical kernels. They are more useful for high-level prototyping, a la MATLAB. Nevertheless, it's not that hard to emulate the behavior using a well-designed API in C, or operator overloading in C++.

The only parallelism that Fortran has that C or C++ lack is co-array Fortran. I haven't used it myself, so can't speak to how useful it is. Both C and C++ have many options for parallelism: pthreads, OpenMP, MPI, C++'s parallel stuff, and tons of other libraries.

I'm not sure what "robust structured/procedural programming" is. I think Fortran is at a clear disadvantage compared to C and C++, here. The amount of boilerplate needed to define a function in Fortran is pretty painful. Fortran's control flow is a subset of C and C++'s, so any style of structured or procedural programming you would do in Fortran can obviously be done in C and C++.

And of course, numpy (and similar) call out to Fortran, but they call out to loads of C and C++, too!

This isn't to say Fortran is a bad language. I work with people who use it and prefer it. But the reasons you pointed out simply aren't valid. A good reason to use Fortran: you work in a group where Fortran is the language that's used and you want to be able to contribute to what's going on!

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

#110

Nim does not have a native ssl and regex lib in the standard library like golang or python. These libraries are taken for granted nowadays.

It doesn't? https://nim-lang.org/docs/re.html and https://nim-lang.org/docs/net.html are part of nim's standard library. Are they missing something you expect?
Post reply on HN