...hasn't Swift become a viable alternative in this space by now? I see it's getting used in ML a bit, and looks nicer than D and easier to learn than Rust.
Just like Objective-C, Swift is mostly a thing on Apple platforms.
Why I rewrote the mesh generator of Dust3D from Rust to C++
151–160 of 283 posts
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#152Earlier quoted context omitted.
That's a decent attempt at suppressing OP's message, but the thing which makes all of the above irrelevant is that C and C++ developers are the main groups of developers Rust is targeting. If they can't use the language, the Rust community should perhaps listen to them. Or should have listened to them 10 years ago, because let's be frank: the friction is coming from the fact that Rust can't be changed any more so tha…
C/C++ developers can't use Rust without learning new concepts . That's not a failure. If there were no new concepts, then there wouldn't be any point in the langauge in the first place.
Contrariwise there is huge demand for a language with a trimmed-down set of concepts from C++ and a much improved syntax.
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#153Earlier quoted context omitted.
Being able to use more D would be nice! But the binding issues remain the same there. There recently was talk about having the D compiler emit C++ headers for exports from D modules automatically. This would be an instant killer feature for me.
dpp is en effort that allows to include C++ headers, also there is ongoing effort to link with C++. https://github.com/atilaneves/dpp
Yes, dpp has issues with C++ constructs according to its readme unless that changed recently. I am talking about the inverse: have dmd generate a C++ header automatically for extern(C++) declarations during compilation. This was discussed quite recently.
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#154Earlier quoted context omitted.
Unity makes it very clear in their blog posts that Burst is a special vectorizing compiler. It is not a linter at all. I am not sure where you got that notion. IL2CPP was required to be able to stick with C# and stay relevant for mobile gaming. They forced themselves into this corner by wanting to stay with C# and become relevant for mobile gaming. Compare all this to Unreal. By sticking to C++, they do not have to c…
Actually they do, because Blueprints need to support graphical debugging and profiling as well. Some studios don't want to mess that much with Unreal's C++. Then Unreal has their own C++ runtime to allow for a tracing GC.
Still, Epic does not have to commit the same amount of resources. That is my point. The Unreal Build Tool and Unreal Header Tool do not come for free, but this is still less than two sets of optimizing compilers in my book.
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#155Earlier quoted context omitted.
> However, the author is still someone who does not know how to use a programming language and is still bound to not only the mental model of another programming language but also bad practices that lead to problems. Well, that's the same attitude ("the language is fine, you just don't know how to use it, that's why you have bugs") that led us to 30+ years of shitty unsafe C code. Now it's applied to the other side (…
> I don't care if the author is a Rust expert or total newb. Someone who can write a 3D modeler in C++ is someone who should be able to use any new Algol-derived language with ease in short time, regardless if they hasn't seen a line of code in that language before. This statement is absurd. It implies that you believe that there are only cosmetic differences between languages, that no language can ever introduce any…
> This statement is absurd. It implies that you believe that there are only cosmetic differences between languages, that no language can ever introduce any useful new concepts.
Well, the fact that you've missed the whole "Algol-derived language" is more absurd to me. Rust, in the end, is C++-streamlined plus fighting with the borrow checker.
Not some huge new paradigm shift in how we construct programs (as would be eg. going from C to Lisp or Idris) -- just making the lifetime aspect of memory management explicit and having the coder handle it (in lieu of e.g. a GC).
In an ideal world, Rust's lifetime management would be automatically derived by the compiler (in several cases, when it's simple, it already is).
Which is why I don't consider it some new paradigm of how to think about programs or how to structure programs (like OO or FP or logical programming are).
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#156Earlier quoted context omitted.
I do qualify that I speak about languages that are still "Algol-derived". Rust is not some significant paradigm shift (like e.g. Scheme vs C vs Prolog vs Haskell, etc). It's the same concepts and programming styles as C, C++ etc, plus fighting the borrow checker.
Actually, a lot of the issues that C/C++ programmers have when they are new to Rust seem to be precisely because idiomatic Rust code (which can help to avoid borrow checker issues) is often in a more functional Scheme/OCaml style. Rust is both algol-derived, and ocaml-derived. And arguably the borrow checker creates a new paradigm entirely.
>Actually, a lot of the issues that C/C++ programmers have when they are new to Rust seem to be precisely because idiomatic Rust code (which can help to avoid borrow checker issues) is often in a more functional Scheme/OCaml style.
Well, those are not the issues that concern me, or that most (in blogs/HN posts/comments/etc I've read) consider the hard parts. It's the borrow checker.
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#157Earlier quoted context omitted.
>You still have to fight with borrow checking in Rust as in C++, it’s just not automated. It's not that easy. The borrow checker gives you memory safety and thread-safety. In C++, you always have to worry about memory safety, so here the ownership model and borrow checker is a pure win. However, in C++ you don't have to worry about thread safety in a single thread...there's no barrier to passing pointers around and m…
My counter argument is nicely summed up by The Problem With Single-threaded Shared Mutability ( https://manishearth.github.io/blog/2015/05/17/the-problem-wi... )
I like the blog post, and I mostly agree with you that shared mutability can cause problems in big programs. It's something I try to keep to a minimum in most code I write, and I'm better at avoiding it after learning rust.
The thing is, getting rid of shared mutable state entirely is a huge paradigm shift. It means many libraries (GUI libs especially) can't be cleanly wrapped. It means throwing away common data structures like linked-lists. A C++ programmer can learn the syntax of rust is a week, but it may take years to get comfortable with the borrow checker.
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#158Earlier quoted context omitted.
> you are making a mistake that in C++ would have bitten you down the line. Taking some C++ code from an explorative phase that "usually works kinda ok" to something seaworthy requires, in my experience, a huge amount of work (which usually neglects a few issues that will bite you later regardless). I'm not so sure the (probably) faster exploration in C++ compensates for this compared to more "strict" languages like…
I found that strict compile time checks speed up my exploratory phase. That's because the type system provide an even tighter feedback loop than a REPL, and effectively cuts down the search space. Other people seem to have experienced the opposite, though. I have no idea why.
It might depend on the problem space. I dunno. But I suspect it depends a lot on the type system and type inferencer of the language you use.
It is easier to write a true statement than it is to prove the statement is true, and getting a compiler to agree to compile quite literally requires proving a statement is true. This can be more or less difficult based on the language. I’ve read a lot of war stories, particularly in java, about having to do a lot of crazy convoluted code to get the compiler to realize that yes actually these 2 objects are interchangeable from an API/Interface point of view. I don’t know, but I suspect this may be a lot less common in languanges using hindley-milner type system, since that lends itself to very good type inferencing.
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#159One day, social anthropologists will read these Hacker News message forums to learn about tribal warfare among programmers. What will they say, considering their entire new world was based on Rust?
Kidding. Stop fighting, people. You're all on the same team.
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#160My hypothesis is a software growth, like a business or an economy, is fueled by debt. We create technical debts, both deliberately and accidentally, to write software faster. And when the software proves itself as a viable project, we could (ideally) start paying the debt.
Rust forces users pay certain kinds of debt upfront that makes Rust attractive for rewriting, but I don't think it's that much attractive for greenfield projects. You'd want to fight your problems, not your problems plus Rust. On top of my head right now I couldn't think of any famous Rust projects which aren't a rewrite.
Personally I don't think Rust is that hard to learn and some of my side projects are being written in Rust. But if I ever had a business with Rust as a main language, I'd be worry I could find enough Rust programmers. Fortunately the community is addressing its ergonomics and hopefully one day its approachability and learning curve will also gain more attention.