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?
101–110 of 271 posts
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?
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.
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?
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 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).
> 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?
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.
Nim desperately needs a real web framework (batteries included) and a proper ORM and it will take off like wildfire. Python on steroids.
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…
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!
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.