Holy moly, you are right! Wow, didn’t look at the year before 😄 However, it is also kind of sad, because would we have changed our developing ways, then I would have known his talk to be out of date, if that makes sense 🤔🙈
This talk is from 2010 and it proves the things he is talking about. If you see newer programming languages like Swift, Kotlin or ES6; they are all converging to the same language. Still, the software world suffers from those old-aged problems: error prone code, readability and sharing of code, programmer productivity, compilation speed etc. If those languages are very good, why they can't solve for those who write them? After a long time; People will realise this and Go will be very successful because of its simplicity. There is no doubt about it.
his analysis seems right on to me. Language designers are like the people who make James Bonds weapons. Sometimes they make programmers cool and useful stuff and sometimes it's overly complex crap. At least when things are open source, we get some say in it, which is how it should be.
I agree with Rob's general view on patterns. It's brief so he's probably got a lot more to add to that given time, but overall a pattern does indeed highlight a weakness in the language. If something can be so predictably designed/written often enough to have a name, then it should be inherent within the language. The other (main) issue I personally have with patterns is that it gives the impression that there's a stock solution for every possible problem and all a coder needs to do is find the right pattern to apply. From my experience this is usually a result of education where being a good student in programming correlates with being able to regurgitate the most applicable pattern given an exam-type scenario. Over the years in dev (and interviewing coders has been part of that), I've come to the conclusion that patterns remove what is actually the most important aspect of logic/coding - the "grey area" as I call it. A pattern offers the idea that every "real-world" scenario can be resolved by using a method which 100% resolves it and it's just about applying the right pattern. This makes patterns ideal for someone who can "fill in forms" as Rob elegantly puts it. Why doesn't Java/C just have "applyVisitorPattern(Object Visitor, List Guests)" etc if that is truly a generic solution? The reality of course is this grey area. Hardly any code solution is 100% of one thing - it's probably 30% of business logic, 20% of database design, 20% of memory management, 20% of conscision, 15% of UX considerations, 25% of optimisation, 15% configuration etc And that doesn't add up to 100% which makes a lot of devs uncomfortable if their idea of coding is 100% code using a pattern. In interviews I tend to ask why they want to be a coder, and if the answer is "because I love it" then they have the job. And so far, I've never heard one mention of patterns after 7 years of RnD.
+Peter Turner "The other (main) issue I personally have with patterns is that it gives the impression that there's a stock solution for every possible problem and all a coder needs to do is find the right pattern to apply." That is well said. I would add that most problems don't fit really well into any pre-made pattern.
I don't think we should disregard the utility of patterns with such prejudice. Agreed, patterns are not the be-all end-all solutions to problems, but are good starting points to begin to implement an idea. As is often mentioned, they also empower you with a vocabulary to communicate designs and ideas which would otherwise be hard to articulate. It might be good to find a middle ground where you don't blindly roll your eyes and dismiss patterns, and neither do you put them on a pedestal and treat them as ultimate solutions.
@@nitin_puranik A lot of patterns, including the GoF ones, are proposed not as solutions to real problems, to make code that does useful work, but as "code to fix code". They work as a band-aid for a poorly made, complex system while adding even more complexity to it. Also let's not fool ourselves, like many programming concepts, patterns didn't live up to the hype. If all they did was to serve as a good starting point we would not have popular sites and books dedicate to them.
It frustrates me that people keep forgetting that the Lisp community has been slowly working on all of these problems for decades and has solved a lot of them by now... Clojure and Common Lisp, for example, are incrementally compiled (so you can work interactively without loosing performance), optionally statically typed (so, once you've worked out an interface, you can get static type checking, but it doesn't slow you down when you're experimenting), and have great concurrency primitives (CSP, CAS, STM, immutable data structures, etc.). Plus, because of the power of lisp macros, it's easy for libraries to add new features to the language/compiler in a sane manner, so complex code patterns can be easily abstracted away.
Whenever you see a new way of doing things somewhere, it was probably used by Lisp hackers in the ’60s. Lisp is the past and the future. Other languages just slowly converge to Lisp. Embrace the Lisp.
@nickik21 The go compiler does make pretty fast code, and it's not heavily optimized. People can go ahead and make an LLVM based Go compiler if they want to. They went with a code base they were really familiar with, which was the Plan 9 C compilers as a basis for the Go compilers. Go is pretty expressive, it's got closures. it's got a nice approach to interfaces and types. It's got concurrency built into the language as well as a CSP like programming model.
Man this video made me feel like i just drank a glass of cool fresh water after a long walk through the scorching desert. Really well put. Industrial code is REALLY verbose... java does not help either. It seems more like a 3in1 instant coffee: Just pour some code in there, and it will turn into this beautiful cool new app. But we all know it's not exactly the real thing, like a good made arabica espresso.
Just a beginner's observation, but when I read my forty-some books on Java programming, I see many code examples that are unnecessarily complicated with constructors and tiny methods calling each other, presumably in the name of encapsulation and code reuse. This code could be written easily in a procedural style. I'm led to believe that Brian Will is right: "Object Oriented Programming Is Bad". Why do I need forty books? Because the many ways of doing the same things in Java all need explanation - and I guess they are hard to explain because most of the explanations are poor.
If I knew only Java, I would dislike your comment. But looking at newer languages such as Kotlin and Rust, I might have to say these languages have a lot more conciseness to offer without giving up in performance, .
@XorLavir the .NET apis suffer from the same flaws as Java. Any little thing is a big chore and there's a community culture of accepting -- or shall I even say embracing -- undue complexity. The thing that continues to make Python or Ruby pleasant to work in is that the communities as a whole are pragmatic and will call you out if you write constipated code. This is what .NET needs but suffers from too many years of neglect and bs initiatives - just look at how WCF is destroying productivity.
Computer Science is like LIFE. You first say that herbs are medicines(medival), then we replace them with incantations(premedival), followed by Unani(5th Century), 17th Century(Allopathy), 21st century we go back to herbs. Similarly, Go is an example that verbosity provided by C++ and Java HINDERS programmers more than it supports them. Python is also another example of why we should have LOVED C.
As much as I hate to use Design Patterrn and crap, I have been forced to learn it, because you can't pass iterviews without them. Like damn man, code should be written organically, and be structred by refactoring; not by rules set in stone. That sucks!!
@nwmcsween 1. Because he understands imperative programming, and most programmers know imperative programming vs a declarative or functional style. 3. If it's JIT "compiled" it's not interpreted.
I use C and Python on a daily basis and it works pretty well for the two areas I develop for, very low-level embedded, and dumb apps for my Windows box.
So has GO already made the step from "it's just a project/test and we want to see how it goes", like they said at IO, to a mature language aimed for production?
@farastray1 Are we talking about .net or C# as a language? Because .net has IronRuby and IronPython. >NET apis suffer from the same flaws as Java. That is disputable. I didn't saw in this presentation any mentioning about Java library flaws we could project on .net. >WCF is destroying productivity That is disputable. It is not every way tool. It is pretty small part of libraries. You don't have to use it, right? I also can mention such marvelous project as Nemerle meta-programming.
The Java example breaks about every rule in the book. It's static, the constants do not comply to Sun Java coding practices, it uses 1.4 style code instead of relying on boxing/unboxing, well the list goes on. His other example is a stack of Generics and inner classes put on top of each other. That would have been flagged as a gross abuse by any reviewer. I'm not disagreeing on what he says in the talk per se, but those examples were below the belt.
Btw, in my humble opinion C# doesn't have such minuses. Its syntax is much clearer and "almost" ideal. Plus, lambdas and dynamic make it realy handy. So it is already in that niche. Well, but Google doesn't like MS, so it is obvious why Rob hadn't said a word about .net ;-)
"Go" is a bit too low level for my uses (I prefer Python), but I certainly agree with Rob about the stupid verbosity of C++ and Java, their hidden pitfalls, the suckiness of their stdlibs and of most commonly used libraries, etc.
This was almost a decade ago. @Rob, how do you feel about the amount of Go code that is written now (especially by a large organizations)? Does it pass a litmus test (it should look good on paper) that you proposed? I doubt it. The problem here is not of a language and its features but that of scaling. It's also like the problem of "persistence of identity" (as philosophers depict it in the ship of Theseus) of evolving languages. Maybe we should leave languages alone and frozen and appreciate the beauty of creations (programs) written in them? If we were to refer to spoken languages, Panini did that (freezing a language) with Samskritam 2500 years ago when he wrote a precise and succinct formal grammar for it. But the "real fun" of creations (e.g. poetry, epics, essays, and verses) in that language is a thing of beauty and a joy forever. In case of programming languages, Guy Steele talks about something similar in his famous essay/talk: [Growing a language](www.cs.virginia.edu/~evans/cs655/readings/steele.pdf). Whereas I totally understand the pain that language designers like you and language maintainers/designers like Brian Goetz (his rather sentimental talk "shepherding Java" comes to the mind), I also believe that at some point, languages should "stop growing" and perhaps stay relevant by leaving it to posterity to produce things in it that last. When a time comes that nobody speaks a language or programs in it, well, that was its fate like everything else. In this regard, programming languages are like paradigm shifts that Thomas Kuhn refers to in his book "The Structure of Scientific Revolutions".
what are we takling about exactly? I've written thousands of lines in Golang, and it still doesn't dissapoint and produces exactly the results Rob Pike originally targetted for. Clean code, it always helps by producing linting and compiling warnings and errors for producing even better code. Very readable paradigms and codeflow. Not too much of anything. very simplistic and it just keeps growing (we need generics!!! and they heard us). I really have no idea about what industry you're talking about. Golang does indeed help much in every possible way in producing good code that is readable by everyone without the feel of being in a war with your compiler, whilst providing a tool for every situation (go get, go fmt, go lint etc)
I am getting projects from big organizations, either creating new services in go or moving their existing services from java or nodejs. The only issue I see in most go projects , is that when developers from a OOPs language background work on go, they tend to muck up the code. For instance, they cannot fathom a function living independently, they would always bind it to a structure. After being in the industry for a decade, I am beginning to think, the Java flavor OOP has been oversold.
funny how he calls Java and C++ very verbose, yet Golang us similarly verbose. Just try to do something close to generics and you'll be writing a crap ton of code in no time. interfaces are a cool idea but they're weird and clunky. and can get really confusing fast. I like Go, but it's far from concise
Go is the easiest language ever, and very imperative. I agree it feels too verbose. Rust on the other hand seems more concise with type classes and generics but not many people use it.
This talk is +10 years old and, sadly, Go continues to be a niche language. I can't see Google rewriting Chrome in Go. Something doesn't go very well for Go. That's the truth.
@@OrlOnEarth On my little planet, aka Spain, the Golang offers are really unusual. Anyway, for my next project I would use Go to quit an inherited Python disaster.
I’m amused how the entire talk remains completely oblivious of C#, then describes a niche which C# already fills, and claims that we need Go to fill it again :-D
Rob Pike says good things sometimes, in other times he is just "funny". It's funny when he talks Python (or something like this) is not modern even tough Golang has born in modern era and is not "modern", being a simple (in sense of poor) language and weird on many situstions. Of course it is great for concurrency, but Go is has nothing and offer nothing new (I mean innovative, something really new) what other languages do not. It strikes me that Go has became too famous just because Google is behind it, and not because it is a fantastic language per se. And yes, I've been writing Go code in my day job.
@PALFINTER OMG, You are out of time, sir. Try Mono and MonoDevelop. They are mature now and included in manu Linux distribs by default. >I'm junior scientist and i have little project and there are team about 7 developers. Maybe you are interested in using SIMD also. Mono can do that. tirania. org/ blog/ archive/ 2008/ Nov-03. html C++ and QT is a good choice, but anyway using managed languages is faster for developing.
100% of the examples of "why C++ and Java suck" are C++. Java's not anywhere near that bad. Furthermore, The ECMA open standard language known as C#--brought about by a big, pushy company no different in this space than Google--already had the exact same objectives as Java and now Go had, and it has actually been fundamentally evolving at the core, such as to replace patterns with language features (as seen in lambdas and extension methods). Google just wanted to be INDEPENDENT, typical anti-MS.
I watched all Rob Pike talks because he is so god damn funny.
"What was wrong with the old integer 80?"
Watching 9 years after talk still make sense
Holy moly, you are right! Wow, didn’t look at the year before 😄
However, it is also kind of sad, because would we have changed our developing ways, then I would have known his talk to be out of date, if that makes sense 🤔🙈
2024, not much changed.
10 years after he spoke, Java has become a Chimera. I started working in JAVA after 5 years , and language is almost unrecognizable to me.
which language do you recommend for beginners to learn based on current scenario??
@@neilchumber3172 Go
@@neilchumber3172C, just C, only C
"False dichotomy between static and dynamic languages." Wish I could give this 100 likes.
This talk is from 2010 and it proves the things he is talking about. If you see newer programming languages like Swift, Kotlin or ES6; they are all converging to the same language. Still, the software world suffers from those old-aged problems: error prone code, readability and sharing of code, programmer productivity, compilation speed etc. If those languages are very good, why they can't solve for those who write them? After a long time; People will realise this and Go will be very successful because of its simplicity. There is no doubt about it.
Amen man !!
I like hearing the little bits of laughter coming through his mike even though he's completely deadpan the entire time.
his analysis seems right on to me. Language designers are like the people who make James Bonds weapons. Sometimes they make programmers cool and useful stuff and sometimes it's overly complex crap. At least when things are open source, we get some say in it, which is how it should be.
I agree with Rob's general view on patterns. It's brief so he's probably got a lot more to add to that given time, but overall a pattern does indeed highlight a weakness in the language. If something can be so predictably designed/written often enough to have a name, then it should be inherent within the language.
The other (main) issue I personally have with patterns is that it gives the impression that there's a stock solution for every possible problem and all a coder needs to do is find the right pattern to apply. From my experience this is usually a result of education where being a good student in programming correlates with being able to regurgitate the most applicable pattern given an exam-type scenario.
Over the years in dev (and interviewing coders has been part of that), I've come to the conclusion that patterns remove what is actually the most important aspect of logic/coding - the "grey area" as I call it. A pattern offers the idea that every "real-world" scenario can be resolved by using a method which 100% resolves it and it's just about applying the right pattern. This makes patterns ideal for someone who can "fill in forms" as Rob elegantly puts it. Why doesn't Java/C just have "applyVisitorPattern(Object Visitor, List Guests)" etc if that is truly a generic solution?
The reality of course is this grey area. Hardly any code solution is 100% of one thing - it's probably 30% of business logic, 20% of database design, 20% of memory management, 20% of conscision, 15% of UX considerations, 25% of optimisation, 15% configuration etc And that doesn't add up to 100% which makes a lot of devs uncomfortable if their idea of coding is 100% code using a pattern.
In interviews I tend to ask why they want to be a coder, and if the answer is "because I love it" then they have the job. And so far, I've never heard one mention of patterns after 7 years of RnD.
+Peter Turner "The other (main) issue I personally have with patterns is that it gives the impression that there's a stock solution for every possible problem
and all a coder needs to do is find the right pattern to apply."
That is well said. I would add that most problems don't fit really well into any pre-made pattern.
I don't think we should disregard the utility of patterns with such prejudice. Agreed, patterns are not the be-all end-all solutions to problems, but are good starting points to begin to implement an idea. As is often mentioned, they also empower you with a vocabulary to communicate designs and ideas which would otherwise be hard to articulate. It might be good to find a middle ground where you don't blindly roll your eyes and dismiss patterns, and neither do you put them on a pedestal and treat them as ultimate solutions.
@@nitin_puranik A lot of patterns, including the GoF ones, are proposed not as solutions to real problems, to make code that does useful work, but as "code to fix code". They work as a band-aid for a poorly made, complex system while adding even more complexity to it.
Also let's not fool ourselves, like many programming concepts, patterns didn't live up to the hype. If all they did was to serve as a good starting point we would not have popular sites and books dedicate to them.
It frustrates me that people keep forgetting that the Lisp community has been slowly working on all of these problems for decades and has solved a lot of them by now... Clojure and Common Lisp, for example, are incrementally compiled (so you can work interactively without loosing performance), optionally statically typed (so, once you've worked out an interface, you can get static type checking, but it doesn't slow you down when you're experimenting), and have great concurrency primitives (CSP, CAS, STM, immutable data structures, etc.). Plus, because of the power of lisp macros, it's easy for libraries to add new features to the language/compiler in a sane manner, so complex code patterns can be easily abstracted away.
Lisp is too old and crusty, we want more fashionable languages with hotness!!!
Whenever you see a new way of doing things somewhere, it was probably used by Lisp hackers in the ’60s. Lisp is the past and the future. Other languages just slowly converge to Lisp. Embrace the Lisp.
I will check it out
@nickik21 The go compiler does make pretty fast code, and it's not heavily optimized.
People can go ahead and make an LLVM based Go compiler if they want to. They went with a code base they were really familiar with, which was the Plan 9 C compilers as a basis for the Go compilers.
Go is pretty expressive, it's got closures. it's got a nice approach to interfaces and types. It's got concurrency built into the language as well as a CSP like programming model.
if you think just having closures makes a language expressive, then you probably haven't used many programming languages and/or paradigms.
Man this video made me feel like i just drank a glass of cool fresh water after a long walk through the scorching desert. Really well put.
Industrial code is REALLY verbose... java does not help either. It seems more like a 3in1 instant coffee: Just pour some code in there, and it will turn into this beautiful cool new app. But we all know it's not exactly the real thing, like a good made arabica espresso.
Just a beginner's observation, but when I read my forty-some books on Java programming, I see many code examples that are unnecessarily complicated with constructors and tiny methods calling each other, presumably in the name of
encapsulation and code reuse. This code could be written easily in a procedural style.
I'm led to believe that Brian Will is right: "Object Oriented Programming Is Bad".
Why do I need forty books? Because the many ways of doing the same things in Java all need explanation - and I guess they are hard to explain because most of the explanations are poor.
If I knew only Java, I would dislike your comment.
But looking at newer languages such as Kotlin and Rust, I might have to say these languages have a lot more conciseness to offer without giving up in performance, .
Essentially a critique of Sjoustroup with Java catching bullets because it just happened to be with C++ when Pike rolled up with his Golang crew.
Describes my journey from C /Delphi / Java to Python - and now to Go. 😊
public static void main(String[] args) // Java
vs
func main() // Go
Now guys, go won in my book
crazy how this comment managed to exist without being raided by java verbosecucks for 7+ whole months
To be fair func main is not the equivalent to the above Java.
That would be
func Main(args []string)
@XorLavir the .NET apis suffer from the same flaws as Java. Any little thing is a big chore and there's a community culture of accepting -- or shall I even say embracing -- undue complexity. The thing that continues to make Python or Ruby pleasant to work in is that the communities as a whole are pragmatic and will call you out if you write constipated code. This is what .NET needs but suffers from too many years of neglect and bs initiatives - just look at how WCF is destroying productivity.
Computer Science is like LIFE. You first say that herbs are medicines(medival), then we replace them with incantations(premedival), followed by Unani(5th Century), 17th Century(Allopathy), 21st century we go back to herbs.
Similarly, Go is an example that verbosity provided by C++ and Java HINDERS programmers more than it supports them.
Python is also another example of why we should have LOVED C.
C is the Light
As much as I hate to use Design Patterrn and crap, I have been forced to learn it, because you can't pass iterviews without them. Like damn man, code should be written organically, and be structred by refactoring; not by rules set in stone. That sucks!!
@nwmcsween
1. Because he understands imperative programming, and most programmers know imperative programming vs a declarative or functional style.
3. If it's JIT "compiled" it's not interpreted.
I use C and Python on a daily basis and it works pretty well for the two areas I develop for, very low-level embedded, and dumb apps for my Windows box.
Exact same combo here. And Cython for a good mix!
public static void
it's so depressing innit?
yep, just look this unreadable code, its looks like make for aliens www.tutorialspoint.com/design_pattern/builder_pattern.htm
C++ came out of Bell Labs. You could have prevented this, Rob.
I think hes just a jr dev that time, he doesn't have enough power
i guess he's right in many ways. just curious he hasn't mentioned scala for more than 2 seconds. they seem to down the exact same road...
So has GO already made the step from "it's just a project/test and we want to see how it goes", like they said at IO, to a mature language aimed for production?
it certainly has now. :) Even two of the most popular and most used tools are written in Go. Kubernetes and Docker.
@@exapsy you answered a 10 year old comment
@@aedd3307 "it certainly has now. :)"
Yes, because that was exactly my intention :P
@@aedd3307 an *unanswered 10 year old question
6:27 What was wrong with old integer 80? ROFL
@farastray1
Are we talking about .net or C# as a language? Because .net has IronRuby and IronPython.
>NET apis suffer from the same flaws as Java.
That is disputable. I didn't saw in this presentation any mentioning about Java library flaws we could project on .net.
>WCF is destroying productivity
That is disputable. It is not every way tool. It is pretty small part of libraries. You don't have to use it, right?
I also can mention such marvelous project as Nemerle meta-programming.
@owlstead And yet he was easily able to find code like that in the wild...
The Java example breaks about every rule in the book. It's static, the constants do not comply to Sun Java coding practices, it uses 1.4 style code instead of relying on boxing/unboxing, well the list goes on. His other example is a stack of Generics and inner classes put on top of each other. That would have been flagged as a gross abuse by any reviewer.
I'm not disagreeing on what he says in the talk per se, but those examples were below the belt.
👌🏾
7:41 "clumsy" hit the finger ... or nail
Btw, in my humble opinion C# doesn't have such minuses. Its syntax is much clearer and "almost" ideal. Plus, lambdas and dynamic make it realy handy. So it is already in that niche. Well, but Google doesn't like MS, so it is obvious why Rob hadn't said a word about .net ;-)
10 ? Hello
20 GOTO 10
RUN
0
0
0
0
0
0
0
0
verbosity makes programs easier to maintain. Code completion solves programmers laziness. =)
"Go" is a bit too low level for my uses (I prefer Python), but I certainly agree with Rob about the stupid verbosity of C++ and Java, their hidden pitfalls, the suckiness of their stdlibs and of most commonly used libraries, etc.
@yudlejoza
LOL - Awesome =)
D code compiles much faster than Go.
If a tree falls in the forest...
This was almost a decade ago. @Rob, how do you feel about the amount of Go code that is written now (especially by a large organizations)? Does it pass a litmus test (it should look good on paper) that you proposed? I doubt it. The problem here is not of a language and its features but that of scaling. It's also like the problem of "persistence of identity" (as philosophers depict it in the ship of Theseus) of evolving languages. Maybe we should leave languages alone and frozen and appreciate the beauty of creations (programs) written in them?
If we were to refer to spoken languages, Panini did that (freezing a language) with Samskritam 2500 years ago when he wrote a precise and succinct formal grammar for it. But the "real fun" of creations (e.g. poetry, epics, essays, and verses) in that language is a thing of beauty and a joy forever. In case of programming languages, Guy Steele talks about something similar in his famous essay/talk: [Growing a language](www.cs.virginia.edu/~evans/cs655/readings/steele.pdf). Whereas I totally understand the pain that language designers like you and language maintainers/designers like Brian Goetz (his rather sentimental talk "shepherding Java" comes to the mind), I also believe that at some point, languages should "stop growing" and perhaps stay relevant by leaving it to posterity to produce things in it that last. When a time comes that nobody speaks a language or programs in it, well, that was its fate like everything else. In this regard, programming languages are like paradigm shifts that Thomas Kuhn refers to in his book "The Structure of Scientific Revolutions".
what are we takling about exactly? I've written thousands of lines in Golang, and it still doesn't dissapoint and produces exactly the results Rob Pike originally targetted for. Clean code, it always helps by producing linting and compiling warnings and errors for producing even better code. Very readable paradigms and codeflow. Not too much of anything. very simplistic and it just keeps growing (we need generics!!! and they heard us).
I really have no idea about what industry you're talking about. Golang does indeed help much in every possible way in producing good code that is readable by everyone without the feel of being in a war with your compiler, whilst providing a tool for every situation (go get, go fmt, go lint etc)
I am getting projects from big organizations, either creating new services in go or moving their existing services from java or nodejs. The only issue I see in most go projects , is that when developers from a OOPs language background work on go, they tend to muck up the code.
For instance, they cannot fathom a function living independently, they would always bind it to a structure.
After being in the industry for a decade, I am beginning to think, the Java flavor OOP has been oversold.
funny how he calls Java and C++ very verbose, yet Golang us similarly verbose. Just try to do something close to generics and you'll be writing a crap ton of code in no time. interfaces are a cool idea but they're weird and clunky. and can get really confusing fast. I like Go, but it's far from concise
Go is the easiest language ever, and very imperative. I agree it feels too verbose. Rust on the other hand seems more concise with type classes and generics but not many people use it.
What I don't like about Go Interfaces is that they only support virtual dispatch. Go should be more zero-cost abstraction.
This talk is +10 years old and, sadly, Go continues to be a niche language. I can't see Google rewriting Chrome in Go. Something doesn't go very well for Go. That's the truth.
On which planet are you living? Go programmers are highly requested, and highly paid, Go's adoption is through the roof
@@OrlOnEarth On my little planet, aka Spain, the Golang offers are really unusual. Anyway, for my next project I would use Go to quit an inherited Python disaster.
I’m amused how the entire talk remains completely oblivious of C#, then describes a niche which C# already fills, and claims that we need Go to fill it again :-D
They day when you can write a function outside a class in C#, I will agree with you. But I do like C# though.
Rob Pike says good things sometimes, in other times he is just "funny". It's funny when he talks Python (or something like this) is not modern even tough Golang has born in modern era and is not "modern", being a simple (in sense of poor) language and weird on many situstions. Of course it is great for concurrency, but Go is has nothing and offer nothing new (I mean innovative, something really new) what other languages do not. It strikes me that Go has became too famous just because Google is behind it, and not because it is a fantastic language per se. And yes, I've been writing Go code in my day job.
@PALFINTER
OMG, You are out of time, sir.
Try Mono and MonoDevelop. They are mature now and included in manu Linux distribs by default.
>I'm junior scientist and i have little project and there are team about 7 developers.
Maybe you are interested in using SIMD also. Mono can do that.
tirania. org/ blog/ archive/ 2008/ Nov-03. html
C++ and QT is a good choice, but anyway using managed languages is faster for developing.
100% of the examples of "why C++ and Java suck" are C++. Java's not anywhere near that bad. Furthermore, The ECMA open standard language known as C#--brought about by a big, pushy company no different in this space than Google--already had the exact same objectives as Java and now Go had, and it has actually been fundamentally evolving at the core, such as to replace patterns with language features (as seen in lambdas and extension methods). Google just wanted to be INDEPENDENT, typical anti-MS.