
Why I rewrote the mesh generator of Dust3D from Rust to C++ - sagartewari01
https://blogs.dust3d.org/2019/03/13/why-i-rewrote-the-mesh-generator-of-dust3d-from-rust-to-cplusplus/
======
mcguire
" _When you implement an algorithm using C++, you can write it down without
one second of pause, but you can’t do that in Rust. As the compiler will stop
you from borrow checking or something unsafe again and again, you are being
distracted constantly by focusing on the language itself instead of the
problem you are solving._ "

Yeah...

On my last C++ project, one very productive co-worker kept disabling -Wall,
etc., because "nobody has got time for that." I periodically fired up valgrind
and chased down assorted memory issues.

So, yeah...

~~~
lixtra
Depending on the situation a write unsafe fast fix later maybe the more
economic approach. Especially if the code is more exploratory, changes a lot
and large parts will be finally discarded.

~~~
bluesroo
I've found that more often, it should be reworded as "unsafe fast, painfully
maintain without the resources to ever fix later".

~~~
bluejekyll
The number of TODO's that litter code in general, or issues file to "cleanup"
are generally significant. You're making a great point that accruing technical
debt at the cost of safety, is quite possibly technical debt, like all other,
that will never be paid down over the life of the software.

I completely agree.

------
__s
/r/rust thread:
[https://www.reddit.com/r/rust/comments/b0erei/why_i_rewrote_...](https://www.reddit.com/r/rust/comments/b0erei/why_i_rewrote_the_mesh_generator_of_dust3d_from)

You'll notice the top rated comment, & majority of comments, agrees with their
decision to switch to C++. Yet we'll persist that Rust is an elitist
community..

~~~
ThrowawayR2
> _You 'll notice the top rated comment, & majority of comments, agrees with
> their decision to switch to C++. Yet we'll persist that Rust is an elitist
> community._

Having read those comments, many of them can be best characterized as politely
dismissive, e.g. from the top rated comment " _If the author is more
comfortable writing this code in C++ it makes sense to use it, but I feel like
there is a long way to go to make this code "safe" regardless of language. _"
, elsewhere " _I get that this project probably values developer efficiency
over safety or correctness, and probably makes sense in this use case._ ",
etc. Still smells kind of elitist to me.

~~~
bluejekyll
How would you describe the trade-off between safety and the developer
productivity listed as the reason in the article?

The comment seems to just be saying that it’s reasonable for someone to make
this trade off when they are more knowledgeable and familiar with one language
rather than another.

I think your reading quite a bit into that comment to take it as elitist.

~~~
ThrowawayR2
> _I think your reading quite a bit into that comment to take it as elitist._

" _... there is a long way to go to make this code "safe" regardless of
language._" and " _...values developer efficiency over ... correctness ..._ "
are somewhat uncomplimentary additions to their main points, no matter how you
look at it.

------
Barrin92
The first few comments here seem to argue against the article, as do comments
below the post but I am very much with the author.

I strongly disagree with the Rust mentality, and the general mentality of
statically typed languages with extremely prohibitive compile time checks,
that seem to become more common.

Underlying that model seems to be a concept of software like a sort of
renaissance master's marble statue, error free and perfect at time of
production.

The downside that the author points out seem to be often neglected. Constant
interruption and battling with the type system during development, when mental
overhead is a problem. Coupling components by types propagating through
software, increasing time and effort to make changes to your software,
increasing the overhead for others to contribute.

In my opinion the dominant metric to evaluate the usefulness of a language's
type system should be its overall effect on cost, time spent, productivity,
ease of development and capacity to change. Everything else is very subjective
or just an aesthetic concern.

~~~
loup-vaillant
> _The downside that the author points out seem to be often neglected.
> Constant interruption and battling with the type system during development,
> when mental overhead is a problem._

Dunno about Rust specifically, but I have written a little Haskell, and a
significant amount of OCaml. I found that the type system _reduces_ my
cognitive overhead, compared to looser languages like Python or Lua. The
compiler is disciplined, so I don't have to be.

In practice, with few exceptions, when the type system is refusing to compile
something I just _screwed up_ , and I'd better fix my mistake right away. I'd
wager that with few exceptions, when Rust is refusing to compile something,
you are making a mistake that in C++ would have bitten you down the line.

What you call "fighting the type system", I call "fixing bugs".

~~~
mlthoughts2018
I worked professionally in Haskell for a long time and I cannot disagree with
you more. This is always the promise of strict functional languages but in a
business setting where the very nature of what you build has to be arbitrarily
mutable at the whim of competing interests between stakeholders, engineers,
customers, etc., it just doesn’t work.

You end up with the same spaghetti code messes, unexpected runtime errors,
indecipherable crashes, etc. no matter what degree of strict verification
tooling you use. The introduction of lazy evaluation, difficult to debug tail
recursion implications on memory consumption, elevating IO into the type
system, burying details deep in type class patterns, relying on dozens of
special case compiler directives to enhance Haskell... it becomes the same
shit code mess as any other paradigm.

~~~
tome
Interesting. I would be interested to know more details about what you worked
on and with whom. This hasn't been my experience in any of the four jobs I've
used Haskell at.

I don't deny that Haskell leads to spaghetti code messes, unexpected runtime
errors, and indecipherable crashes, but the Java that I've previously worked
with and the Python I currently work with suffer from those to a degree
greater by an order of magnitude.

~~~
mlthoughts2018
It was first for a bank, later for a data analytics start-up, and then also
for an education technology company. I had many skilled functional programmers
on my team too, including a few people who had done work on GHC itself.

I’ve also see code messes in many languages. It’s a business culture problem,
has nothing to do with the language or paradigm.

I’ll greatly dispute with about Python though. It has been a language that
facilitates notably cleaner and more extensible implementations in my
experience. Seen messes in Python too, but absolutely no way it’s “an order of
magnitude” worse. That’s simply ridiculous. The only way that’s happening is
if the programmers are exceptionally bad to the extent that it would not
matter which language they used.

~~~
tome
Very interesting. I suspect we may even have worked for the same bank! I'd
love to discover how we came to such opposing conclusions.

To give you a Python example, it encourages stuff like:

    
    
        def send_email(recipients, contents):
            if type(recipients) == str:
                send_one_email(recipients, contents)
            else:
                for recipient in recipients:
                    send_one_email(recipient, contents)
    

That is a flavour of convenience that people commonly implement in Python.
People like it because it allows both

    
    
        send_email("tome", contents)
    

and

    
    
        send_email(["tome", "mlthoughts2018"], contents)
    

and saves them from typing two square brackets. The problem is when you call

    
    
        send_email(u"tome", contents)
    

It tries to email "t", "o", "m", and "e". This kind of stuff is endemic in
Python. Yes, this did happen in practice in a company I worked for (a company
that was responsible for trading hundreds of millions of dollars of securities
every day). Call the programmers exceptionally bad if you like, but they were
among the brightest minds graduating in my country. It was Python that allowed
them to be sloppy.

~~~
mlthoughts2018
I disagree very much. The Pythonic way would be to do something like
map(send_email, list_of_addresses), and have send_email raise an exception if
not passed precisely a single string, and presumable raise exceptions when you
validate that the email address is of an acceptable format, etc.

It would not be Pythonic to make the function superficially handle different
arities of argument through explicit handling on the list type with
isinstance, precisely because you’d need to handle different meanings of
different types that implement the Iterator Protocol. That’s not something
Python generally encourages, it’s just a mistaken implementation. And
particularly not making careless assumptions when basing branches on
isinstance behavior (for example, you could always encounter custom classes
that have overridden __instancecheck__ or __subclasshook__ special methods.

~~~
tome
It's certainly a poor use of Python's flexibility, but I've seen that kind of
thing written at two completely different companies by completely different,
yet smart, people so I suspect it's prevalent. Haskell does a much better job
of nudging smart people to write good code. Gabriel Gonzalez explained it
better than I could: [http://www.haskellforall.com/2016/04/worst-practices-
should-...](http://www.haskellforall.com/2016/04/worst-practices-should-be-
hard.html)

------
ilovecaching
Three problems with this:

1\. You still have to fight with borrow checking in Rust as in C++, it’s just
not automated. You have to consider moves and copies, borrowed references,
etc. As the author points out, if you’re used to writing C or C++, it’s going
to take a while before responding to the borrow checker is second nature. The
point is that the borrow checker is a computer and doesn’t make mistakes the
same way a human does, and that’s value added not detracted.

2\. Having the benifit of actually having a package manager, Rust is much
easier to download and use dependencies with. That said, I agree with the
general premise of not using Rust if you have an immediate business need and
it’s missing a core library. My issue is that it should be fairly apparent
before you start a project what dependencies you need, so a rewrite back to
C++ seems odd. Also, Rust is an open source ecosystem, and people using it
should feel compelled to consider writing the missing pieces they need for the
benifit of the community. It’s also odd to say that Rust doesn’t have what you
need, it sounds like there are C libraries that already do what you want, and
Rust can wrap C.

3\. If something is written in C and you don’t have time to replace it, just
wrap it in unsafe and make a safe interface over it. Rust is exceedingly good
at interfacing with C, so any library you can use in C can potentially be used
in Rust.

~~~
epage
> As the author points out, if you’re used to writing C or C++, it’s going to
> take a while before responding to the borrow checker is second nature

I see these comments and it feels so foreign to my experience. The borrow
checker was second nature to me because of my C++ experience. These were
things I already had to juggle mentally. On rare occasions, it complained
about something that I could prove was valid but I understood why it couldn't
tell. Usually, when I hit it, it is because I forgot a case and am grateful
for it. I know of at least one optimization I've made that I would never have
bothered with without the borrow checker. It would have been too much bother
for me to reason about everything. Even if I did, it would have been even
worse to maintain.

~~~
pjmlp
Were you trying to write GUI code?

Because of my experience it was also plain sailing, while doing the tutorials
and exercises from the books I bought.

Then I tried to make a GUI application in Gtk-rs and had lots of fun with
event handler callbacks, which are the main reason why Relm was created.

~~~
epage
No, I have not written a GUI in Rust yet. I've been doing libraries and CLIs
so far.

But I find the standard approaches to GUI broken: inheritance and shared
mutable state. i think Rust does a service by highlighting the brittleness of
this pattern via syntax / libraries.

I've not dealt with elm-like GUIs. Probably my natural inclination would be to
use an actor framework. And to be clear, I am speaking from having written
non-trivial GUIs with both GTK and Qt (I miss the Maemo days).

------
jsiepkes
> As the compiler will stop you from borrow checking or something unsafe again
> and again, you are being distracted constantly by focusing on the language
> itself instead of the problem you are solving.

While anyone is obviously free to use any language he or she likes the whole
article comes across to me as someone arguing why they dont want / need
seatbelts: "They constrain my movement, I'm a good driver, etc.".

These are also the same kind of arguments one could make for wanting to use a
weakly typed language instead of a strongly typed language.

Personally I like my types strong and my memory safe...

~~~
fulafel
Strong typing and memory safety are compatible with his wants. It's just that
Rust isn't it. Any of Clojure, F#/C#, Python, or Go might be good here. (Ok,
the nil-punning might make the strong arguable on Clojure's point... but otoh
you have spec)

~~~
adamnemecek
Most of those langauges don’t have the perf of rust or cpp.

~~~
sanxiyn
Most programs don't need C++ performance. Java is usually within factor of two
and usually fast enough.

~~~
adev_
> Most programs don't need C++ performance. Java is usually within factor of
> two and usually fast enough.

Meshing software is a typical program where you need C++ and where Java is a
terrible choice.

By nature, meshing makes you play with millions to billions of very small
object with mutual interactions. A thing that Java GC absolutely hate. Sorry
for the Java fan-boys.

~~~
fulafel
The billion vertex objects might be a nice torture test benchmark for a gc or
malloc implementation, but fortunately things aren't so grim in the real
world:

Performant mesh manipulation code as a rule deals with largish float arrays
(or other similar contiguous layouts, like AoS or SoA or indexed versions
thereof). So there are no per-vertex objects to malloc/free or to track in GC.

In some algorithms, other data structures such as trees, may be used used as
intermediate formats, but there too the options to use malloc/gc allocated
nodes vs alternatives is similar in a GC'd vs a non-GC'd language.

In general, good GC's often outperform malloc/free. Because GC's are amenable
to parallelization in the background, and because malloc/free don't enjoy the
bump-allocator style happy case that is used in generational GC's nursery
objects.

~~~
gmueckl
I never met a GC that can deal with millions of allocations per second while
having several millions of objects in the young generations. Some mesh
processing algorithms have a tendency to get you there very quickly if you do
not employ custom allocators. At this point you already defeated the GC
provided by the language.

~~~
fulafel
You would have to be dealing with a very large number of meshes at once, if
you were churning through millions of vertex and uv arrays per second. I can't
say what you should use in this scneario. But this is a pretty niche scenario!
And you would probably want to focus on parallelism, where C++ again is not
the best.

~~~
adev_
> And you would probably want to focus on parallelism, where C++ again is not
> the best.

Here again, this is wrong.

99% of highly scalable parallel code that run on supercomputers is C++ or
Fortran.

And there is reasons to that, if you want parallelism, you want generally
performance. If you want performance you want control on NUMA, SIMD, cache
locality, etc... and C++ gives you that. Not Java.

~~~
pjmlp
Yet Julia and Chapel are winning hearts of HPC researchers.

Java is not the only language with GC, there are others which offer control
over NUMA, SIMD, cache locality, like .NET Native with C# 7/8, or D as two
possible examples.

~~~
gmueckl
But the GC is frowned upon a lot in the D community. A lot of D programmers
try to make everything they write @nogc.

~~~
pjmlp
A GC in a systems programming language is there as a productivity and safety
mechanism, by no means as the only way of doing 100% of memory allocations.

A vocal sub-community of D programmers argue for @nogc due to GC phobia, as
ex-C++ devs, and a GC implementation found lacking. A situation that might
improve with the recently released GC pluggable API and a new precise tracing
GC.

Many devs that prototype their apps in D without doing premature memory
optimizations, end up realizing that for their use case it actually good
enough.

------
gmueckl
Doing game dev and digital content creation in anything but C++ and some
python is simply a fool's errand. Any decent software in this area needs to
use libraries written in C++ to have even a remote chance of being successful.
These libraries are often written in ways that makes wrapping them for other
languages impossible or at least force the exclusion of some desirable
features in the bindings.

In other words, C++ is utterly entrenched in that space like Fortran is for
HPC.

~~~
est31
Unity, one of the most popular engines out there, is mainly about C# for the
gamedevs.

~~~
gmueckl
And it is a special snowflake because of that. Unity needs to pour a ton of
resources into this to make it viable and competitive. IL2CPP and the Burst
compiler are proof. A company with fewer resources would have to give up on
this approach.

~~~
pjmlp
The same was said about the game developers using Pascal and C instead of
Assembly, followed by game developers using C++ instead of C.

The industry always needs some pioniers willing to do the investment
regardless of the naysayers.

~~~
mewse
Note that the game industry avoided C++ for a long time because those early
C++ compilers produced code which was very large and quite a lot slower than
you'd get from C, so C++ was kind of a non-starter when you were writing code
for the consoles of the day which had slow processors and only a few megabytes
of RAM. You just couldn't afford the overheads of C++ or your competitors
would eat your lunch.

It wasn't about needing a pioneer to show us that we'd been wrong; we _weren
't_ wrong. C++ just wasn't ready for the particular set of requirements that
games imposed, yet. Once the state of C++ compilers began dramatically
improving in the late 90s (by the criteria of optimisation and executable
sizes), most studios moved over to the language pretty quick. Or at least that
was my experience.

~~~
pjmlp
The pioneers were the studios using Watcom C++ on MS-DOS, while others were
still being dragged into Windows with plain old C, while complaining about
losing hardware access until Wing was released.

And the studios that were forced to adopt C++ when the PlayStation SDK
required it.

So nothing speaks against other languages getting over the same kind of
acceptance issues.

------
sanxiyn
"As the compiler will stop you from borrow checking or something unsafe again
and again, you are being distracted constantly by focusing on the language
itself instead of the problem you are solving."

This is very much true while learning, and very much not true once you
finished learning. It would be very concerning indeed if it were otherwise. As
is, it is very concerning for Rust adoption, as this post evidences.

------
JabavuAdams
This is why I gave up on Haskell. Code is still (currently) written by humans.
Sure the code was more terse, but I had to expend more time thinking about
every tiny piece of that terse code. I've been programming for 36 years. Just
as some people think out loud, I think by shaping and reshaping code. Top-down
doesn't work for me, although I know there are other developers for whom it
does. I like to build bottom-up by fooling around with little pieces. I have
no experience with Rust, but fooling around in Haskell just took all the joy
out of programming, for me, while adding frustration.

EDIT> I would rather have better CASE tools / an AI pair-programmer than be
straitjacketed into a top-down correct-first then code way of working.

~~~
sjcoles
Even with a top down approach you can end up with insane type level
machinations or group/category theory that only the best Haskell developer can
decode. Sure it's elegant, but damn near indecipherable.

------
gcc_programmer
I wonder how many of the Rust defenders in this article actually know C++ and
have written a production used Rust system, instead of a side-project on
github, so that they can compare in an informed way? The author certainly has,
but who else has? Step forth priests of Rust! As for me: I use C++ at my job
daily but have never done Rust so I cannot compare. What I do know about is
"memory safety" in C++, and to be honest, the tools available are enough to
make you figure out any issue: gdb/core dumps/valgrind, when combined with
good software practices and unit tests seem to work ok for the rest of us. The
compilers now have sanitizers, and new versions of gcc actually tell you what
your template errors are. It's 2019, not 2005 for C++. Smart pointers are now
available: use them! Finally, if a Rust veteran could let me know: how does
Rust deal with general resource management in the presence of exceptions? Not
everything a program uses is memory: we sometimes need sockets! In C++ using
RAII works well, does the Rust Type System statically error/type check non-
memory resources automatically, or is that out of scope?

~~~
ekidd
> _I wonder how many of the Rust defenders in this article actually know C++
> and have written a production used Rust system, instead of a side-project on
> github, so that they can compare in an informed way? The author certainly
> has, but who else has?_

Hello. :-) I started writing C++ around 1992, and was lead programmer on
various C++ production systems from 2002 until 2011. I worked with valgrind,
unit tests, and boost/std::tr1 C++, but not C++14 or 17.

