C and Go are the best languages ever invented

C and Go are the best languages ever invented
if you are using any other you are wasting time

Other urls found in this thread:

soton.mpeforth.com/flag/jfar/vol5/no4/article2.pdf
danluu.com/assembly-intrinsics/
intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf
developer.amd.com/resources/developer-guides-manuals/
twitter.com/SFWRedditImages

I wonder where Haskell is in that chart.

I'm liking Haskell.

java cuck detected

>C++ more fun than C

>tfw you cant into reading

>JS faster than Perl
really?

...

Thank you based Ken Thompson.

>ruby
>perl
>js
>fucking js
>fun to write in

kek

Yes. Thanks to Google.

They must mean with a standalone interpreter because that shit is slower as mollasses in a browser.

Javascript running on V8 is fast. Love it or hate it it's not slow.

The placement there is wrong. They all fit below a negative slope line. Because the implication the graph makes is platform abstraction+required detail awareness vs performance really.
Also what does it mean placing C++ so close to C? It's incredibly difficult to use C++ features without major performance penalties. Even things like variadic templates that people tend to think of as 'free' usually kills the compilers ability to optimize your code.
Dealing with these issues is way less fun than dealing with any C issues.
And if we're just writing C-like code in C++ the fun should be way lower. Bevause you have to deal with a team who doesn't get it.

>it's not slow
It's a couple thousand times slower than an equivalent C program usually.
But yeah in the grand scheme of things I agree it's not 'slow'. There's some horrible languages out there.

>Muh bottlenecks
For the overwhelming majority of tasks, saving hours of developer time is far more valuable than shaving 50 ms of off execution time. You are working in a job that doesn't pay like shit, right?

>JavaScript
>fun for humans

Fixed

>Go
AH HAHAHAHAHAHAHAHHAHAHAHAHA

Sounds accurate.

C is going to be faster than most any other language, comparing a language to C in raw speed is pointless.

C are fun for humans, as well, as assembly.
What is not fun - is guessing how it works

Um. He read it correctly.

Assembly is obsolete. I'd rather use Forth than Assembly every time.

>tfw they don't know Haskell

C isn't going to make you money.

C# and Java will make you money.

C# vs Java, C# is the more developed language.

Since those two are the only two money making languages, I'll take C#.

>C# and Java will make you money.
>he thinks everyone is a paid prostitute
Good code > money
most anonoymous coders are poor and they make our lives better
C>Assembly>Go>Wasting time on C#meme> everything else

>Assembly is obsolete
Enjoy NEVER taking full advantage of SIMD. Intrinsics don't cut it, senpai.

Call a recruiter and tell them you want a job writing C or assembly or Go. You'll be waiting a while.

Tell them you know C# or Java and you're looking at $100k/yr at a minimum.

Best language is money making language.

oh you mean like this?
soton.mpeforth.com/flag/jfar/vol5/no4/article2.pdf

>pointless
No. If you care about efficiency you choose your language according to that. If you don't you don't consider efficiency. It's that simple. It's not meaningful to decide your requirements for efficiency in any other way because the actual estimates for how many elements you can process per unit time is complex even when you've constrained yourself to one language. To make this call when you have multiple languages to consider is harder than your actual problem. Because deciding this means understanding the performance implications beyond algorithmic complexity for each individual language. Which implies you know the full implementation.

If you've got a resource constraint that's weak enough to be beyond a factor of 10 times slower than C (or whatever language you're considering actually) you clearly don't actually care enough to choose your main language based on this. Should you find yourself running short you start using C-FFI if you're late in development or change language if you're early.

It's a pointless deliberation for a lot of software. And where you do care you usually have things that aren't upper bounded. You have other costs based on the problem. Like how you could run less servers if they're more efficient.
My company was looking for a C programmer with Linux experience for a year. Sure we're not in an IT capital but we're not some village out in nowhere.
Of course we weren't looking for a junior. So that's
>C# & Java 100k minimum
To measure number of job positions in salary is stupid. And to measure salary without regard for where you live is even more stupid.
I'm guessing you're stupid user.
>intrinsics don't cut it
Have any good examples? Usually they do quite well.

>TFW you actually like ASM.
Whats wrong with me?

It's simple and the tasks you do are suited to the environment.
What's not to like?
Consider JS as an opposite. People force it into every bad situation. It's also got complicated rules that strike you even when writing simple programs (implicit conversions come to mind, but there's lists for these things).
Nothing really bad about asm.

