[j-nsp] MX104 capabilities question

Saku Ytti saku at ytti.fi
Thu Jul 7 07:11:37 EDT 2016


On 7 July 2016 at 13:22, Gavin Henry <ghenry at suretec.co.uk> wrote:

Hey,

> Any developer can introduce bugs irrelevant of the language but some
> languages just have bugs that you
> would need to know C to fix. At Arista's level they are using C as
> everything touches C at some point be it
> bootstrapping the mini-any-lang to get to the state of compiling a
> language implementation from source.

There are actually many languages with no runtime, which you can write
lowest level at possible. It's entirely possible to write all the low
level stuff in C++ or better yet Rust, you'll get sparser version of
the language, but it can be done.

> I would say using C in the right place within a company puts them at a
> *massive* advantage.

In comparison to what language, all languages? Why? C++ and Rust are
arguably more complicated languages, and it will take more time to
learn them. But we're talking about senior developers anyhow, so it's
an advantage that some experience is needed before you appear
proficient. And after you've paid the complexity tax, there are
dividends.

> Some interesting reading:

> Again, very true. Further proof that the language is irrelevant and
> the "right tool for the job". The issue being
> algorithms, architecture of said toolset/project need to be understood
> clearly. The language is the second bit.
> Is that level still being taught or is it learned on the job?

Aren't these mutually exclusive 'language is irrelevant' and 'right
tool for the job', I am arguing C is not the right tool for the job,
when talking about vast majority of things written in C. Routing stack
is way too high level for C.
Kernel is probably fine in C, but even for that, I'd rather consider Rust today.

I think good portion of IOS and RPD are written by people who learned
C on the job. They didn't enter the company as developer, but as they
were dealing with customer issues and had access to code base, they
started hacking on it. How many years until they realised how things
should have been written, 5? 10?

> Test, test and test as you know. It's very easy to write crap code,
> full stop :-)

It is considerably harder to write bad code higher level languages
than in C. Especially in garbage collected ones, which are perfectly
acceptable for majority of use-cases, when it does not matter if you
pause for few milliseconds now and then.
I'm not making absolute statements, I'm trying say there is some
probability of introducing a bug per feature or line of code written,
and I don't think this probability is constant and I believe this
probability is amongst highest in C.

> There in lies the whole point which I do agree with. Finding good or
> great C programmers is hard. Lots of C++.

And if you can't find them for the salary which makes economically
sense, then you are in disadvantage compared to company who is using
tools to which they can find them.

-- 
  ++ytti


More information about the juniper-nsp mailing list