>As I had before, I recognized that this technology had the potential to revolutionize how software was written at a fundamental level.
Congrats and all, and I love Hugo (use it all the time).
That said, I think the kool-aid was spiked with something.
Sorry, but in what way is Go "revolutionizing"?
I'd buy "refreshing simplicity" and "yay, static builds again" but it's hardly revolutionary, even in its most touted feature (channels).
And it hardly changed how people write software. At best, it introduced some dynamic language programmers to static types and static builds.
All the rest, including creating a language that's easy for average programmers to program at scale was already the goal, and a success at that, of Java.
Go's big success, in my opinion, was to fuse the lightweight, spawn a million threads we don't care, style of programming to conventional imperative, conventional static-type programming. I know of several other runtimes that had that lightweight threading capability, I've been using them since years before Go was even a thing, but they all required programmers to learn a new paradigm. At times, a radically new paradigm (Haskell).
You may complain that programmers have a professional obligation to learn those new paradigms. You may complain that programmers should consider "learning a new paradigm" a smaller strike against a language, especially if it brings other good things with it. But that won't change observed reality, in which programmers do want to not have to risk several months to a year on something they aren't sure will pay off. By contrast, if you know any of the existing manifestly-typed languages at all (Java, C, C++), which most programmers do to some extent, you'll be writing fancy concurrent code in Go next week. Possibly even "tomorrow". You can be shipping production code in a month.
The language nerd in me really wishes Go had isolated its goroutines from each other and only passed things by value. (While I like Rust's much finer-grained handling of that for a lot of other reasons, you can get a lot of the benefits in a language where the threads aren't supposed to be that large by isolating to small threads, and it's way easier to implement.) The pragmatist in me is forced to reluctantly admit that had it done so it probably wouldn't have succeeded as much, because while that may not have been a "full" paradigm shift if the rest of the language was still imperative, it still would have been at least half of one. That affects how you design larger programs. In a lot of good ways, I think, but still, change with an unknown prospect of payoff.
So... it depends on your point of view. It's not revolutionary in the sense that there's anything new in it. But it is a somewhat revolutionary combination of concepts.
You're even free to join me in being a bit sad that fusing your concepts to an Algol-descended language is basically mandatory for success right now. But, one step at a time. We are slowly creeping away from it. As I've often observed, programming as a profession does not move anywhere near as quickly as some people think; there's a constant surface churn of technologies and languages, but deep paradigm shifts take decades.
By offering simplicity. Taking a step back to before C++. And providing a better C. C + strings + GC + map + slice(array) + json/xml parsing + http transport layer (server & client). What else do you need? Ideal for minimalists. That's its beauty. Programs are very stable. Takes less memory than Java (some amount more than C/C++). Faster compilation time compared to C++. A convenient C. For minimalists, who like to cut down all the jargon, and solve the problem. Looking at it that way, you see its beauty.
Some of the harder more time consuming things in high level programming include abstraction/polymorphism, concurrency and dependency management which are all simpler and clearer in Go than in Java. Think about how many hours you have to invest to learn any of these things in either language.
>At best, it introduced some dynamic language programmers to static types and static builds.
Can confirm (well, add another point of anecdote), I played with it a bit in order to get some experience with static stuff before diving into the whole C ecosystem.
Next thing I build that needs that kind of development will probably be C though.
I interviewed at Mongo a long time ago for a Drupal developer position. It was strange, they took me through a bunch of whiteboard algorithm crap that had nothing to do with Drupal. Obviously they weren't Drupal devs and didn't know how to interview for one so they just gave me the standard CS stuff. Obviously I was a Drupal dev so I didn't know shit about actual CS topics. I failed hard and learned a lot from it.
Steve was the only one of the 3 that I interviewed with that didn't come across as a self-important asshole. He was kind and helpful and overall seemed like the perfect guy for a Developer Advocate or whatever the title was. I wish him luck.
> they took me through a bunch of whiteboard algorithm crap that had nothing to do with Drupal.
Oh I hate that type of interview. I had a similar experience getting interviewed for a front-end dev position by two backend devs at a consumer VPN company in Toronto who asked me to write common CS algorithms while they both sat there staring at me.
Even ignoring the total lack of connection between the content of the algo with the job in question, I've never coded like that in my life. Largely because I also never took a CS course and didn't bothered to study cliche interview questions because I don't apply to big cos. But most importantly, I don't solve problems on the spot in front of other people IRL, so what aptitude are they testing for exactly?
I'm an introvert who always codes with headphones on and likes to spend time thinking through problems on my own - but can also work with other devs to solve problems when needed. I also had OSS projects, private repos I could show them, and live production apps with tens of thousands of visitors I built myself to point to my aptitude. That's been more than enough for other smart teams to hire me. It's also the content I look for most when I've hired people myself.
The non-technical founder also never told me ahead of time they were going to do this type of interview so I was surprised when they sat me down.
Also during a telephone interview with their other semi-technical founder asked me to describe how NAT works (yes asking a front-end dev to describe network implementation details). I figured he was just confused about what I would be doing for them... then I showed up to meet the two backend devs the next day.
I just walked out of the interview and told the founder his hiring process was silly, even though I liked the company (product). I'm happy I did.
I should note that I'm not against the idea of measuring aptitude during the hiring process, if companies want to be thorough. For example. during another interview process with a different company a dev team gave me a problem to solve (with ample warning before I arrived that day) and let me solve it on my own, using my own laptop in a quiet room, while they went back to work at their own desks for an hour or two (taking however long I needed). I was fine with that process and it worked out. There was also a collaborative element to it as well. That was a test better grounded in the reality of software development.
I'm sorry to hear that. Go is not revolutionary (unless you count "completely ignoring runtime errors" to be revolutionary). If anything, functional languages are the new, old, revolutionary thing.
-) A proper package manager. (no, go get is not enough. They have realized this and have a team coming up with a draft for an official one)
-) Well written, well maintained libraries that do proper releases. There are very few of those out there. Might get better with an offical package manager and ideally package repository a la npm/crates.io
-) Generics. This will help the previous point also. Often it's hard to write proper reusable libraries due to the lack of generics. And no, they didn't keep generics out because they are to complicated for the language users. They just (quote) "didn't find a good way to implement them", and big language changes like that are out of scope before 2.0.
-) Macros probably won't ever come, but if not, please at least give us a language construct that reduces error handling boilerplate. (Rust has some nice macros for that).
JetBrains WebStorm with the free Go plug-in provides an excellent Go IDE experience. There are some free community editions of JetBrains IDEs that are supposed to work with the Go plug-in (e.g. PyCharm, if I’m not wrong), so you do not even have to pay anything.
Atom has surprisingly consistent and useful support for go - fmt on save, debugging, automatically manages imports in a file, and the autocomplete works very well.
* Interfaces which can have fields would be really, really great.
* A rust-style borrow checker would make dealing with channels and pointers a lot safer.
* Equality operations for slices would clean up some ugly parts of the standard net library (addresses are []byte, so a direct x == y doesn't work but seems like it should).
* Closed enum sets: some ability to setup an enum type which can be "complete" when used in a switch statement without needing a "default" and which will only panic/fail when a bad type conversion is made. Let me sanitize out a whole bunch of possible errors at one point in my code when I want to use constants (and be warned when I break the guarantees).
My two Golang pet peeves, not very important either:
-still no math.round WTF?
-make() should be syntax and not this quasi-function that takes this vast array of argument types, and while you're at it, you should just rename it `new`, because that's what it is.
Programming in C# feels almost like scripting. Blazing-fast compilation with the added benefit of static type system. If only MS took a different path of cross-platform support in the beginning.
As a habit it is bad, but this is actually standard for short bios. It allows it to be dropped in place directly for conferences, PR shots, news articles, etc without any rewrite.
It is pretty readable, but really non-functional too. Eg, they still don't have math.round and you wind up writing a lot of code because it can be a little bare bones or does things in a way that isn't quit usable.
I wouldn't say it is very expressive either. Go can be very wordy and verbose at times, and some things are downright a pain or poorly thought out (e.g, while Java has finally and C++/Rust have RIAA for dealing with resource deallocation Go has defer and it doesn't work really well when you encounter an error in the dealloc logic).
Simplicity is about Java 1.0. Give Go some time to add some technical debt before you get too excited about it simplicity.
It isn't a bad language. This is my second run thought the language, and I'm neither excited nor turned off by it.
[+] [-] coldtea|9 years ago|reply
Congrats and all, and I love Hugo (use it all the time).
That said, I think the kool-aid was spiked with something.
Sorry, but in what way is Go "revolutionizing"?
I'd buy "refreshing simplicity" and "yay, static builds again" but it's hardly revolutionary, even in its most touted feature (channels).
And it hardly changed how people write software. At best, it introduced some dynamic language programmers to static types and static builds.
All the rest, including creating a language that's easy for average programmers to program at scale was already the goal, and a success at that, of Java.
[+] [-] jerf|9 years ago|reply
You may complain that programmers have a professional obligation to learn those new paradigms. You may complain that programmers should consider "learning a new paradigm" a smaller strike against a language, especially if it brings other good things with it. But that won't change observed reality, in which programmers do want to not have to risk several months to a year on something they aren't sure will pay off. By contrast, if you know any of the existing manifestly-typed languages at all (Java, C, C++), which most programmers do to some extent, you'll be writing fancy concurrent code in Go next week. Possibly even "tomorrow". You can be shipping production code in a month.
The language nerd in me really wishes Go had isolated its goroutines from each other and only passed things by value. (While I like Rust's much finer-grained handling of that for a lot of other reasons, you can get a lot of the benefits in a language where the threads aren't supposed to be that large by isolating to small threads, and it's way easier to implement.) The pragmatist in me is forced to reluctantly admit that had it done so it probably wouldn't have succeeded as much, because while that may not have been a "full" paradigm shift if the rest of the language was still imperative, it still would have been at least half of one. That affects how you design larger programs. In a lot of good ways, I think, but still, change with an unknown prospect of payoff.
So... it depends on your point of view. It's not revolutionary in the sense that there's anything new in it. But it is a somewhat revolutionary combination of concepts.
You're even free to join me in being a bit sad that fusing your concepts to an Algol-descended language is basically mandatory for success right now. But, one step at a time. We are slowly creeping away from it. As I've often observed, programming as a profession does not move anywhere near as quickly as some people think; there's a constant surface churn of technologies and languages, but deep paradigm shifts take decades.
[+] [-] aws_ls|9 years ago|reply
By offering simplicity. Taking a step back to before C++. And providing a better C. C + strings + GC + map + slice(array) + json/xml parsing + http transport layer (server & client). What else do you need? Ideal for minimalists. That's its beauty. Programs are very stable. Takes less memory than Java (some amount more than C/C++). Faster compilation time compared to C++. A convenient C. For minimalists, who like to cut down all the jargon, and solve the problem. Looking at it that way, you see its beauty.
edit: typo
[+] [-] dgb23|9 years ago|reply
[+] [-] traverseda|9 years ago|reply
Can confirm (well, add another point of anecdote), I played with it a bit in order to get some experience with static stuff before diving into the whole C ecosystem.
Next thing I build that needs that kind of development will probably be C though.
[+] [-] nbevans|9 years ago|reply
[+] [-] squeed|9 years ago|reply
And never, ever, ever give up the fight for GNU-style double-dash command-line flags!
[+] [-] Touche|9 years ago|reply
[+] [-] Jgrubb|9 years ago|reply
Steve was the only one of the 3 that I interviewed with that didn't come across as a self-important asshole. He was kind and helpful and overall seemed like the perfect guy for a Developer Advocate or whatever the title was. I wish him luck.
[+] [-] dmix|9 years ago|reply
Oh I hate that type of interview. I had a similar experience getting interviewed for a front-end dev position by two backend devs at a consumer VPN company in Toronto who asked me to write common CS algorithms while they both sat there staring at me.
Even ignoring the total lack of connection between the content of the algo with the job in question, I've never coded like that in my life. Largely because I also never took a CS course and didn't bothered to study cliche interview questions because I don't apply to big cos. But most importantly, I don't solve problems on the spot in front of other people IRL, so what aptitude are they testing for exactly?
I'm an introvert who always codes with headphones on and likes to spend time thinking through problems on my own - but can also work with other devs to solve problems when needed. I also had OSS projects, private repos I could show them, and live production apps with tens of thousands of visitors I built myself to point to my aptitude. That's been more than enough for other smart teams to hire me. It's also the content I look for most when I've hired people myself.
The non-technical founder also never told me ahead of time they were going to do this type of interview so I was surprised when they sat me down.
Also during a telephone interview with their other semi-technical founder asked me to describe how NAT works (yes asking a front-end dev to describe network implementation details). I figured he was just confused about what I would be doing for them... then I showed up to meet the two backend devs the next day.
I just walked out of the interview and told the founder his hiring process was silly, even though I liked the company (product). I'm happy I did.
I should note that I'm not against the idea of measuring aptitude during the hiring process, if companies want to be thorough. For example. during another interview process with a different company a dev team gave me a problem to solve (with ample warning before I arrived that day) and let me solve it on my own, using my own laptop in a quiet room, while they went back to work at their own desks for an hour or two (taking however long I needed). I was fine with that process and it worked out. There was also a collaborative element to it as well. That was a test better grounded in the reality of software development.
[+] [-] bigato|9 years ago|reply
[+] [-] pmarreck|9 years ago|reply
[+] [-] thwd|9 years ago|reply
[+] [-] packetslave|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] kozikow|9 years ago|reply
Personally, golang "IDE" experience is not as good as Java or even C++.
For example, ycmd only supports subset of functions for golang. I miss ycmd-goto-references the most.
[+] [-] the_duke|9 years ago|reply
-) A proper package manager. (no, go get is not enough. They have realized this and have a team coming up with a draft for an official one)
-) Well written, well maintained libraries that do proper releases. There are very few of those out there. Might get better with an offical package manager and ideally package repository a la npm/crates.io
-) Generics. This will help the previous point also. Often it's hard to write proper reusable libraries due to the lack of generics. And no, they didn't keep generics out because they are to complicated for the language users. They just (quote) "didn't find a good way to implement them", and big language changes like that are out of scope before 2.0.
-) Macros probably won't ever come, but if not, please at least give us a language construct that reduces error handling boilerplate. (Rust has some nice macros for that).
[+] [-] tqkxzugoaupvwqr|9 years ago|reply
https://www.jetbrains.com/products.html?fromMenu#type=ide
[+] [-] leetrout|9 years ago|reply
[+] [-] vetinari|9 years ago|reply
Most go modes for various editors use native go utilities as their backend, for example gocode/godef/golint/gorename/guru, etc.
[+] [-] ruffrey|9 years ago|reply
[+] [-] XorNot|9 years ago|reply
* A rust-style borrow checker would make dealing with channels and pointers a lot safer.
* Equality operations for slices would clean up some ugly parts of the standard net library (addresses are []byte, so a direct x == y doesn't work but seems like it should).
* Closed enum sets: some ability to setup an enum type which can be "complete" when used in a switch statement without needing a "default" and which will only panic/fail when a bad type conversion is made. Let me sanitize out a whole bunch of possible errors at one point in my code when I want to use constants (and be warned when I break the guarantees).
[+] [-] jnordwick|9 years ago|reply
-still no math.round WTF?
-make() should be syntax and not this quasi-function that takes this vast array of argument types, and while you're at it, you should just rename it `new`, because that's what it is.
[+] [-] tkubacki|9 years ago|reply
Make decent visual debugger and devs will come.
[+] [-] gravypod|9 years ago|reply
[+] [-] zvrba|9 years ago|reply
[+] [-] romanovcode|9 years ago|reply
[+] [-] swah|9 years ago|reply
[+] [-] pmarreck|9 years ago|reply
[+] [-] fibo|9 years ago|reply
[+] [-] karakal|9 years ago|reply
[+] [-] coriny|9 years ago|reply
[+] [-] pgt|9 years ago|reply
[+] [-] amelius|9 years ago|reply
[+] [-] TurboHaskal|9 years ago|reply
[+] [-] erikb|9 years ago|reply
[+] [-] hnarayanan|9 years ago|reply
[+] [-] smegel|9 years ago|reply
Is Go really expressive?
[+] [-] jnordwick|9 years ago|reply
I wouldn't say it is very expressive either. Go can be very wordy and verbose at times, and some things are downright a pain or poorly thought out (e.g, while Java has finally and C++/Rust have RIAA for dealing with resource deallocation Go has defer and it doesn't work really well when you encounter an error in the dealloc logic).
Simplicity is about Java 1.0. Give Go some time to add some technical debt before you get too excited about it simplicity.
It isn't a bad language. This is my second run thought the language, and I'm neither excited nor turned off by it.
[+] [-] favadi|9 years ago|reply
[+] [-] ex_amazon_sde|9 years ago|reply
[+] [-] idobai|9 years ago|reply
[deleted]
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] asdfologist|9 years ago|reply
[+] [-] Lord_Zero|9 years ago|reply
[+] [-] bitmapbrother|9 years ago|reply
[+] [-] snippet22|9 years ago|reply
One thing I liked the most about c# was the libraries in one place.
One thing I liked the most about PHP is the many array methods and easy to call methods from objects.
One thing I liked the most about Python is the readability and built in debugger into the language.
One thing I didn't like about all of them is all the libraries you have to memorize.