One Of AMD's Leading LLVM Compiler Experts Jumped Ship To Unity

[tuxd3v]

"Performance beyond C++"
Unless they're talking about really shitty, over-engineered code that does "OOP for the sake of OOP" or about incredibly rare edge-cases, I see the idea that C# could outperform C++ as hyperbole.

Some history first..
C# is a Java Derivative..created by the Same guy who created or envisioned Java, James Gosling.. another Traitor like Miguel de Icaza..

Past..
Java was licensed, *unfortunately*, for free in Windows( after Microsoft say at the time, they will *not* use such "horror thing"... and Sun Microsystems believed that, and licensed Java for free in Windows.. *Ingenuity* .. ), and this clause make Oracle loose the Case in MS Windows use of Java Technology in Court, because it was licensed for free, so *no* Multi-billion dollar penalty was applied..

Now..
C# uses a lot of Java Technology behind, and it was *NOT* Licensed for free in any other platform..
We could say that C# is Illegal in Linux/Others, and Oracle could charge Microsoft for that.. C# in Linux is a "poisoned apple"

[F.Ultra]

I've found that when your workplace doesn't accommodate you and impedes your workflow, you have to do things your own way (of course, as long as it doesn't negatively impact everyone else). All that matters is finding a way to bridge your method with the internally preferred/suggested way. If he's really working at 10% his potential, I think the amount of hours it takes to personalize his workflow to increase his potential would've been well worth it. If the company tells him to stop doing that, well, maybe it is best he leave.
Where I work, I'm the only desktop user running Linux. I also don't use almost any of the same tools anyone else does. But, when I need to interact with someone or get the "real user experience", I'll divert my workflow to accommodate them. Sometimes that means running something in Wine or a VM, if push comes to shove. It's a temporary inconvenience that allows my overall workflow to be sped up.
As long as you understand how the company wants things done, it's not hard to do things your own way without interfering or holding them back.

I may be mistaken, but I think Apple heavily pushes for C# for iOS. At least they used to.

You are thinking about Objective-C that was the Apple choice #1 before Swift.

[F.Ultra]

One should not store binary files in SCM! Binary files are meant to be stored in artifact repository.

If your SCM sucks ass for storing binary files then yes that is true. But if it doesn't then storing the binary files in the same repo makes for a really streamlined process.

[bridgman]

I just hope that you have healthy internal discussions over which rules work and which don't and have a process to revise them if needed. At least he wrote that he felt heavily restricted in his productivity due to all of this and that should ring some alarm bells. But of course I can imagine that consensus is hard to achieve, especially across many teams with different priorities.

Yes, but those discussions are generally split between the open and closed source groups since our working environments are so different**, although there is some cross-pollination between the groups.

** open source teams are upstream-based with short periods of internal-only work for new unannounced GPUs while closed-source teams are internal only with occasional open source releases like AMDVLK

[smitty3268]

Is it me or do others think that C# is a dead end? I certainly don’t hear much about it in the forums I read. I don’t see a lot of demand either for programmers.

Not dead, it's just not that used in open source or linux which I'm guessing is where your interests lie.

https://insights.stackoverflow.com/s...019#technology

That places it 7th, behind only Python and Java in terms of competitor languages, and ahead of C++ and C and on a different level entirely than more minor languages like Go, Rust, Swift, etc.

[F.Ultra]

Not dead, it's just not that used in open source or linux which I'm guessing is where your interests lie.

https://insights.stackoverflow.com/s...019#technology

That places it 7th, behind only Python and Java in terms of competitor languages, and ahead of C++ and C and on a different level entirely than more minor languages like Go, Rust, Swift, etc.

It's also still heavily used by Windows devs, I think that every single WIndows dev that use our softwares and services programs in c#.

[xxmitsu]

If your SCM sucks ass for storing binary files then yes that is true. But if it doesn't then storing the binary files in the same repo makes for a really streamlined process.

Is not like that. There are some good/established industry practices already. One implementing configuration management is already familiar with this. Scm is for everything that can be represented as code nowdays. Be it infrastructure as code in terms of servers, networking, CI pipelines, etc. This is to benefit from the well known practices that are already appied to code. Like auditing, tracking, code review/approvals, separation of concerns, etc.

This code is used to generate binary files or so called artefacts. Be it in form of rpm, docker images, or compiled binaries. Those will also be versioned, usually using semantic versioning and with conventions and metadata to know the exact commit that generated that binary. After this, the binaries are deployed and validated in each environment as soon as they pass various quality gates. And if everything is fine, they will be considered releases.

So, bottom line is that soring binaries in SCM is highly discouraged, and I see no real reason for why a person would want to do that.

PS: I am talking from experience, I've designed and wrote from CI/CD pipelines to various infra as code using automation tools.

[bridgman]

So, bottom line is that soring binaries in SCM is highly discouraged, and I see no real reason for why a person would want to do that.

That might be a bit too much of a blanket statement.

Agree that storing binary builds in the same CM system as the source code is not usually a good idea, but are you saying that documentation for the source code should also be kept outside the tree and not be coordinated with the evolving source code ?

[xxmitsu]

I was referring to the binaries generated from code.

I think like that the answer is the classical 'it depends'. But with regards to the documentation, what we usually prefer to do is write it using markdown (so it's versioned together with code, and still text format) and the git web interface will render it nicely.

In general, we strive to write the code in such way that the chosen naming is related to the purpose of the variable or function. Because comments can drift from actual implementation if someone forgots to update the comment after modifying implementation. But if some variable has a name that implies something and someone will store something else in it, chances are that that var will be renamed to reflect its new purpose. And if not, is more obvious during code reviews.
We usually add comments where decision is not so obvious, or explaining some algorithm, for posterity if someone ask something during code review and we come to the conclusion that it was not so obvious, etc.

If absolutelly necessary, functions docs can be generated from annotations/comments. APIs with swagger, release notes from git history, etc.

[F.Ultra]

Is not like that. There are some good/established industry practices already. One implementing configuration management is already familiar with this. Scm is for everything that can be represented as code nowdays. Be it infrastructure as code in terms of servers, networking, CI pipelines, etc. This is to benefit from the well known practices that are already appied to code. Like auditing, tracking, code review/approvals, separation of concerns, etc.

This code is used to generate binary files or so called artefacts. Be it in form of rpm, docker images, or compiled binaries. Those will also be versioned, usually using semantic versioning and with conventions and metadata to know the exact commit that generated that binary. After this, the binaries are deployed and validated in each environment as soon as they pass various quality gates. And if everything is fine, they will be considered releases.

So, bottom line is that soring binaries in SCM is highly discouraged, and I see no real reason for why a person would want to do that.

PS: I am talking from experience, I've designed and wrote from CI/CD pipelines to various infra as code using automation tools.

I think that you are used to work on projects that involve quite a large team?!