So long and goodnight

esr.ibiblio.org/?p=7711

>one of the most prolific figures in FOSS is switching from C to Go/Rust

1972-2017

Press F to pay respects

If you are not here to pay respects, you must explain in detail why you are continuing to use a deprecated language.

Other urls found in this thread:

gobyexample.com/collection-functions
twitter.com/AnonBabble

it was a good ride but it's time to move forward

C has already been dead, only Sup Forums neckbeards pretend that it hasn't been
>I can’t clearly remember when I stopped doing so. And…looking back, I don’t think it was in this century.

>Go
>challenging C

>putting Rust and Go in the same bucket

This meme needs to stop.

>i haven't used c in a decade, dunno lol, anyway it's dead
whatever. can't take these kind of people serious. you can't remember the last time you wrote in c? that's like saying you can't remember the last time you spoke in x language.
>dunno, i don't casually speak english it's mostly for work. at home we're all speaking spanish lol

Did you even read the post, retard?
He clearly says that he uses C on a weekly basis.

Is there any UNIX-era pioneer that didn't become a irrelevant hack with shitty and ill-advised ideas?


Rob Pike? Eric S. Raymond, even Brian Kernighan has been caught doing gender welfare shit by sponsoring some college girl's CS 4-year capstone project which was some trivial shit that could finished in a week.

>caught doing gender welfare shit by sponsoring some college girl's CS 4-year capstone project which was some trivial shit that could finished in a week.

can you post an example of this?

This, Rust will never be in the same league as Go.

This, you could remove 90% of Rust's features and it would still be several leagues above Go.

>python
kill me

They're the only 2 languages invented this millennium that have any kind of corporate backing and have a clear use case, they're also a pain in the ass to write in, of course people will lump them together.

that is literally the example you fucking retard

go has generally replaced c and everything else for me. one exception is tcl for prototyping GUIs; go needs to hurry the fuck up and offer a complete and stable UI package, one that doesn't render to html either.

rust's main reason for existence was that it was a compiled language with CSP concurrency built into the syntax. now that they've stupidly removed that and then added a fucking ton of pointless C++, D and haskell features, we can leave rust in the dustbin.

>t. never used Go

Why are they a pain in the ass to write in? Not contesting, actually interested

I can't believe you idiots take ESR seriously. All this means is that he's found a new trend he can parasitically attach himself to.

yeah but can you post a link to a project report or something like that
you fucking retard

>they're also a pain in the ass to write in
Says the fag lamenting the fact ESR isn't going to be reaching for C as much anymore.

MMMMUH GENERICS

literally who?

your worst nightmare

>muh duck-typed interfaces
>muh broken package manager
>muh C-style error handling
>muh array and hash table is all you'll ever need
>muh use for loops for everything, functional programming is too hard

confirmed for never having written a single line of go. embarrassing.

you'll have a road-to-damascus moment sooner or later, enjoy

go looks bad, and now that eric s raymond has signaled an interest in it it's about to get worse. rip

I read the spec.
I tried using it anyway.
I didn't like it for the aforementioned reasons.
I hope Go 2.0 will be usable.

>>muh duck-typed interfaces
interfaces are 100% compile time unless you're using the empty interface, which people normally only do to shitpost about generics
>>muh broken package manager
if you're going to whine about go-get having no versioning (which was never its purpose), use git to clone the repository.
>>muh C-style error handling
nothing c-style about the error type, and you'll be pleased to hear they're going to add some short-circuit syntactic sugar for error checking to go2
>>muh array and hash table is all you'll ever need
learn to write code. also there is a standard container package. also untold amounts of data structures implemented and posted on github.
>>muh use for loops for everything, functional programming is too hard
what are you on about? go has first-class functions, closures, and whatever else. are you just bitter that tail call elimination is not mandatory in the spec?

yes i don't think you've used go. it's always the loudest gobshites who haven't used it. go write a blustery blog post, why don't you?

>interfaces are 100% compile time unless you're using the empty interface, which people normally only do to shitpost about generics
I might have used the wrong term. The issue with Go's interfaces is that they only check whether a method with the same name exists.
C++ has the same problem but even worse.

>use git to clone the repository
Now I need my own clone of every repo just to make sure that nothing breaks the next time I pull the library code or use some third-party service like gopkg.in instead of the package manager doing it for me.
>which was never its purpose
Well it should've been.

>nothing c-style about the error type
if err != nil { return nil, err } reeks of C, the only difference is that the actual value is not returned via a pointer.
>you'll be pleased to hear they're going to add some short-circuit syntactic sugar for error checking to go2
Great. Until then Go is going to continue to suck in this aspect.

>untold amounts of data structures implemented and posted on github.
Implemented using interface{}
We Java 4 now.
Oh and now your interfaces are no longer "100% compile time"

>go has first-class functions, closures, and whatever else
Again, you need interface{} and assertions.
Writing a for loop over and over again (maybe wrapping them up into functions for every data type) is the recommended way of working with collections in Go.
All of these examples are one-liners in most other languages gobyexample.com/collection-functions

>go write a blustery blog post
There's really no need to, there's enough of those already.

>The issue with Go's interfaces is that they only check whether a method with the same name exists.
same signature, you mean. that is how interfaces work.
>Now I need my own clone of every repo just to make sure that nothing breaks
spastic
>reeks of C
and everything else reeks of C++ or ML
>Implemented using interface{}
which is fine; you've got your generics!
>Oh and now your interfaces are no longer "100% compile time"
don't be surprised that reflection is reflection
>Again, you need interface{} and assertions.
what? we're talking about functions now.
>Writing a for loop over and over again (maybe wrapping them up into functions for every data type) is the recommended way of working with collections in Go.
yeah if you want to operate on a set of things with a first-class function you'll have to write code that operates on a set of things with a first-class function. sorry your pet haskell feature didn't make it into the language.

>that is how interfaces work
That is how interfaces in some languages work. In other languages you need to explicitly declare that your type implements it.
Just because your function happens to have the same name and signature doesn't mean that it can be used in the same context.

>which is fine; you've got your generics!
That's not generics. Generics can be typechecked at compile-time.

>don't be surprised that reflection is reflection
Generics don't require reflection.

>>Again, you need interface{} and assertions.
>what? we're talking about functions now.
You need interface{} to implement those functions.

>yeah if you want to operate on a set of things with a first-class function you'll have to write code that operates on a set of things with a first-class function
And if you want to do the exact same operation (e.g. filter) on a set of different things then you have to write the exact same function again but with different types.
Unless you use interface{}, which brings us back to the points already discussed.