For the past three years, I've been writing production systems in Rust. Here
are some things I've observed:

\- If your C++ code relies heavily on complicated webs of objects that all
mutate each other (as found in many game and GUI designs), you'll have a bad
time translating that code to Rust. If your C++ code tends to be more
functional, idempotent, or transaction-based, and if it has clear ownership of
objects, then translating to Rust will be much easier. For example, Rust seems
to work better with ECS-based games and React-like GUIs.

\- Rust is significantly weaker than C++ for designs which use integer
template parameters (e.g., "vec<3>") or partial template specialization.

\- Modern C++ allows you get ownership 99% correct, if you throw enough tools
at it. Rust gets ownership 100% correct by default. If you're dealing with
situations where that 1% matters (complex threading, or decoding hostile
data), then it's a much bigger difference than you might think.

\- Not counting Rust IDEs (which are only borderline OK by static language
standards), Rust tooling is _great_. Dependency management is solid, linting
is good, automatic formatting is good, etc.

\- I've been working with nightly and experimental builds of Rust async code,
and I think that Rust will soon give C++ a real run for its money in this
space. Multithreaded async executors (where you mix "green" threads with OS
threads) rely _very_ heavily on precise tracking of who's allowed to mutate
what, which Rust is excellent at.

> _Finally, if a Rust veteran could let me know: how does Rust deal with
> general resource management in the presence of exceptions?_