>Usually they do quite well.
"quite well" =/= optimal
Particularly in the strange way the compiler will choose to spill registers and rewrite registers that could still be hot. I've been looking at compiler output of my intrinsics and tweaking the C code so many times until I realized I should just fucking do it in assembly myself.

danluu.com/assembly-intrinsics/

I'll have a read.
Thanks.

>nothing really bad about ASM
Except it's macro assembler without any good macros. Assembler is like programming in notepad instead of a good IDE. Might as well write your application in a hex editor as machine code.

I think it's working so close to the metal.
I don't particularly like dealing with odd registers, but I love being able to use all of the hardware features.

I'm on a project where we have a microcontroller operating most of the peripherals for the main computer, and I love being able to just write a bit of inline ASM that lets the hardware's specialized functions do the heavy lifting, compared to my teammates who implement everything in C.

I'm not sure if I'd want to write an entire program in ASM, but I have lots of fun with the functions that I've written in ASM.

You should also dip in to this optimization manual. Don't let the number of pages scare you, you only really want to read small bits of it related to what you're doing. The most helpful are the micro-architectures and the layout of the execution engine for a particular micro-architecture of focus. Personally, I'll look at Haswell when coding AVX2.

intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf

Also x86 is CISC so "latency" and "throughput" are a thing.

Bullshit. I think I'd rather kill myself than write x86 machine code directly.

Yea, stupid to measure salary and job positions. I suppose we could use Sup Forums merit points instead?

Fact is that C# and Java pay. Nothing else at the moment is going to pay as well. Wherever your shitty town is where you live, chances are that C# and Java pay.

Nobody cares about academia; nobody cares about the shit-tier on-ramp of languages like C and Go. People care about results and C# and Java deliver those results. I've never once heard a discussion about CQRS among C devs; never once heard any real architectural discussions among them.

Believing C and Go are the way forward is a child-like fascination with things that will never be. My guess is that you're a teenager whose first and only language compiles with gcc. Grow up and try to make money on that. PROTIP: you'll still be driving your ford fiesta.

That guide isn't designed to teach optimization tricks that dick over AMD, is it?

its fun, nigga.

>fallen for the weeb's meme of AMD the 'underdog'.
Optimization for a given architecture is up to you, the developer. Take responsibility, retard.

News just in: Intel and AMD have slight variations in their processor designs

Assembly is fun. Writing x86 machine code directly is just retarded.

I'll take that as a yes.

>golang
>using a language created by google bonnet

No you fucking retard. Intel has tried to fuck AMD and the industry historically. This is not one of them. It's just that they have different micro-architectures holy FUCK it's not malicious you fucking retard.

...

>Reading Nissan car manual
>wtf nothing written here applies to Chevy

>posting about low level architecture and coding in assembly
>"This isn't going to be specific to a given CPU model is it guize?!"

And why should it?
A fucking ISA is standardized. If I'm reading the section on SSE3, then I'd expect it to apply to all CPUs with SSE3.

The link you posted before was a good read. It's a bit old, 2014. Wonder how the compilers fare today. For clang especially as they've really evolved quite a bit.

Of course a programmer must be aware of the cost of abstraction. Intrinsics (where appropriate) are at least a step above writing simple C code.
>manual
I've seen that manual before but I haven't paid that much attention to it when writing code.

Mate you can have a standard ISA all you want but there can still be wild differences in performance of each and every execution engine that implements it

The only thing standardized about x86 is literally the x86 instruction set. The way each CPU executes those instructions internally is wholly proprietary. Therefore, optimization for each CPU model is bound to differ.

>I'd expect it to apply to all CPUs with SSE3.
Why would you expect that with an INTEL architecture guide?
Go to developer.amd.com/resources/developer-guides-manuals/ maybe.

The good news:
You can just pick a micro-architecture, e.g., Haswell, or Bulldozer, and anything newer is pretty much the same thing but with more execution ports and abilities per port.

They might be a little better, but 1) they still don't optimize for a particular micro-architecture, and 2) they aren't able to make reasonable decisions as to how to fill registers based on hotness and execution port dispatch

Welcome to low level optimization. Everything matters. A lot of what you learn will apply everywhere. Your knowledge level is what determines how well you can decide where it applies. Even if you learn everything available there's still other shit happening in black boxes called trade secrets so you'll have to experiment to better characterize those boxes. You still probably won't figure out what's in them.

Remember not to optimize prematurely. No matter how well you optimize a section of your code that is responsible for .1% of your run time, you'll never make it past a .1% improvement.

i fail to see how go's features outweigh its disgusting design