[j-nsp] MX104 capabilities question

[Gavin Henry]

On 7 July 2016 at 12:11, Saku Ytti <saku at ytti.fi> wrote:
> 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'm not fluent in all programming languages at all, but I'd be interested in
ready up on those that don't use C to get their main binaries to a certain point
to compile the rest to get the final main binary ready. For example
Perl's miniperl
etc.

>> 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?

The "in the right place" is the strong emphasis here, which goes back
to the right
tool for the right job.

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

Agreed. It's Senior devs that will have the confidence to say out loud
that "this
is better done in X language".

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

"Vast majority of things written in C"? For example?

I would say things as critical as a routing stack would need C and that's
why most are written in C. But again, this comes down to your other points about
inhouse skillset vs "the right tool for the job".

If a routing stack can be written in X language and supported by X
company and it's "fast enough" or "good enough", then that's what it
should be written in as X language is then the right tool for the job.

> Kernel is probably fine in C, but even for that, I'd rather consider Rust today.

Understood.

> 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?

No idea how their ecosystems work.

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

For our comments we need to define "bad code". Is that not using the write
techniques or writing slow code. Test and benchmark when it's needed.

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

I would say it depends. If that code base has it's own memory
management routines
and pointer routines it may be safe to add lines of code where errors
get caught.

Software crashes with any language as us humans write it:

https://github.com/search?q=This+should+never+happen&type=Code&utf8=%E2%9C%93

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

And said tools will be the "right tool for the job".

-- 
Kind Regards,

Gavin Henry.

Winner of the Best Business ITSP (Medium Enterprise) 2016!
http://www.surevoip.co.uk/2016-best-provider