Rust does not have exceptions. Instead, it uses `Result<T,E>` and the `?`
operator to propagate errors. Ownership and RAII are 100% idiomatic and fully
checked by the same systems as memory management.

~~~
happyweasel
> If your C++ code tends to be more functional, idempotent, >or transaction-
> based, and if it has clear ownership of >objects, then translating to Rust
> will be much easier

That's exactly the kind of c++ code you probably don't have to refactor/move
to another language at all

------
bsder
One thing that I don't see pointed out is that Rust is a _nightmare_ if you
are dependent upon mutable algorithms.

I suspect that mesh generation is very much a mutable algorithm domain and
probably a high impedance mismatch with Rust.

For example, simple things like mapping a struct of three elements to a vector
of three elements were, at one point, very difficult if not impossible in
Rust.

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

~~~
adamnemecek
> On top of my head right now I couldn't think of any famous Rust projects
> which aren't a rewrite.

Wut? Piston, actix, Amazon Firecracker, Alacritty, Xi, the list goes on.

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

~~~
Verdex
My theory is that there are two basic ways of understanding the world around
you and solving problems. Statistically and structurally.

Everyone can do statistical problem solving. At least everyone who can talk.
What you do is that you start making sounds when you're an infant and then you
receive positive or negative feedback. This continues until suddenly you know
how to talk.

