/fgg/

Go on, now is the time to argument yourself.

Just something I found on DDG with "lol no generics"

>argument yourself
Really? Anyway.
>Unicode
>basically opaque data due to sheer complexity, good luck completely supporting it
>no, we can't add those often used codepoints, our corporate shilled emojis and taco pictures are fine, though
>no concrete encoding, so shitton of encodings pop up in uncontrolled manner
>shit tier spacing defintions for monospaced fonts

>Unix
>doomed modern desktop computing, all modern desktop OSes are more or less improved or "improved" copies
>proprietary certificate
>worse-is-better (really shit-is-fine, though)
>comes with shit tier ABI, OS APIs, shit tier language only as a plot to create a gigantic inner-system of poorly created scripting languages due to ego boost of "inventing" a poor form of IPC
>config is a textfile mentallity, forgetting that there is no such thing as "just text" (there never was, btw)

I agree with some points. Especially about emojis in unicode. This should die.

Why do you say that Unix has a shit ABI and OS API?

>Why do you say that Unix has a shit ABI
It more or less boils down to being based on C and all that this implies, like compilation model, runtime model, library loading restrictions.
> and OS API?
That's down to details. For example, async IO is a mess, in particular if you need performance. And every variant of POSIX-like OS comes with its own cancer. On Linux, a symptom is that systemd has won.

C is pretty good, and I wouldn't call an ABI based on C bad. What would be a good alternative?

>C is pretty good
By the time C was designed, people already knew
- proper symbolic inclusion
- that syntax doesn't has to be retarded
- better metaprogramming features
- that gets() was a retarded idea
And probably much more...
>and I wouldn't call an ABI based on C bad
your loss, have fun funneling bindings through extremely limited means
>What would be a good alternative?
We will never know, thanks to Unix. That said, take a look at languages that employ their own dynamic linking system through packages, modules and assemblies.

Both examples are stupid. D and Go. Both smell of bad code and shit abstractions.

The only real thing I want from Go is compile-time code generation or similar features.

Also, the author comes to the same realization everyone else using Go has after using it a bit.

>I’ve written before about Go and how I was initially pretty unimpressed with the over simplicity and parenting that is forced upon you. However, over time I’ve come to enjoy using Go to the point that every new project I tackle, Go is the first language I consider. In my opinion, it’s unsurpassed for cross-platform support, tooling and libraries. The language itself is simple and straightforward and the concurrency support is second to none. It really is an absolute joy to create concurrent programs in such a simple, robust way. I, like many people, just enjoy using Go.

It doesn't really hit you until you realize you're shitting out code like there's no tomorrow with almost zero effort, without the verbosity and need for project management like e.g Java has.

Go isn't enterprise ready but it's getting there.

Attached: 1535393569899.png (750x1334, 439K)

Go is just so fucking comfy. sure writing if err != nil all the time gets tiresome, but checked exceptions and having your whole program be wrapped in try catch blocks everywhere is much worse. Oh yeah and oopsie woopsie when you fuck up your deallocation with C++ exceptions and leak memory because the stack unwound without freeing the resource. defer is pretty nice.

Looking at go code reminds me of looking at shitty Microsoft COM code
err != nil is the same as !FAILED(hr)

>Go is just so fucking comfy.
Shit famalam. Couldn't agree more.

Attached: go comfy.png (409x409, 139K)