10 ms·
The author obviously doesn't like Go. Ok, he can have his own opinions. I've been coding professionally since 1987, using everything from mainframe assembler,
by kitd 4y ago
The author obviously doesn't like Go. Ok, he can have his own opinions.
I've been coding professionally since 1987, using everything from mainframe assembler, Fortran, C, VB, Java, C++, to most recently Go. IMHO, the language itself plays a smaller role in its usefulness than most think. As important is the tooling, stdlib, ecosystem, community and "StackOverflow"-ability.
Go has a few warts, like every language, but not that many, and they are more than made up for by how easy it is to assemble and run a project using it. It's that that makes it the most productive language I've used so far.
- paskozdilar 4y agoFor me, the goroutines + channels + select is what makes Go leagues above any other popular language. As far as I know, no other popular language allows you to read from multiple queues at the same time, which is an extremely useful pattern in concurrent programming. The only way to "select" from multiple sources in other languages is to use some kind of poll/select syscall on file descriptors - and even that is very limited, since kernel (at least Linux) does not allow userspace programs to create private file descriptors for intra-process communication - they must always be bound to some file/pipe/socket.
- fasterthanlime 4y ago> As far as I know, no other popular language allows you to read from multiple queues at the same time Off the top of my head, that's certainly possible in Rust, C++ and Java - probably many others I just don't know about. That particular bit of concurrency goodness comes from the 70s, so you can be sure other languages picked it up.
- npe 4y agoAs I understand it, he's talking about select/alt (i.e. guarded commands from CSP) being a native feature of the language rather than callback-based approaches. It's possible to implement CSP channels in most languages, but they're not first-class like go.
- samhw 4y ago> It's possible to implement CSP channels in most languages, but they're not first-class like go. But does that matter? In all my experience, I can't think of any instances where that wouldn't be a distinction without a difference. (Perhaps I'm missing something, though.)
- fasterthanlime 4y agoDefaults matter because friction matters, but friction there is largely removed by having a decent package manager, so I personally don't think it matters (though the topic of "what batteries should be included" has far from run its course).
- npe 4y agoThe minute you put language constructs in the base syntax and runtime of the language, it's a lot more than friction. Love it or hate it, Go is inextricably tied to CSP.
- npe 4y agoIt matters a lot IMO. Most systems programming languages can implement whatever concurrency primitives you care to use, but most people default to whatever is provided by the OS/language because concurrency is hard. Having first-class syntactic sugar over a concurrent runtime bakes in a certain programming style in the language, which strongly determines how the language is used and the programming style. Go comes out of the Newsqueak/Aleph/Limbo family which has a very different style of programming compared to a lot of other languages.
- samhw 4y agoI think there's a difference between 'in the standard library' and 'in the language', though. They seem to be praising Go for doing the latter. And the technical language in which it was expressed gave me to think there was some technical motivation for that, as opposed to sociological - but if what they meant is what you said, then I certainly wouldn't disagree with that.
- thestoicattack 4y agoAda too, I think.
- pyjarrett 4y agoAda has had this built-in for decades, and even allows selecting from one of multiple waiting queues (entries) using a `select` keyword.
- bheadmaster 4y agoIf you could spare some time, would you please demonstrate an example? Any language of those mentioned would be OK.
- fasterthanlime 4y agoHere's a Rust example, with tokio: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=825256f548eb9bb5df528704867f80fd https://play.rust-lang.org/?version=stable&mode=debug&editio... - I don't have time to come up with Java/C++ examples, but I'm sure others will. (If your point was about it being _built into the language_, then it definitely stands, see the other discussion in the parent comment thread)
- paskozdilar 4y agoYeah, I guess I overestimated the complexity of such mechanisms. I mean, still, you need some kind of runtime for the asynchronicity, but the Rust version seems fairly OK (apart from the function coloring, but that's another story). I guess I just like it being built into the language. Plus no function coloring (everything is asynchronous, but appears synchronous) really makes it easy to build complex systems.
- autarch 4y agoHere's a rust example - https://github.com/autarch/channel-select https://github.com/autarch/channel-select
- moralestapia 4y ago>read from multiple queues at the same time That's a trivial thing in javascript.
- metadat 4y agoHow? Javascript is single threaded run loop.
- lalaithion 4y agoConcurrency is not parallelism: https://go.dev/blog/waza-talk#:~:text=In%20programming%2C%20concurrency%20is%20the,lots%20of%20things%20at%20once https://go.dev/blog/waza-talk#:~:text=In%20programming%2C%20....
- metadat 4y ago>read from multiple queues at the same time Agreed, and things happening "at the same time" are possible only with parallelism. Hence my question =)
- moralestapia 4y agoI interpreted "at the same time" as "without blocking", But sure you could also add parallelism using a few built-in Node modules (there's cluster and worker threads, also don't know if atomics are already in Node, they are in V8), It's not trivial anymore but also not that hard. A newcomer could figure it out in ~30 mins from the docs.
- metadat 4y agoGotcha, sounds like we interpreted it differently. I appreciate you taking the time to clarify, I am an old hand as JS but didn't know true parallelism had become feasible these days. Thank you, sincerely!
- 4y ago
- jcelerier 4y agohere's some documentation on how to do it in C++ with boost in 2008, before go even existed: in this example two threads pull events from a single queue. https://www.boost.org/doc/libs/1_35_0/doc/html/boost_asio/tutorial/tuttimer5/src.html https://www.boost.org/doc/libs/1_35_0/doc/html/boost_asio/tu... (of course it was possible before)
- paskozdilar 4y agoI'm not really experienced with Boost so I'm having a hard time understanding what that snippet does. Is there any example that is completely self-contained (or at least limited to STL)?
- jcelerier 4y agoBoost's io_service (since then renamed as io_context) is an implementation of a thread-safe event queue. Threads can put events in the queue (timer events, asynchronous read and write requests for networking, but one can also just push a generic lambda). This example sets up two timers which will regularly push events in the queue, while two threads processes these events. It's from before c++ had lambdas - nowadays it can be written much more tersely. I'll try to write a short example after when I'm not on my phone - it should be reduceable to 5-6 lines of setup at most
- jcelerier 4y ago=> very dumb example of processing messages from ten threads #include <boost/asio.hpp> #include <atomic> #include <iostream> #include <thread> int main() { boost::asio::io_context io; using work_guard_type = boost::asio::executor_work_guard<boost::asio::io_context::executor_type>; work_guard_type work_guard(io.get_executor()); std::vector<std::jthread> t; for(int i = 0; i < 10; i++) t.emplace_back(std::jthread([&io] { io.run(); })); std::atomic_int counter{}; while(counter < 100) io.post([&] { std::cerr << std::this_thread::get_id() << '\n'; counter++; }); io.stop(); return 0; }
- lalaithion 4y agoIf that's all you want, Haskell has had goroutines (forkIO, yes it's called "fork" but it doesn't spawn an OS level process, that's forkOS), channels, and select since 1996. https://www.microsoft.com/en-us/research/wp-content/uploads/1996/01/concurrent-haskell.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...
- otterley 4y agoPeople also want a programming language they can easily read and that has enough market share to work well in team environments.
- newaccount2021 4y ago
- aidaman 4y agonobody should ever write haskell
- jayd16 4y agoLots of languages have similar async, channel and pattern matching syntax these days. Kotlin, C#, off the top of my head. Probably a lot more.
- innagadadavida 4y agoA couple of things to add to this: the language spec is like a page long and very readable. Also the entire compiler toolchain and everything is written in Go and doesn’t depend llvm etc. This doesn’t help the developer but is a pretty unique aspect of Go.
- randomdata 4y ago> Also the entire compiler toolchain and everything is written in Go and doesn’t depend llvm etc. Depends on which implementation you're talking about. One of the stated goals of the Go project is that there must not be just one implementation. gc does not, but tinygo depends on llvm. gccgo depends on gcc.
- josephcsible 4y agoIf a language spec is only a page long, it's leaving a bunch of important things unspecified.
- metadat 4y agoCan you clarify further? Otherwise this seems like a shallow dismissal, which is against our HN community guidelines, and makes for uninteresting discussion.
- alice-i-cecile 4y agoProgramming languages have a large amount of irreducible complexity. A page long spec for a language more complex than Brainfuck cannot represent the critical distinctions correctly. Without that clarity, you end up with incompatible, spec-compliant implementations. This is a disaster, and so below a certain point relative to language complexity a shorter spec is simply wrong.
- metadat 4y agoAre there nasty divergences between official go and cgo?
- adhoc_slime 4y agoThis has perhaps been my biggest pain-point with Golang.. Woe unto those who do not follow the idiosyncrasies of how golang handles versioning, package management, tooling etc. if this is really your most important part of a language I would whole-heartedly recommend looking at rust which has been a breathe of fresh air in terms of package management and tooling.
- jeroenhd 4y agoI love Rust as a language but its packaging mechanism is as flawed as all the others. I don't really see what breath of fresh air it brings. I suppose you can define feature flags in your Cargo.toml but that's about it.
- yen223 4y agoGolang has the most hilarious approach to date formatting
- deleted 4y ago[deleted]
- lenkite 4y agoLol, I thought it was some sort of Joke when I first learnt it. And kept hunting for the 'proper' way. When I realised this was serious, I banged my head against the wall.
- Karrot_Kream 4y ago+100. I found a lot of the points in the post pretty silly/arbitrary, but if he had talked about date formatting I would be all aboard.
- thegeekpirate 4y agoYou might enjoy https://golangti.me https://golangti.me which I wrote to help with my inability to remember it!
- busterarm 4y agoAs an operations person who cares about deploying repeatable systems at scale, Rust's package management (and the toolchain's "packaging" itself) is an absolute nightmare. But at least I with MUSL can I have a 100% statically linked binary, which really should have been easier but that's another argument. Seriously though, Rust team needs to have its Come To Jesus moment about not piping shit off the internet to sh.
- alyandon 4y agoYeah, it's pretty obvious to me the author doesn't like Go and some of the arguments raised really aren't concerns in (my very limited part of) the real world. I've written a fair amount of Go and I am not bothered at all by the general ergonomics of the language. Some of the issues the author points out (like accidentally copying structs with embedded synchronization primitives) are caught by linters which you should be using regardless of what language you are coding in. Edit: I dabble with Rust from time to time as well.
- 14113 4y agoFrom the article: "[...] as developers get more and more senior, they tend to ignore more and more problems, because they've gotten so used to it. That's the way it's always been done, and they've learned to live with them, so they've stopped questioning it any more."
- yegle 4y agoHmm won't this apply to any language and therefore not a valid argument? A: language FOO is a great language! B: You are telling lies because you are fluent in this language and ignore the problems in the language.
- jayd16 4y agoJust speaking abstractly, whether problems are ignored has no bearing on the existence, size or count of the problems.
- xtracto 4y agoIt seems to me there are two ways to evaluate the "beauty" of a language: there's the people who love the language theoretically (well constructed, coherent, nice typing, etc) and then there's people who love the usefulness/utility of the language. For example, I hate python as a language (spaces syntax? Self,self,self, lack of static type, etc) but I've been using it lately and it's nice using it due to libraries, community,etc.
- sophacles 4y agoYes. This is true of any environment. That's why I ask new hires to write down every WTF moment, every question and every idea for improvement they have as they get up to speed on our systems. Just because I'm used to avoiding a problem doesn't mean the problem must exist.
- formerly_proven 4y agoIME there are sort of two kinds of people here. People who are "fans" and defend "their" toy and people who don't. For example, I've been using Python for a very long time. I'm a "Senior Python Developer" so to speak. I quite like it for various purposes, but I can also talk your ear off about problems with Python. I'd say if you run into someone who says they're experienced with X or love X etc., but they can't give criticism of it, they're most likely either not that experienced with X, or fanboys.