Similarly, in industrial chicken raising you need to differentiate between
male and female chicks right after they're born. However, there isn't any
guide to determine the difference. Instead what you do is that you take one
person who knows how to do it and pair them with someone who doesn't know how
to do it. The person who doesn't know how to do it will guess at the sex of
the chick and they will be corrected by the person who does know how to do it.
After enough time you have two people who know how to do it.

Sounding familiar yet?

Most people learn programming languages in a statistical fashion. They try a
bunch of stuff and get positive or negative results (compile fails, runtime
errors, etc). However, just like determining whether a chick is a male or
female in the chicken raising industry, nobody can really give you the
specification of how to program. All they can do is tell you that you are
doing it wrong or doing it right for any given scenario.

Now of course there are problems with the statistical method (also benefits,
but we're interested in failure right now). 1) You can't say why you're right
[in order to do that you have to sit down an analyze what you've been doing in
a structural fashion]. 2) The only teaching method you know involves telling
people they're wrong when your gut tells you they're wrong. 3) You'll have a
terrible intuition for any situation that only causes a failure after a period
of time or some of the time (think undefined behavior in C).

If you have only learned programming statistically and haven't sat down and
reflected on what the structure of what you're doing actually is, then when
you are faced with information that is contrary to what you know your natural
reaction is going to be to listen to your gut (even if your gut is wrong) and
provide the same negative response that you got when you were first learning.

Additionally, the only "reasons" that you'll be able to give are paper thin
metaphors and thought terminating cliches that don't stand up to even the
smallest amount of examination.

The end result? You get a bunch of programmers that freak out every time a new
language comes out.

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

~~~
pjmlp
Just like Objective-C, Swift is mostly a thing on Apple platforms.

------
fooker
Yeah, Rust seems to have an ergonomics problem and the only response we are
seeing is "you're holding it wrong".

I would rather work on interesting projects than use interesting tools for
not-so-interesting projects. So far, for things I am interested in, C++ seems
to be the tool of choice.

~~~
steveklabnik
> the only response we are seeing is "you're holding it wrong".

We had such a huge push last year for ergonomics that there's a segment of the
community that's still upset about it. We're _very_ interested in improving
them; if you have good ideas about it, you'll get heard out.

~~~
fooker
Can you point me to a document listing the changes from this effort?

~~~
steveklabnik
Probably the closest is [https://blog.rust-lang.org/2017/03/02/lang-
ergonomics.html](https://blog.rust-lang.org/2017/03/02/lang-ergonomics.html),
which laid out the plans to do so. That being said, there wasn’t a single real
document I can point you to: it was a label attached to a number of RFCs, and
not really tracked as one thing. Some stuff that ended up landing under this
banner was:

Non-lexical lifetimes

“Match ergonomics”

Implied lifetime bounds

The anonymous lifetime

The question mark operator

Async/await (this one is still in progress)

The removal of “extern crate”

... and some other things I’m sure I’ve forgotten. I also said “last year” but
that blog post is from 2017, and that’s because it took a long time for RFCs
to be created, accepted, implemented, and stabilized; a lot of this stuff
landed in the latter half of last year, though some before then too.

------
adamnemecek
"As the compiler will stop you from borrow checking or something unsafe again
and again, you are being distracted constantly by focusing on the language
itself instead of the problem you are solving. I know the friction is greater
because I am still a Rust learner, not a veteran, but I think this experience
stops a lot of new comers, speaking as someone who already conquered the
uncomfortable syntax of Rust, coming from a C/C++ background."

To be honest, this article seems somewhat ingenuous. The author wasn't
comfortable with Rust, and it seems like he missed the point of the borrow
checker. This article will now be circulated whenever Rust is discussed.

Here is a good article that arrives at the opposite conclusion:
[https://kyren.github.io/2018/09/14/rustconf-
talk.html](https://kyren.github.io/2018/09/14/rustconf-talk.html)

I've been writing Rust full time for the last month and a half or so and the
language is a joy to use. The main difference is that the code I write feels
very sturdy and permanent. I've heard other people say the same thing.

~~~
nraynaud
XML didn't work? use more XML. Everybody has a breaking point, and they
reached theirs.

I have been studying rust for embedded since January and I am not really
impressed by what I have seen. I am mostly hacking around the deficiencies of
the libraries, the crazy organisation of the stack, and the issues with the
community.

I am sticking with rust for now because I feel like there is a bandwagon and
there might eventually be money in it, but I am certainly not a convert.

~~~
adamnemecek
> XML didn't work? use more XML. Everybody has a breaking point, and they
> reached theirs.

This argument could be applied to anything.

What's crazy about Rust stack organization? What are the issues with the
community?

~~~
sanxiyn
There are lots of issues with using Rust for embedded development, most of
them long standing, which are often felt to be neglected, and some suspicion
that progress is slow because it is not the highest priority for decision-
making people. [https://github.com/rust-
embedded/wg/issues/64](https://github.com/rust-embedded/wg/issues/64) details
some of these technical issues. Personally issues with Cargo are the most
pressing, and math/compiler_builtins is very annoying.

------
peatmoss
As someone who never learned C++, I keep hearing about how today’s C++ is much
better than the C++ of a few years ago. Can anyone recommend a resource for
learning some C++ basics using today’s modern C++?

------
Vogtinator
Rust is still completely unusable as you can't use dynamic linking as there's
no stable ABI.

~~~
fxfan
"completely unusable"

You forgot to tell Microsoft (biggest software seller on earth)and they
decided to use it in actix

~~~
pjmlp
And are proposing it alongside C# and Core Guidelines compliant C++ for new
systems software.

~~~
adamnemecek
Do you have a link?

~~~
pjmlp
Sure. Check the presentation slides.

[https://github.com/Microsoft/MSRC-Security-
Research/tree/mas...](https://github.com/Microsoft/MSRC-Security-
Research/tree/master/presentations/2019_02_BlueHatIL)

------
alexnewman
I was a fan of rust when it first started. i wrote some consensus algorithms
and metrics packages in rust. i also hosted a rust podcast. I now believe Rust
has failed. Mostly because of the arrogance of organizations like the rust
community and the inability to form stronger relationships with companies like
apple. I now think that people should focus on swift and soon it will have the
same native code support and a borrow checker. I think we all learned a lot
but it’s time to realize people still don’t understand why not go and swift. C
programmers continue to prefer c and more and more people are shifting back
from rust to c++. rust will never provide enough

