Go 1.16 released Posted Feb 17, 2021 19:38 UTC (Wed) by benhoyt (subscriber, #138463) [Link] It's a good release! LWN wrote about the new filesystem interface (io/fs) and the file embedding last July: Go filesystems and file embedding. Related to the new io/fs interface, there's also a new os.ReadDir function (similar to Python's os.scandir), which speeds up directory traversal. Go 1.16 released Posted Feb 18, 2021 0:11 UTC (Thu) by xnor (guest, #125308) [Link] (29 responses) Still wondering why anyone would use this language for anything other than toy/hobby projects. Go 1.16 released Posted Feb 18, 2021 0:43 UTC (Thu) by HelloWorld (guest, #56129) [Link] Correct, it's a horribly designed language that ignored most of what happened in programming language design in the last 50 years. It really is based on ideas from the 60s. That said, it does compile fast, and everyone who ever worked on a significant Scala, C++, Haskell or Rust codebase knows that this is a real advantage. Go 1.16 released Posted Feb 18, 2021 1:31 UTC (Thu) by benhoyt (subscriber, #138463) [Link] (12 responses) Trollish comment, but I'll bite. :-) People have said the same thing about languages like Python, but that seems to be used for some quite large projects. Go is used (quite effectively) for some very large projects: Docker, Kubernetes, Hashicorp's tools, Juju, CockroachDB, Hugo, Traefik, Caddy (more here). I personally like it for large projects due to its lightweight static typing (didn't feel too heavy coming from Python), unique take on interfaces, C-like size of the language, goroutines, great standard library, excellent tooling (including a fast compiler), and the community's focus on fewer dependencies. People have complained that its type system is stuck in the 60's. But some things were simpler in the 60's. :-) Yes, sometimes nil pointers are a bit of a pain, and error handling can be boilerplatey, but it keeps things simple and explicit, and the simplicity helps keep the tooling simple and the compiler fast, so it's a pragmatic win. Go 1.16 released Posted Feb 18, 2021 8:58 UTC (Thu) by HelloWorld (guest, #56129) [Link] (11 responses) > People have said the same thing about languages like Python, but that seems to be used for some quite large projects. Yes, and these large projects are often quite buggy. Personally I can't understand how anybody can still defend dynamic typing at this point. It inherently makes software unmaintainable, because you never know what the data you're dealing with looks like, and your tools also don't, e. g. code completion doesn't work. Yes, there's mypy and all that, and it's useless – you can't retrofit this sort of stuff onto an existing culture of programmers. > Go is used (quite effectively) for some very large projects Yeah, so what? People are using horrible languages to write useful software all the time. Great software has been written in C and PHP, but that doesn't make these languages any less crappy. The question you need to answer to judge a programming language isn't how much great software has been written in it. It is how good that software would have been if it had been written in a different languagage, assuming that the developers were equally skilled with that language. > I personally like it for large projects due to its lightweight static typing What is “lightweight” supposed to mean in a type system context? Go's type system is atrocious. There is no excuse for not having generics in 2021. And yes, apparently they're going to add them, and that doesn't fix the problem *at all* because then you still don't have higher kinded types, higher rank polymorphism, GADTs (or even ADTs!) and all the other stuff that modern type systems have had for years. > goroutines The fact that they need to put goroutines in the language (just like many other features, such as maps) just shows that the type system is useless, because these things should be implemented as libraries. > People have complained that its type system is stuck in the 60's. But some things were simpler in the 60's I'm so sick and tired of this argument. If you seriously have trouble coping with the “complexity” of generics, then you shouldn't be writing software, period. Yes, things were simpler in the 60s, because the problems were simpler back then. Using these ideas to solve today's problems is like a carpenter refusing to use power tools. > Yes, sometimes nil pointers are a bit of a pain, and error handling can be boilerplatey, but it keeps things simple and explicit Bullshit! The simplest code is the code you don't need to write, and hence any kind of boilerplate makes code *less* simple. It's a completely unnecessary distraction. > the simplicity helps keep […] the compiler fast I believe this to be the only valid argument in your list. Go 1.16 released Posted Feb 18, 2021 16:36 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses) > higher kinded types, higher rank polymorphism, GADTs (or even ADTs!) None of that crap is needed in a normal language. I've personally came to conclusion that so called "advanced" type systems simply distract from the actual code and algorithms. > The fact that they need to put goroutines in the language (just like many other features, such as maps) just shows that the type system is useless, because these things should be implemented as libraries. No. Goroutines are fundamental to Go runtime and any library implementation (e.g. fibers in C++) would be inferior. > Bullshit! The simplest code is the code you don't need to write, and hence any kind of boilerplate makes code *less* simple. It's a completely unnecessary distraction. That's not true. Boilerplate code makes it a bit more verbose, but not at all harder to follow. Go 1.16 released Posted Feb 18, 2021 16:39 UTC (Thu) by HelloWorld (guest, #56129) [Link] (2 responses) > None of that crap is needed in a normal language. None of your crap is needed in this forum either. Stop here Posted Feb 18, 2021 17:03 UTC (Thu) by corbet (editor, #1) [Link] (1 responses) This is the sort of stuff we really don't need here. I'll ask you — yet again! — to desist. Stop here Posted Feb 18, 2021 17:20 UTC (Thu) by HelloWorld (guest, #56129) [Link] And yet again you ignore the context of my comment and blame me for other people's attacks. Getting tired of this… Go 1.16 released Posted Feb 19, 2021 1:07 UTC (Fri) by togga (subscriber, #53103) [Link] (2 responses) "Yes, things were simpler in the 60s, because the problems were simpler back then." This was deep. Are you talking of an entropy increase over time here? How exactly do you think that higher abstractions and generics is a better fit to meet your perceived "problem domain" evolution? I've seen too many projects get stuck in their own higher order abstractions to believe you. Go 1.16 released Posted Feb 19, 2021 14:14 UTC (Fri) by HelloWorld (guest, #56129) [Link] > This was deep. I think it's a trivial observation. There's a reason why software is getting larger and larger every year that passes. > I've seen too many projects get stuck in their own higher order abstractions to believe you. Every feature can be abused. That doesn't tell you anything about a feature's utility, nor does it tell you anything about how those projects would have fared in a language like Go. Go 1.16 released Posted Feb 19, 2021 14:21 UTC (Fri) by mathstuf (subscriber, #69389) [Link] I don't know if I'd classify it as the GP did. I think it's probably more along the lines of "programmers in the 60's would have also done better with generics and such, but *compilers* were not sophisticated enough yet for such languages". Of course, once a language gets a toehold, it'll tend to snowball due to network effects. Personally, I'd say that it's now that compilers exist for sufficiently sophisticated, and useful, languages that the balance is shifting away from the incumbent's network effects (mainly because the incumbents are acknowledging the network effects and building bridges[1] instead of keeping a walled garden and expecting to boil the ocean on their quest to conquer the world). [1] That are reasonable to use. JNI has existed for how long, but is not easy to integrate with in general. Go 1.16 released Posted Feb 22, 2021 18:49 UTC (Mon) by mebrown (subscriber, #7960) [Link] (1 responses) > > goroutines > The fact that they need to put goroutines in the language (just like many other features, such as maps) just shows that the type system is useless, because these things should be implemented as libraries. Non-sequitur, ie. it does not follow. Why, exactly, does language support for goroutines say anything about the type system? From what I can see, these are completely orthogonal concepts that have nothing to do with one another. Having a mechanism built into the language to handle parallelism is a great step forward, regardless of the type system. Go 1.16 released Posted Feb 23, 2021 17:45 UTC (Tue) by HelloWorld (guest, #56129) [Link] > Why, exactly, does language support for goroutines say anything about the type system? From what I can see, these are completely orthogonal concepts that have nothing to do with one another. Goroutines are just cooperatively scheduled logical threads. This is an idea that can and has been implemented as a library, e. g. in the cats-effect library for the Scala programming language. The advantage is that as we learn more about how this abstraction is actually used, the implementation can be changed easily, whereas with Go you're stuck with whatever the language's designers decided. You can have different, competing implementations that come up with new ideas and learn from each other. And we can see this happening in real time: ZIO is now another Scala library that implements this feature (they call it Fibers) and has a vastly superior feature set when compared to cats-effect (e. g. ZIO STM). So yes, these topics are very much related. > Having a mechanism built into the language to handle parallelism is a great step forward, regardless of the type system. No, building stuff into the language is a step back towards the 60s. A programming language shouldn't be a collection of abstractions like maps, goroutines and channels. It should be a tool that enables programmers to build their own abstractions for the problems they need to solve, and to do so in a re-usable way. A powerful type system generally and generics specifically are crucial for this, and Go is a complete failure in that regard. Go 1.16 released Posted Feb 22, 2021 18:55 UTC (Mon) by mebrown (subscriber, #7960) [Link] (1 responses) > > People have complained that its type system is stuck in the 60's. But some things were simpler in the 60's > I'm so sick and tired of this argument. If you seriously have trouble coping with the “complexity” of generics, then you shouldn't be writing software, period. Yes, things were simpler in the 60s, because the problems were simpler back then. Using these ideas to solve today's problems is like a carpenter refusing to use power tools. Wow. This comment is insulting and dismissive of anybody with another opinion, showing few signs of maturity and no genuine desire to engage in a genuine debate. You seem to be saying, "I'm right. I'm smart. You're wrong and stupid." It's not possible to engage with this type of rhetoric in a productive manner or to engage in any productive debate on the merits of any particular language design choice. This is not an argument constructed by somebody who can effectively defend their position, and really serves no purpose other than trolling. And yet, you're going to act personally attacked and offended if somebody tries to call you on this. Go 1.16 released Posted Feb 22, 2021 19:22 UTC (Mon) by corbet (editor, #1) [Link] If at all possible, it would be nice to close down this conversation from all directions at this point. Can we please do that? Go 1.16 released Posted Feb 18, 2021 2:59 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses) > Still wondering why anyone would use this language for anything other than toy/hobby projects. Go's implementation is extremely high-quality, designed by actual practical engineers, not computer science theorists. Go 1.16 released Posted Feb 18, 2021 21:11 UTC (Thu) by xnor (guest, #125308) [Link] (3 responses) > Go's implementation is extremely high-quality, designed by actual practical engineers, not computer science theorists. Eh, what? Where've you been the past couple of years? When actual software engineers have made countless presentations about the many horrible design choices and flaws in the language after using it in anything ranging from hobby to huge corporate projects. Bad design choices and flaws including the IR, the plethora of issues with the type system, the error handling, the forced synchronous I/O, the mixed concurrency and parallelism, the memory model (with no safety which is just priceless given the two points before), new/make, the package management, GOPATH, slow and inconsistent APIs, GC issues in certain use cases... Even the most simple things that one would expect from a language created in the past decades were misdesigned. Also, have you missed some of the larger past releases where they worked on some of the stuff that's not unfixable? Please confirm that your comment was sarcastic. Go 1.16 released Posted Feb 18, 2021 21:21 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses) > Eh, what? Where've you been the past couple of years? Running multiple high-performance services in Go, so far I'm extremely impressed with it. > the forced synchronous I/O Whut? You can use epoll with Go just fine ( https://www.freecodecamp.org/news/million-websockets-and-... ). Regular IO in Go looks "synchronous" but in reality it's built on top of asynchronous IO. > GOPATH It's not used anymore, there's now a module system. > the memory model (with no safety which is just priceless given the two points before) Go actually doesn't have a formal memory model, mostly because nobody cares to write it up. > GC issues in certain use cases... GC in Go in my experience works way better than GC in Java. Even though Java GC has a much more complicated internals. > Even the most simple things that one would expect from a language created in the past decades were misdesigned. The only glaring mis-design is the lack of easy way to check for nil interface. Maybe also variable shadowing. But honestly, they are minor. Go 1.16 released Posted Feb 18, 2021 22:39 UTC (Thu) by xnor (guest, #125308) [Link] (1 responses) >Whut? You can use epoll with Go just fine Oh so to get high performance you must not use the "extremely high-quality, designed by practical engineers, not computer science theorists" designs and language features. I see. >Regular IO in Go looks "synchronous" That was the point. This "model" is forced upon the user, which in turn forces the user into concurrency/parallelism, which is ironic given that the "brilliant" (sarcasm) language design doesn't offer any safety in that regard. > It's not used anymore, there's now a module system. So it was not so good design after all, and not very practical despite being designed by practical engineers? >Go actually doesn't have a formal memory model Yeah, there's a chapter on it in the docs that points out some random pitfalls. That's pretty ridiculous. > The only glaring mis-design is the lack of easy way to check for nil interface. Maybe also variable shadowing. Yes but there are many other issues with the design. Maybe not subjectively glaring to everyone. The only thing that speaks for Go is Google's massive marketing machinery. Go 1.16 released Posted Feb 18, 2021 22:54 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] > Oh so to get high performance you must not use the "extremely high-quality, designed by practical engineers, not computer science theorists" designs and language features. I see. Golang can scale just fine. epoll() is needed for EXTREME scaling, like tens of millions connections per _server_. If you need mere hundreds of thousands then you don't need to bother. > That was the point. This "model" is forced upon the user, which in turn forces the user into concurrency/parallelism, which is ironic given that the "brilliant" (sarcasm) language design doesn't offer any safety in that regard. The new generics will allow more structured parallelism. Go is a bit low-level in concurrency, but it does have good validation tools (race detector). > So it was not so good design after all, and not very practical despite being designed by practical engineers? Whut? The GOPATH was a simple solution that allowed Go developers to gain real-world experience and then design a proper module system. And it's one of the best, with built-in support for repeatable builds and package notarization. On the subject of builds, I have a huge project in Go and I can build it within a couple of seconds. Resulting in a ready-to-run fully-static binary. I'm not aware of any other language that can do the same. > Yes but there are many other issues with the design. Maybe not subjectively glaring to everyone. Which ones? Please note, that verbosity is not an issue per se. > The only thing that speaks for Go is Google's massive marketing machinery. Apple has a comparable marketing machine, yet Swift is not particularly popular. C# has not gained acceptance outside of MS, etc. You actually need a good product for that. Go 1.16 released Posted Feb 18, 2021 7:13 UTC (Thu) by mti (subscriber, #5390) [Link] (8 responses) Two questions. What is bad with Go? I have only tried it a little but it seemed like a really good language. What language should you use instead? Go 1.16 released Posted Feb 18, 2021 9:38 UTC (Thu) by ibukanov (subscriber, #3942) [Link] (7 responses) Go is not good for low-level system programming. It’s GC and threading model makes things too abstract. Resent Go releases fixed few problems in that area, but still for system programming one better sticks to languages without runtime. Another problem is GUI. Realistically one cannot use Go for that. Surely there are bindings to various GUI frameworks, but they are awkward. But for implementing network services, the area Go was designed initially, Go is very good. Go 1.16 released Posted Feb 18, 2021 10:13 UTC (Thu) by mti (subscriber, #5390) [Link] (6 responses) Interesting. Exactly what do you mean by "low-level system programming"? I never fully understood what is meant by that expression. But I think I agree. One thing I tried to write in Go was a Lua interpreter. Both memory layout issues and the GC caused some hard to solve problems. It could be done but not as efficiently as in e.g. C or C++. But for the other 99 % of programs I write for Linux I believe Go could be an alternative. > better sticks to languages without runtime. Which leaves C, C++, and a lot of older/less common languages? Rust? I often use C but people always tell me that is wrong by definition ;-) Go 1.16 released Posted Feb 18, 2021 11:58 UTC (Thu) by Wol (subscriber, #4433) [Link] > Interesting. Exactly what do you mean by "low-level system programming"? I never fully understood what is meant by that expression. Imho "low level" means "close to the hardware". So a network card driver is low level programming. Assembly is a low level language. The trouble with programming close to the hardware with a high level language is the language tries to abstract away all the nitty gritty that the program is meant to be doing - "the hardware driver will deal with that - but I AM the hardware driver - oops!" That's all this fuss about C now - it still thinks its a low level language, but hardware has evolved ... Cheers, Wol Go 1.16 released Posted Feb 20, 2021 18:42 UTC (Sat) by ibukanov (subscriber, #3942) [Link] (4 responses) By system-level programming I meant code that needs precise control over threads, signals, various IPC mechanisms and system resources like file handles. As for modern languages without runtime Zig is interesting. Plus Swift does not need one. Surely it extensively uses reference counting and weak pointers, but it does not preclude precise control over system resources. Too bad Apple is not particularly interested in cross-platform support. Go 1.16 released Posted Feb 20, 2021 19:20 UTC (Sat) by mti (subscriber, #5390) [Link] (3 responses) Ok, I think I see what you mean. But it is not black and white, rather a grayscale. Go gives you much more control than e.g. Java but less than e.g. C. On Linux I seldom feel that I need that level of control. The only program I can think of is one that needed real time performance in the millisecond range. C++ seemed like a good compromise. We also do a lot of soft real time and then Java seems good enough. I would have preferred Go. But the language itself is not the only factor. You need to be able to find developers that know the language or you might need to know that the language (and developers) will be available in ten or twenty years. Zig and Swift are indeed interesting but I think I count them as "less common languages". Go 1.16 released Posted Feb 21, 2021 7:52 UTC (Sun) by edomaur (subscriber, #14520) [Link] (2 responses) For system programming, well, the language du jour seems to be Rust (which is a language I really like) but you have some choice around that with Zig, D-lang, Nim (which has an interesting python-like syntax) or Swift (but outside Apple it's not really supported, it seems) Go 1.16 released Posted Feb 21, 2021 17:16 UTC (Sun) by mathstuf (subscriber, #69389) [Link] (1 responses) There's support for compiling Swift for Linux with CMake. But I think part of the problem was that the only defined interface had been Xcode for the longest time. The command line `swiftc` was either undocumented or explicitly "unsupported; keep both pieces" territory. I *think* that has changed a bit, but I believe that is mostly external contributor work than Apple engineers on Apple time[1] (but I could be mis-remembering this). [1] Though non-Apple time is probably covered under some NDA/non-compete clause, so that seems unlikely too. Go 1.16 released Posted Feb 22, 2021 4:56 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] You can use Swift on Linux just fine, it's officially supported. But there aren't many useful libraries or bindings for it on anything but Apple. Go 1.16 released Posted Feb 22, 2021 18:39 UTC (Mon) by mebrown (subscriber, #7960) [Link] What is the purpose of your comment? What is it that you are trying to achieve? It's a language initially sponsored by google. It's currently successfully used in many very large projects. You can easily find the reasoning for any of those just by looking. Your comment just sets up a false narrative and sets up for trolling. As somebody who is currently using go for several medium to large projects internally, go occupies a niche that no other available language satisfies and is literally the only option to accomplish the very specific requirements *I* have, and it's not my responsibility to educate you. Attacking others for their language choice is just silly. Some info Posted Feb 20, 2021 13:20 UTC (Sat) by kunitz (subscriber, #3965) [Link] I have read here a number of misconceptions about Go. 1. epoll Go is using epoll under the hood. It is used for network sockets and since a few versions also for file io. Apparently it is so well hidden from users that people don't know that. See https://go.googlesource.com/go/+/go1.16/src/runtime/netpo... 2. Memory model Go has a memory model for seven years: https://golang.org/ref/mem 3. Generics The feature will be called type parameters and the specification can be found here: https://go.googlesource.com/proposal/+/refs/heads/master/... Work to support type parameters is currently in progress and there is a good chance it will be part of the release in a year from now. If you don't want that long you can experiment with the go2go tool. https://go.googlesource.com/go/+/refs/heads/dev.go2go/REA... Go 1.16 released Posted Feb 22, 2021 18:33 UTC (Mon) by mebrown (subscriber, #7960) [Link] I'm a fan on Hanlons Razor... "never attribute to malice that which is adequately explained by stupidity", but many of the comments are just so full of misinformation and outright incorrect details that this feels like an organized campaign on the order of the systemd debates of yore. I don't quite get why somebody isn't allowed to like a language without getting harassed. This is downright silly.
Posted Feb 17, 2021 19:38 UTC (Wed) by benhoyt (subscriber, #138463) [Link]
Posted Feb 18, 2021 0:11 UTC (Thu) by xnor (guest, #125308) [Link] (29 responses)
Go 1.16 released Posted Feb 18, 2021 0:43 UTC (Thu) by HelloWorld (guest, #56129) [Link] Correct, it's a horribly designed language that ignored most of what happened in programming language design in the last 50 years. It really is based on ideas from the 60s. That said, it does compile fast, and everyone who ever worked on a significant Scala, C++, Haskell or Rust codebase knows that this is a real advantage. Go 1.16 released Posted Feb 18, 2021 1:31 UTC (Thu) by benhoyt (subscriber, #138463) [Link] (12 responses) Trollish comment, but I'll bite. :-) People have said the same thing about languages like Python, but that seems to be used for some quite large projects. Go is used (quite effectively) for some very large projects: Docker, Kubernetes, Hashicorp's tools, Juju, CockroachDB, Hugo, Traefik, Caddy (more here). I personally like it for large projects due to its lightweight static typing (didn't feel too heavy coming from Python), unique take on interfaces, C-like size of the language, goroutines, great standard library, excellent tooling (including a fast compiler), and the community's focus on fewer dependencies. People have complained that its type system is stuck in the 60's. But some things were simpler in the 60's. :-) Yes, sometimes nil pointers are a bit of a pain, and error handling can be boilerplatey, but it keeps things simple and explicit, and the simplicity helps keep the tooling simple and the compiler fast, so it's a pragmatic win. Go 1.16 released Posted Feb 18, 2021 8:58 UTC (Thu) by HelloWorld (guest, #56129) [Link] (11 responses) > People have said the same thing about languages like Python, but that seems to be used for some quite large projects. Yes, and these large projects are often quite buggy. Personally I can't understand how anybody can still defend dynamic typing at this point. It inherently makes software unmaintainable, because you never know what the data you're dealing with looks like, and your tools also don't, e. g. code completion doesn't work. Yes, there's mypy and all that, and it's useless – you can't retrofit this sort of stuff onto an existing culture of programmers. > Go is used (quite effectively) for some very large projects Yeah, so what? People are using horrible languages to write useful software all the time. Great software has been written in C and PHP, but that doesn't make these languages any less crappy. The question you need to answer to judge a programming language isn't how much great software has been written in it. It is how good that software would have been if it had been written in a different languagage, assuming that the developers were equally skilled with that language. > I personally like it for large projects due to its lightweight static typing What is “lightweight” supposed to mean in a type system context? Go's type system is atrocious. There is no excuse for not having generics in 2021. And yes, apparently they're going to add them, and that doesn't fix the problem *at all* because then you still don't have higher kinded types, higher rank polymorphism, GADTs (or even ADTs!) and all the other stuff that modern type systems have had for years. > goroutines The fact that they need to put goroutines in the language (just like many other features, such as maps) just shows that the type system is useless, because these things should be implemented as libraries. > People have complained that its type system is stuck in the 60's. But some things were simpler in the 60's I'm so sick and tired of this argument. If you seriously have trouble coping with the “complexity” of generics, then you shouldn't be writing software, period. Yes, things were simpler in the 60s, because the problems were simpler back then. Using these ideas to solve today's problems is like a carpenter refusing to use power tools. > Yes, sometimes nil pointers are a bit of a pain, and error handling can be boilerplatey, but it keeps things simple and explicit Bullshit! The simplest code is the code you don't need to write, and hence any kind of boilerplate makes code *less* simple. It's a completely unnecessary distraction. > the simplicity helps keep […] the compiler fast I believe this to be the only valid argument in your list. Go 1.16 released Posted Feb 18, 2021 16:36 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses) > higher kinded types, higher rank polymorphism, GADTs (or even ADTs!) None of that crap is needed in a normal language. I've personally came to conclusion that so called "advanced" type systems simply distract from the actual code and algorithms. > The fact that they need to put goroutines in the language (just like many other features, such as maps) just shows that the type system is useless, because these things should be implemented as libraries. No. Goroutines are fundamental to Go runtime and any library implementation (e.g. fibers in C++) would be inferior. > Bullshit! The simplest code is the code you don't need to write, and hence any kind of boilerplate makes code *less* simple. It's a completely unnecessary distraction. That's not true. Boilerplate code makes it a bit more verbose, but not at all harder to follow. Go 1.16 released Posted Feb 18, 2021 16:39 UTC (Thu) by HelloWorld (guest, #56129) [Link] (2 responses) > None of that crap is needed in a normal language. None of your crap is needed in this forum either. Stop here Posted Feb 18, 2021 17:03 UTC (Thu) by corbet (editor, #1) [Link] (1 responses) This is the sort of stuff we really don't need here. I'll ask you — yet again! — to desist. Stop here Posted Feb 18, 2021 17:20 UTC (Thu) by HelloWorld (guest, #56129) [Link] And yet again you ignore the context of my comment and blame me for other people's attacks. Getting tired of this… Go 1.16 released Posted Feb 19, 2021 1:07 UTC (Fri) by togga (subscriber, #53103) [Link] (2 responses) "Yes, things were simpler in the 60s, because the problems were simpler back then." This was deep. Are you talking of an entropy increase over time here? How exactly do you think that higher abstractions and generics is a better fit to meet your perceived "problem domain" evolution? I've seen too many projects get stuck in their own higher order abstractions to believe you. Go 1.16 released Posted Feb 19, 2021 14:14 UTC (Fri) by HelloWorld (guest, #56129) [Link] > This was deep. I think it's a trivial observation. There's a reason why software is getting larger and larger every year that passes. > I've seen too many projects get stuck in their own higher order abstractions to believe you. Every feature can be abused. That doesn't tell you anything about a feature's utility, nor does it tell you anything about how those projects would have fared in a language like Go. Go 1.16 released Posted Feb 19, 2021 14:21 UTC (Fri) by mathstuf (subscriber, #69389) [Link] I don't know if I'd classify it as the GP did. I think it's probably more along the lines of "programmers in the 60's would have also done better with generics and such, but *compilers* were not sophisticated enough yet for such languages". Of course, once a language gets a toehold, it'll tend to snowball due to network effects. Personally, I'd say that it's now that compilers exist for sufficiently sophisticated, and useful, languages that the balance is shifting away from the incumbent's network effects (mainly because the incumbents are acknowledging the network effects and building bridges[1] instead of keeping a walled garden and expecting to boil the ocean on their quest to conquer the world). [1] That are reasonable to use. JNI has existed for how long, but is not easy to integrate with in general. Go 1.16 released Posted Feb 22, 2021 18:49 UTC (Mon) by mebrown (subscriber, #7960) [Link] (1 responses) > > goroutines > The fact that they need to put goroutines in the language (just like many other features, such as maps) just shows that the type system is useless, because these things should be implemented as libraries. Non-sequitur, ie. it does not follow. Why, exactly, does language support for goroutines say anything about the type system? From what I can see, these are completely orthogonal concepts that have nothing to do with one another. Having a mechanism built into the language to handle parallelism is a great step forward, regardless of the type system. Go 1.16 released Posted Feb 23, 2021 17:45 UTC (Tue) by HelloWorld (guest, #56129) [Link] > Why, exactly, does language support for goroutines say anything about the type system? From what I can see, these are completely orthogonal concepts that have nothing to do with one another. Goroutines are just cooperatively scheduled logical threads. This is an idea that can and has been implemented as a library, e. g. in the cats-effect library for the Scala programming language. The advantage is that as we learn more about how this abstraction is actually used, the implementation can be changed easily, whereas with Go you're stuck with whatever the language's designers decided. You can have different, competing implementations that come up with new ideas and learn from each other. And we can see this happening in real time: ZIO is now another Scala library that implements this feature (they call it Fibers) and has a vastly superior feature set when compared to cats-effect (e. g. ZIO STM). So yes, these topics are very much related. > Having a mechanism built into the language to handle parallelism is a great step forward, regardless of the type system. No, building stuff into the language is a step back towards the 60s. A programming language shouldn't be a collection of abstractions like maps, goroutines and channels. It should be a tool that enables programmers to build their own abstractions for the problems they need to solve, and to do so in a re-usable way. A powerful type system generally and generics specifically are crucial for this, and Go is a complete failure in that regard. Go 1.16 released Posted Feb 22, 2021 18:55 UTC (Mon) by mebrown (subscriber, #7960) [Link] (1 responses) > > People have complained that its type system is stuck in the 60's. But some things were simpler in the 60's > I'm so sick and tired of this argument. If you seriously have trouble coping with the “complexity” of generics, then you shouldn't be writing software, period. Yes, things were simpler in the 60s, because the problems were simpler back then. Using these ideas to solve today's problems is like a carpenter refusing to use power tools. Wow. This comment is insulting and dismissive of anybody with another opinion, showing few signs of maturity and no genuine desire to engage in a genuine debate. You seem to be saying, "I'm right. I'm smart. You're wrong and stupid." It's not possible to engage with this type of rhetoric in a productive manner or to engage in any productive debate on the merits of any particular language design choice. This is not an argument constructed by somebody who can effectively defend their position, and really serves no purpose other than trolling. And yet, you're going to act personally attacked and offended if somebody tries to call you on this. Go 1.16 released Posted Feb 22, 2021 19:22 UTC (Mon) by corbet (editor, #1) [Link] If at all possible, it would be nice to close down this conversation from all directions at this point. Can we please do that? Go 1.16 released Posted Feb 18, 2021 2:59 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses) > Still wondering why anyone would use this language for anything other than toy/hobby projects. Go's implementation is extremely high-quality, designed by actual practical engineers, not computer science theorists. Go 1.16 released Posted Feb 18, 2021 21:11 UTC (Thu) by xnor (guest, #125308) [Link] (3 responses) > Go's implementation is extremely high-quality, designed by actual practical engineers, not computer science theorists. Eh, what? Where've you been the past couple of years? When actual software engineers have made countless presentations about the many horrible design choices and flaws in the language after using it in anything ranging from hobby to huge corporate projects. Bad design choices and flaws including the IR, the plethora of issues with the type system, the error handling, the forced synchronous I/O, the mixed concurrency and parallelism, the memory model (with no safety which is just priceless given the two points before), new/make, the package management, GOPATH, slow and inconsistent APIs, GC issues in certain use cases... Even the most simple things that one would expect from a language created in the past decades were misdesigned. Also, have you missed some of the larger past releases where they worked on some of the stuff that's not unfixable? Please confirm that your comment was sarcastic. Go 1.16 released Posted Feb 18, 2021 21:21 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses) > Eh, what? Where've you been the past couple of years? Running multiple high-performance services in Go, so far I'm extremely impressed with it. > the forced synchronous I/O Whut? You can use epoll with Go just fine ( https://www.freecodecamp.org/news/million-websockets-and-... ). Regular IO in Go looks "synchronous" but in reality it's built on top of asynchronous IO. > GOPATH It's not used anymore, there's now a module system. > the memory model (with no safety which is just priceless given the two points before) Go actually doesn't have a formal memory model, mostly because nobody cares to write it up. > GC issues in certain use cases... GC in Go in my experience works way better than GC in Java. Even though Java GC has a much more complicated internals. > Even the most simple things that one would expect from a language created in the past decades were misdesigned. The only glaring mis-design is the lack of easy way to check for nil interface. Maybe also variable shadowing. But honestly, they are minor. Go 1.16 released Posted Feb 18, 2021 22:39 UTC (Thu) by xnor (guest, #125308) [Link] (1 responses) >Whut? You can use epoll with Go just fine Oh so to get high performance you must not use the "extremely high-quality, designed by practical engineers, not computer science theorists" designs and language features. I see. >Regular IO in Go looks "synchronous" That was the point. This "model" is forced upon the user, which in turn forces the user into concurrency/parallelism, which is ironic given that the "brilliant" (sarcasm) language design doesn't offer any safety in that regard. > It's not used anymore, there's now a module system. So it was not so good design after all, and not very practical despite being designed by practical engineers? >Go actually doesn't have a formal memory model Yeah, there's a chapter on it in the docs that points out some random pitfalls. That's pretty ridiculous. > The only glaring mis-design is the lack of easy way to check for nil interface. Maybe also variable shadowing. Yes but there are many other issues with the design. Maybe not subjectively glaring to everyone. The only thing that speaks for Go is Google's massive marketing machinery. Go 1.16 released Posted Feb 18, 2021 22:54 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] > Oh so to get high performance you must not use the "extremely high-quality, designed by practical engineers, not computer science theorists" designs and language features. I see. Golang can scale just fine. epoll() is needed for EXTREME scaling, like tens of millions connections per _server_. If you need mere hundreds of thousands then you don't need to bother. > That was the point. This "model" is forced upon the user, which in turn forces the user into concurrency/parallelism, which is ironic given that the "brilliant" (sarcasm) language design doesn't offer any safety in that regard. The new generics will allow more structured parallelism. Go is a bit low-level in concurrency, but it does have good validation tools (race detector). > So it was not so good design after all, and not very practical despite being designed by practical engineers? Whut? The GOPATH was a simple solution that allowed Go developers to gain real-world experience and then design a proper module system. And it's one of the best, with built-in support for repeatable builds and package notarization. On the subject of builds, I have a huge project in Go and I can build it within a couple of seconds. Resulting in a ready-to-run fully-static binary. I'm not aware of any other language that can do the same. > Yes but there are many other issues with the design. Maybe not subjectively glaring to everyone. Which ones? Please note, that verbosity is not an issue per se. > The only thing that speaks for Go is Google's massive marketing machinery. Apple has a comparable marketing machine, yet Swift is not particularly popular. C# has not gained acceptance outside of MS, etc. You actually need a good product for that. Go 1.16 released Posted Feb 18, 2021 7:13 UTC (Thu) by mti (subscriber, #5390) [Link] (8 responses) Two questions. What is bad with Go? I have only tried it a little but it seemed like a really good language. What language should you use instead? Go 1.16 released Posted Feb 18, 2021 9:38 UTC (Thu) by ibukanov (subscriber, #3942) [Link] (7 responses) Go is not good for low-level system programming. It’s GC and threading model makes things too abstract. Resent Go releases fixed few problems in that area, but still for system programming one better sticks to languages without runtime. Another problem is GUI. Realistically one cannot use Go for that. Surely there are bindings to various GUI frameworks, but they are awkward. But for implementing network services, the area Go was designed initially, Go is very good. Go 1.16 released Posted Feb 18, 2021 10:13 UTC (Thu) by mti (subscriber, #5390) [Link] (6 responses) Interesting. Exactly what do you mean by "low-level system programming"? I never fully understood what is meant by that expression. But I think I agree. One thing I tried to write in Go was a Lua interpreter. Both memory layout issues and the GC caused some hard to solve problems. It could be done but not as efficiently as in e.g. C or C++. But for the other 99 % of programs I write for Linux I believe Go could be an alternative. > better sticks to languages without runtime. Which leaves C, C++, and a lot of older/less common languages? Rust? I often use C but people always tell me that is wrong by definition ;-) Go 1.16 released Posted Feb 18, 2021 11:58 UTC (Thu) by Wol (subscriber, #4433) [Link] > Interesting. Exactly what do you mean by "low-level system programming"? I never fully understood what is meant by that expression. Imho "low level" means "close to the hardware". So a network card driver is low level programming. Assembly is a low level language. The trouble with programming close to the hardware with a high level language is the language tries to abstract away all the nitty gritty that the program is meant to be doing - "the hardware driver will deal with that - but I AM the hardware driver - oops!" That's all this fuss about C now - it still thinks its a low level language, but hardware has evolved ... Cheers, Wol Go 1.16 released Posted Feb 20, 2021 18:42 UTC (Sat) by ibukanov (subscriber, #3942) [Link] (4 responses) By system-level programming I meant code that needs precise control over threads, signals, various IPC mechanisms and system resources like file handles. As for modern languages without runtime Zig is interesting. Plus Swift does not need one. Surely it extensively uses reference counting and weak pointers, but it does not preclude precise control over system resources. Too bad Apple is not particularly interested in cross-platform support. Go 1.16 released Posted Feb 20, 2021 19:20 UTC (Sat) by mti (subscriber, #5390) [Link] (3 responses) Ok, I think I see what you mean. But it is not black and white, rather a grayscale. Go gives you much more control than e.g. Java but less than e.g. C. On Linux I seldom feel that I need that level of control. The only program I can think of is one that needed real time performance in the millisecond range. C++ seemed like a good compromise. We also do a lot of soft real time and then Java seems good enough. I would have preferred Go. But the language itself is not the only factor. You need to be able to find developers that know the language or you might need to know that the language (and developers) will be available in ten or twenty years. Zig and Swift are indeed interesting but I think I count them as "less common languages". Go 1.16 released Posted Feb 21, 2021 7:52 UTC (Sun) by edomaur (subscriber, #14520) [Link] (2 responses) For system programming, well, the language du jour seems to be Rust (which is a language I really like) but you have some choice around that with Zig, D-lang, Nim (which has an interesting python-like syntax) or Swift (but outside Apple it's not really supported, it seems) Go 1.16 released Posted Feb 21, 2021 17:16 UTC (Sun) by mathstuf (subscriber, #69389) [Link] (1 responses) There's support for compiling Swift for Linux with CMake. But I think part of the problem was that the only defined interface had been Xcode for the longest time. The command line `swiftc` was either undocumented or explicitly "unsupported; keep both pieces" territory. I *think* that has changed a bit, but I believe that is mostly external contributor work than Apple engineers on Apple time[1] (but I could be mis-remembering this). [1] Though non-Apple time is probably covered under some NDA/non-compete clause, so that seems unlikely too. Go 1.16 released Posted Feb 22, 2021 4:56 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] You can use Swift on Linux just fine, it's officially supported. But there aren't many useful libraries or bindings for it on anything but Apple. Go 1.16 released Posted Feb 22, 2021 18:39 UTC (Mon) by mebrown (subscriber, #7960) [Link] What is the purpose of your comment? What is it that you are trying to achieve? It's a language initially sponsored by google. It's currently successfully used in many very large projects. You can easily find the reasoning for any of those just by looking. Your comment just sets up a false narrative and sets up for trolling. As somebody who is currently using go for several medium to large projects internally, go occupies a niche that no other available language satisfies and is literally the only option to accomplish the very specific requirements *I* have, and it's not my responsibility to educate you. Attacking others for their language choice is just silly.
Posted Feb 18, 2021 0:43 UTC (Thu) by HelloWorld (guest, #56129) [Link]
That said, it does compile fast, and everyone who ever worked on a significant Scala, C++, Haskell or Rust codebase knows that this is a real advantage.
Posted Feb 18, 2021 1:31 UTC (Thu) by benhoyt (subscriber, #138463) [Link] (12 responses)
Trollish comment, but I'll bite. :-) People have said the same thing about languages like Python, but that seems to be used for some quite large projects.
Go is used (quite effectively) for some very large projects: Docker, Kubernetes, Hashicorp's tools, Juju, CockroachDB, Hugo, Traefik, Caddy (more here). I personally like it for large projects due to its lightweight static typing (didn't feel too heavy coming from Python), unique take on interfaces, C-like size of the language, goroutines, great standard library, excellent tooling (including a fast compiler), and the community's focus on fewer dependencies.
People have complained that its type system is stuck in the 60's. But some things were simpler in the 60's. :-) Yes, sometimes nil pointers are a bit of a pain, and error handling can be boilerplatey, but it keeps things simple and explicit, and the simplicity helps keep the tooling simple and the compiler fast, so it's a pragmatic win.
Go 1.16 released Posted Feb 18, 2021 8:58 UTC (Thu) by HelloWorld (guest, #56129) [Link] (11 responses) > People have said the same thing about languages like Python, but that seems to be used for some quite large projects. Yes, and these large projects are often quite buggy. Personally I can't understand how anybody can still defend dynamic typing at this point. It inherently makes software unmaintainable, because you never know what the data you're dealing with looks like, and your tools also don't, e. g. code completion doesn't work. Yes, there's mypy and all that, and it's useless – you can't retrofit this sort of stuff onto an existing culture of programmers. > Go is used (quite effectively) for some very large projects Yeah, so what? People are using horrible languages to write useful software all the time. Great software has been written in C and PHP, but that doesn't make these languages any less crappy. The question you need to answer to judge a programming language isn't how much great software has been written in it. It is how good that software would have been if it had been written in a different languagage, assuming that the developers were equally skilled with that language. > I personally like it for large projects due to its lightweight static typing What is “lightweight” supposed to mean in a type system context? Go's type system is atrocious. There is no excuse for not having generics in 2021. And yes, apparently they're going to add them, and that doesn't fix the problem *at all* because then you still don't have higher kinded types, higher rank polymorphism, GADTs (or even ADTs!) and all the other stuff that modern type systems have had for years. > goroutines The fact that they need to put goroutines in the language (just like many other features, such as maps) just shows that the type system is useless, because these things should be implemented as libraries. > People have complained that its type system is stuck in the 60's. But some things were simpler in the 60's I'm so sick and tired of this argument. If you seriously have trouble coping with the “complexity” of generics, then you shouldn't be writing software, period. Yes, things were simpler in the 60s, because the problems were simpler back then. Using these ideas to solve today's problems is like a carpenter refusing to use power tools. > Yes, sometimes nil pointers are a bit of a pain, and error handling can be boilerplatey, but it keeps things simple and explicit Bullshit! The simplest code is the code you don't need to write, and hence any kind of boilerplate makes code *less* simple. It's a completely unnecessary distraction. > the simplicity helps keep […] the compiler fast I believe this to be the only valid argument in your list. Go 1.16 released Posted Feb 18, 2021 16:36 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses) > higher kinded types, higher rank polymorphism, GADTs (or even ADTs!) None of that crap is needed in a normal language. I've personally came to conclusion that so called "advanced" type systems simply distract from the actual code and algorithms. > The fact that they need to put goroutines in the language (just like many other features, such as maps) just shows that the type system is useless, because these things should be implemented as libraries. No. Goroutines are fundamental to Go runtime and any library implementation (e.g. fibers in C++) would be inferior. > Bullshit! The simplest code is the code you don't need to write, and hence any kind of boilerplate makes code *less* simple. It's a completely unnecessary distraction. That's not true. Boilerplate code makes it a bit more verbose, but not at all harder to follow. Go 1.16 released Posted Feb 18, 2021 16:39 UTC (Thu) by HelloWorld (guest, #56129) [Link] (2 responses) > None of that crap is needed in a normal language. None of your crap is needed in this forum either. Stop here Posted Feb 18, 2021 17:03 UTC (Thu) by corbet (editor, #1) [Link] (1 responses) This is the sort of stuff we really don't need here. I'll ask you — yet again! — to desist. Stop here Posted Feb 18, 2021 17:20 UTC (Thu) by HelloWorld (guest, #56129) [Link] And yet again you ignore the context of my comment and blame me for other people's attacks. Getting tired of this… Go 1.16 released Posted Feb 19, 2021 1:07 UTC (Fri) by togga (subscriber, #53103) [Link] (2 responses) "Yes, things were simpler in the 60s, because the problems were simpler back then." This was deep. Are you talking of an entropy increase over time here? How exactly do you think that higher abstractions and generics is a better fit to meet your perceived "problem domain" evolution? I've seen too many projects get stuck in their own higher order abstractions to believe you. Go 1.16 released Posted Feb 19, 2021 14:14 UTC (Fri) by HelloWorld (guest, #56129) [Link] > This was deep. I think it's a trivial observation. There's a reason why software is getting larger and larger every year that passes. > I've seen too many projects get stuck in their own higher order abstractions to believe you. Every feature can be abused. That doesn't tell you anything about a feature's utility, nor does it tell you anything about how those projects would have fared in a language like Go. Go 1.16 released Posted Feb 19, 2021 14:21 UTC (Fri) by mathstuf (subscriber, #69389) [Link] I don't know if I'd classify it as the GP did. I think it's probably more along the lines of "programmers in the 60's would have also done better with generics and such, but *compilers* were not sophisticated enough yet for such languages". Of course, once a language gets a toehold, it'll tend to snowball due to network effects. Personally, I'd say that it's now that compilers exist for sufficiently sophisticated, and useful, languages that the balance is shifting away from the incumbent's network effects (mainly because the incumbents are acknowledging the network effects and building bridges[1] instead of keeping a walled garden and expecting to boil the ocean on their quest to conquer the world). [1] That are reasonable to use. JNI has existed for how long, but is not easy to integrate with in general. Go 1.16 released Posted Feb 22, 2021 18:49 UTC (Mon) by mebrown (subscriber, #7960) [Link] (1 responses) > > goroutines > The fact that they need to put goroutines in the language (just like many other features, such as maps) just shows that the type system is useless, because these things should be implemented as libraries. Non-sequitur, ie. it does not follow. Why, exactly, does language support for goroutines say anything about the type system? From what I can see, these are completely orthogonal concepts that have nothing to do with one another. Having a mechanism built into the language to handle parallelism is a great step forward, regardless of the type system. Go 1.16 released Posted Feb 23, 2021 17:45 UTC (Tue) by HelloWorld (guest, #56129) [Link] > Why, exactly, does language support for goroutines say anything about the type system? From what I can see, these are completely orthogonal concepts that have nothing to do with one another. Goroutines are just cooperatively scheduled logical threads. This is an idea that can and has been implemented as a library, e. g. in the cats-effect library for the Scala programming language. The advantage is that as we learn more about how this abstraction is actually used, the implementation can be changed easily, whereas with Go you're stuck with whatever the language's designers decided. You can have different, competing implementations that come up with new ideas and learn from each other. And we can see this happening in real time: ZIO is now another Scala library that implements this feature (they call it Fibers) and has a vastly superior feature set when compared to cats-effect (e. g. ZIO STM). So yes, these topics are very much related. > Having a mechanism built into the language to handle parallelism is a great step forward, regardless of the type system. No, building stuff into the language is a step back towards the 60s. A programming language shouldn't be a collection of abstractions like maps, goroutines and channels. It should be a tool that enables programmers to build their own abstractions for the problems they need to solve, and to do so in a re-usable way. A powerful type system generally and generics specifically are crucial for this, and Go is a complete failure in that regard. Go 1.16 released Posted Feb 22, 2021 18:55 UTC (Mon) by mebrown (subscriber, #7960) [Link] (1 responses) > > People have complained that its type system is stuck in the 60's. But some things were simpler in the 60's > I'm so sick and tired of this argument. If you seriously have trouble coping with the “complexity” of generics, then you shouldn't be writing software, period. Yes, things were simpler in the 60s, because the problems were simpler back then. Using these ideas to solve today's problems is like a carpenter refusing to use power tools. Wow. This comment is insulting and dismissive of anybody with another opinion, showing few signs of maturity and no genuine desire to engage in a genuine debate. You seem to be saying, "I'm right. I'm smart. You're wrong and stupid." It's not possible to engage with this type of rhetoric in a productive manner or to engage in any productive debate on the merits of any particular language design choice. This is not an argument constructed by somebody who can effectively defend their position, and really serves no purpose other than trolling. And yet, you're going to act personally attacked and offended if somebody tries to call you on this. Go 1.16 released Posted Feb 22, 2021 19:22 UTC (Mon) by corbet (editor, #1) [Link] If at all possible, it would be nice to close down this conversation from all directions at this point. Can we please do that?
Posted Feb 18, 2021 8:58 UTC (Thu) by HelloWorld (guest, #56129) [Link] (11 responses)
Yes, and these large projects are often quite buggy. Personally I can't understand how anybody can still defend dynamic typing at this point. It inherently makes software unmaintainable, because you never know what the data you're dealing with looks like, and your tools also don't, e. g. code completion doesn't work. Yes, there's mypy and all that, and it's useless – you can't retrofit this sort of stuff onto an existing culture of programmers.
> Go is used (quite effectively) for some very large projects
Yeah, so what? People are using horrible languages to write useful software all the time. Great software has been written in C and PHP, but that doesn't make these languages any less crappy. The question you need to answer to judge a programming language isn't how much great software has been written in it. It is how good that software would have been if it had been written in a different languagage, assuming that the developers were equally skilled with that language.
> I personally like it for large projects due to its lightweight static typing What is “lightweight” supposed to mean in a type system context? Go's type system is atrocious. There is no excuse for not having generics in 2021. And yes, apparently they're going to add them, and that doesn't fix the problem *at all* because then you still don't have higher kinded types, higher rank polymorphism, GADTs (or even ADTs!) and all the other stuff that modern type systems have had for years.
> goroutines The fact that they need to put goroutines in the language (just like many other features, such as maps) just shows that the type system is useless, because these things should be implemented as libraries.
> People have complained that its type system is stuck in the 60's. But some things were simpler in the 60's I'm so sick and tired of this argument. If you seriously have trouble coping with the “complexity” of generics, then you shouldn't be writing software, period. Yes, things were simpler in the 60s, because the problems were simpler back then. Using these ideas to solve today's problems is like a carpenter refusing to use power tools.
> Yes, sometimes nil pointers are a bit of a pain, and error handling can be boilerplatey, but it keeps things simple and explicit Bullshit! The simplest code is the code you don't need to write, and hence any kind of boilerplate makes code *less* simple. It's a completely unnecessary distraction.
> the simplicity helps keep […] the compiler fast I believe this to be the only valid argument in your list.
Go 1.16 released Posted Feb 18, 2021 16:36 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses) > higher kinded types, higher rank polymorphism, GADTs (or even ADTs!) None of that crap is needed in a normal language. I've personally came to conclusion that so called "advanced" type systems simply distract from the actual code and algorithms. > The fact that they need to put goroutines in the language (just like many other features, such as maps) just shows that the type system is useless, because these things should be implemented as libraries. No. Goroutines are fundamental to Go runtime and any library implementation (e.g. fibers in C++) would be inferior. > Bullshit! The simplest code is the code you don't need to write, and hence any kind of boilerplate makes code *less* simple. It's a completely unnecessary distraction. That's not true. Boilerplate code makes it a bit more verbose, but not at all harder to follow. Go 1.16 released Posted Feb 18, 2021 16:39 UTC (Thu) by HelloWorld (guest, #56129) [Link] (2 responses) > None of that crap is needed in a normal language. None of your crap is needed in this forum either. Stop here Posted Feb 18, 2021 17:03 UTC (Thu) by corbet (editor, #1) [Link] (1 responses) This is the sort of stuff we really don't need here. I'll ask you — yet again! — to desist. Stop here Posted Feb 18, 2021 17:20 UTC (Thu) by HelloWorld (guest, #56129) [Link] And yet again you ignore the context of my comment and blame me for other people's attacks. Getting tired of this… Go 1.16 released Posted Feb 19, 2021 1:07 UTC (Fri) by togga (subscriber, #53103) [Link] (2 responses) "Yes, things were simpler in the 60s, because the problems were simpler back then." This was deep. Are you talking of an entropy increase over time here? How exactly do you think that higher abstractions and generics is a better fit to meet your perceived "problem domain" evolution? I've seen too many projects get stuck in their own higher order abstractions to believe you. Go 1.16 released Posted Feb 19, 2021 14:14 UTC (Fri) by HelloWorld (guest, #56129) [Link] > This was deep. I think it's a trivial observation. There's a reason why software is getting larger and larger every year that passes. > I've seen too many projects get stuck in their own higher order abstractions to believe you. Every feature can be abused. That doesn't tell you anything about a feature's utility, nor does it tell you anything about how those projects would have fared in a language like Go. Go 1.16 released Posted Feb 19, 2021 14:21 UTC (Fri) by mathstuf (subscriber, #69389) [Link] I don't know if I'd classify it as the GP did. I think it's probably more along the lines of "programmers in the 60's would have also done better with generics and such, but *compilers* were not sophisticated enough yet for such languages". Of course, once a language gets a toehold, it'll tend to snowball due to network effects. Personally, I'd say that it's now that compilers exist for sufficiently sophisticated, and useful, languages that the balance is shifting away from the incumbent's network effects (mainly because the incumbents are acknowledging the network effects and building bridges[1] instead of keeping a walled garden and expecting to boil the ocean on their quest to conquer the world). [1] That are reasonable to use. JNI has existed for how long, but is not easy to integrate with in general. Go 1.16 released Posted Feb 22, 2021 18:49 UTC (Mon) by mebrown (subscriber, #7960) [Link] (1 responses) > > goroutines > The fact that they need to put goroutines in the language (just like many other features, such as maps) just shows that the type system is useless, because these things should be implemented as libraries. Non-sequitur, ie. it does not follow. Why, exactly, does language support for goroutines say anything about the type system? From what I can see, these are completely orthogonal concepts that have nothing to do with one another. Having a mechanism built into the language to handle parallelism is a great step forward, regardless of the type system. Go 1.16 released Posted Feb 23, 2021 17:45 UTC (Tue) by HelloWorld (guest, #56129) [Link] > Why, exactly, does language support for goroutines say anything about the type system? From what I can see, these are completely orthogonal concepts that have nothing to do with one another. Goroutines are just cooperatively scheduled logical threads. This is an idea that can and has been implemented as a library, e. g. in the cats-effect library for the Scala programming language. The advantage is that as we learn more about how this abstraction is actually used, the implementation can be changed easily, whereas with Go you're stuck with whatever the language's designers decided. You can have different, competing implementations that come up with new ideas and learn from each other. And we can see this happening in real time: ZIO is now another Scala library that implements this feature (they call it Fibers) and has a vastly superior feature set when compared to cats-effect (e. g. ZIO STM). So yes, these topics are very much related. > Having a mechanism built into the language to handle parallelism is a great step forward, regardless of the type system. No, building stuff into the language is a step back towards the 60s. A programming language shouldn't be a collection of abstractions like maps, goroutines and channels. It should be a tool that enables programmers to build their own abstractions for the problems they need to solve, and to do so in a re-usable way. A powerful type system generally and generics specifically are crucial for this, and Go is a complete failure in that regard. Go 1.16 released Posted Feb 22, 2021 18:55 UTC (Mon) by mebrown (subscriber, #7960) [Link] (1 responses) > > People have complained that its type system is stuck in the 60's. But some things were simpler in the 60's > I'm so sick and tired of this argument. If you seriously have trouble coping with the “complexity” of generics, then you shouldn't be writing software, period. Yes, things were simpler in the 60s, because the problems were simpler back then. Using these ideas to solve today's problems is like a carpenter refusing to use power tools. Wow. This comment is insulting and dismissive of anybody with another opinion, showing few signs of maturity and no genuine desire to engage in a genuine debate. You seem to be saying, "I'm right. I'm smart. You're wrong and stupid." It's not possible to engage with this type of rhetoric in a productive manner or to engage in any productive debate on the merits of any particular language design choice. This is not an argument constructed by somebody who can effectively defend their position, and really serves no purpose other than trolling. And yet, you're going to act personally attacked and offended if somebody tries to call you on this. Go 1.16 released Posted Feb 22, 2021 19:22 UTC (Mon) by corbet (editor, #1) [Link] If at all possible, it would be nice to close down this conversation from all directions at this point. Can we please do that?
Posted Feb 18, 2021 16:36 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)
> The fact that they need to put goroutines in the language (just like many other features, such as maps) just shows that the type system is useless, because these things should be implemented as libraries. No. Goroutines are fundamental to Go runtime and any library implementation (e.g. fibers in C++) would be inferior.
> Bullshit! The simplest code is the code you don't need to write, and hence any kind of boilerplate makes code *less* simple. It's a completely unnecessary distraction. That's not true. Boilerplate code makes it a bit more verbose, but not at all harder to follow.
Go 1.16 released Posted Feb 18, 2021 16:39 UTC (Thu) by HelloWorld (guest, #56129) [Link] (2 responses) > None of that crap is needed in a normal language. None of your crap is needed in this forum either. Stop here Posted Feb 18, 2021 17:03 UTC (Thu) by corbet (editor, #1) [Link] (1 responses) This is the sort of stuff we really don't need here. I'll ask you — yet again! — to desist. Stop here Posted Feb 18, 2021 17:20 UTC (Thu) by HelloWorld (guest, #56129) [Link] And yet again you ignore the context of my comment and blame me for other people's attacks. Getting tired of this…
Posted Feb 18, 2021 16:39 UTC (Thu) by HelloWorld (guest, #56129) [Link] (2 responses)
Stop here Posted Feb 18, 2021 17:03 UTC (Thu) by corbet (editor, #1) [Link] (1 responses) This is the sort of stuff we really don't need here. I'll ask you — yet again! — to desist. Stop here Posted Feb 18, 2021 17:20 UTC (Thu) by HelloWorld (guest, #56129) [Link] And yet again you ignore the context of my comment and blame me for other people's attacks. Getting tired of this…
Posted Feb 18, 2021 17:03 UTC (Thu) by corbet (editor, #1) [Link] (1 responses)
Stop here Posted Feb 18, 2021 17:20 UTC (Thu) by HelloWorld (guest, #56129) [Link] And yet again you ignore the context of my comment and blame me for other people's attacks. Getting tired of this…
Posted Feb 18, 2021 17:20 UTC (Thu) by HelloWorld (guest, #56129) [Link]
Posted Feb 19, 2021 1:07 UTC (Fri) by togga (subscriber, #53103) [Link] (2 responses)
This was deep. Are you talking of an entropy increase over time here? How exactly do you think that higher abstractions and generics is a better fit to meet your perceived "problem domain" evolution?
I've seen too many projects get stuck in their own higher order abstractions to believe you.
Go 1.16 released Posted Feb 19, 2021 14:14 UTC (Fri) by HelloWorld (guest, #56129) [Link] > This was deep. I think it's a trivial observation. There's a reason why software is getting larger and larger every year that passes. > I've seen too many projects get stuck in their own higher order abstractions to believe you. Every feature can be abused. That doesn't tell you anything about a feature's utility, nor does it tell you anything about how those projects would have fared in a language like Go. Go 1.16 released Posted Feb 19, 2021 14:21 UTC (Fri) by mathstuf (subscriber, #69389) [Link] I don't know if I'd classify it as the GP did. I think it's probably more along the lines of "programmers in the 60's would have also done better with generics and such, but *compilers* were not sophisticated enough yet for such languages". Of course, once a language gets a toehold, it'll tend to snowball due to network effects. Personally, I'd say that it's now that compilers exist for sufficiently sophisticated, and useful, languages that the balance is shifting away from the incumbent's network effects (mainly because the incumbents are acknowledging the network effects and building bridges[1] instead of keeping a walled garden and expecting to boil the ocean on their quest to conquer the world). [1] That are reasonable to use. JNI has existed for how long, but is not easy to integrate with in general.
Posted Feb 19, 2021 14:14 UTC (Fri) by HelloWorld (guest, #56129) [Link]
I think it's a trivial observation. There's a reason why software is getting larger and larger every year that passes.
> I've seen too many projects get stuck in their own higher order abstractions to believe you.
Every feature can be abused. That doesn't tell you anything about a feature's utility, nor does it tell you anything about how those projects would have fared in a language like Go.
Posted Feb 19, 2021 14:21 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
[1] That are reasonable to use. JNI has existed for how long, but is not easy to integrate with in general.
Posted Feb 22, 2021 18:49 UTC (Mon) by mebrown (subscriber, #7960) [Link] (1 responses)
Non-sequitur, ie. it does not follow.
Why, exactly, does language support for goroutines say anything about the type system? From what I can see, these are completely orthogonal concepts that have nothing to do with one another. Having a mechanism built into the language to handle parallelism is a great step forward, regardless of the type system.
Go 1.16 released Posted Feb 23, 2021 17:45 UTC (Tue) by HelloWorld (guest, #56129) [Link] > Why, exactly, does language support for goroutines say anything about the type system? From what I can see, these are completely orthogonal concepts that have nothing to do with one another. Goroutines are just cooperatively scheduled logical threads. This is an idea that can and has been implemented as a library, e. g. in the cats-effect library for the Scala programming language. The advantage is that as we learn more about how this abstraction is actually used, the implementation can be changed easily, whereas with Go you're stuck with whatever the language's designers decided. You can have different, competing implementations that come up with new ideas and learn from each other. And we can see this happening in real time: ZIO is now another Scala library that implements this feature (they call it Fibers) and has a vastly superior feature set when compared to cats-effect (e. g. ZIO STM). So yes, these topics are very much related. > Having a mechanism built into the language to handle parallelism is a great step forward, regardless of the type system. No, building stuff into the language is a step back towards the 60s. A programming language shouldn't be a collection of abstractions like maps, goroutines and channels. It should be a tool that enables programmers to build their own abstractions for the problems they need to solve, and to do so in a re-usable way. A powerful type system generally and generics specifically are crucial for this, and Go is a complete failure in that regard.
Posted Feb 23, 2021 17:45 UTC (Tue) by HelloWorld (guest, #56129) [Link]
Goroutines are just cooperatively scheduled logical threads. This is an idea that can and has been implemented as a library, e. g. in the cats-effect library for the Scala programming language. The advantage is that as we learn more about how this abstraction is actually used, the implementation can be changed easily, whereas with Go you're stuck with whatever the language's designers decided. You can have different, competing implementations that come up with new ideas and learn from each other. And we can see this happening in real time: ZIO is now another Scala library that implements this feature (they call it Fibers) and has a vastly superior feature set when compared to cats-effect (e. g. ZIO STM). So yes, these topics are very much related.
> Having a mechanism built into the language to handle parallelism is a great step forward, regardless of the type system. No, building stuff into the language is a step back towards the 60s. A programming language shouldn't be a collection of abstractions like maps, goroutines and channels. It should be a tool that enables programmers to build their own abstractions for the problems they need to solve, and to do so in a re-usable way. A powerful type system generally and generics specifically are crucial for this, and Go is a complete failure in that regard.
Posted Feb 22, 2021 18:55 UTC (Mon) by mebrown (subscriber, #7960) [Link] (1 responses)
Wow. This comment is insulting and dismissive of anybody with another opinion, showing few signs of maturity and no genuine desire to engage in a genuine debate. You seem to be saying, "I'm right. I'm smart. You're wrong and stupid." It's not possible to engage with this type of rhetoric in a productive manner or to engage in any productive debate on the merits of any particular language design choice. This is not an argument constructed by somebody who can effectively defend their position, and really serves no purpose other than trolling. And yet, you're going to act personally attacked and offended if somebody tries to call you on this.
Go 1.16 released Posted Feb 22, 2021 19:22 UTC (Mon) by corbet (editor, #1) [Link] If at all possible, it would be nice to close down this conversation from all directions at this point. Can we please do that?
Posted Feb 22, 2021 19:22 UTC (Mon) by corbet (editor, #1) [Link]
Posted Feb 18, 2021 2:59 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)
Go 1.16 released Posted Feb 18, 2021 21:11 UTC (Thu) by xnor (guest, #125308) [Link] (3 responses) > Go's implementation is extremely high-quality, designed by actual practical engineers, not computer science theorists. Eh, what? Where've you been the past couple of years? When actual software engineers have made countless presentations about the many horrible design choices and flaws in the language after using it in anything ranging from hobby to huge corporate projects. Bad design choices and flaws including the IR, the plethora of issues with the type system, the error handling, the forced synchronous I/O, the mixed concurrency and parallelism, the memory model (with no safety which is just priceless given the two points before), new/make, the package management, GOPATH, slow and inconsistent APIs, GC issues in certain use cases... Even the most simple things that one would expect from a language created in the past decades were misdesigned. Also, have you missed some of the larger past releases where they worked on some of the stuff that's not unfixable? Please confirm that your comment was sarcastic. Go 1.16 released Posted Feb 18, 2021 21:21 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses) > Eh, what? Where've you been the past couple of years? Running multiple high-performance services in Go, so far I'm extremely impressed with it. > the forced synchronous I/O Whut? You can use epoll with Go just fine ( https://www.freecodecamp.org/news/million-websockets-and-... ). Regular IO in Go looks "synchronous" but in reality it's built on top of asynchronous IO. > GOPATH It's not used anymore, there's now a module system. > the memory model (with no safety which is just priceless given the two points before) Go actually doesn't have a formal memory model, mostly because nobody cares to write it up. > GC issues in certain use cases... GC in Go in my experience works way better than GC in Java. Even though Java GC has a much more complicated internals. > Even the most simple things that one would expect from a language created in the past decades were misdesigned. The only glaring mis-design is the lack of easy way to check for nil interface. Maybe also variable shadowing. But honestly, they are minor. Go 1.16 released Posted Feb 18, 2021 22:39 UTC (Thu) by xnor (guest, #125308) [Link] (1 responses) >Whut? You can use epoll with Go just fine Oh so to get high performance you must not use the "extremely high-quality, designed by practical engineers, not computer science theorists" designs and language features. I see. >Regular IO in Go looks "synchronous" That was the point. This "model" is forced upon the user, which in turn forces the user into concurrency/parallelism, which is ironic given that the "brilliant" (sarcasm) language design doesn't offer any safety in that regard. > It's not used anymore, there's now a module system. So it was not so good design after all, and not very practical despite being designed by practical engineers? >Go actually doesn't have a formal memory model Yeah, there's a chapter on it in the docs that points out some random pitfalls. That's pretty ridiculous. > The only glaring mis-design is the lack of easy way to check for nil interface. Maybe also variable shadowing. Yes but there are many other issues with the design. Maybe not subjectively glaring to everyone. The only thing that speaks for Go is Google's massive marketing machinery. Go 1.16 released Posted Feb 18, 2021 22:54 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] > Oh so to get high performance you must not use the "extremely high-quality, designed by practical engineers, not computer science theorists" designs and language features. I see. Golang can scale just fine. epoll() is needed for EXTREME scaling, like tens of millions connections per _server_. If you need mere hundreds of thousands then you don't need to bother. > That was the point. This "model" is forced upon the user, which in turn forces the user into concurrency/parallelism, which is ironic given that the "brilliant" (sarcasm) language design doesn't offer any safety in that regard. The new generics will allow more structured parallelism. Go is a bit low-level in concurrency, but it does have good validation tools (race detector). > So it was not so good design after all, and not very practical despite being designed by practical engineers? Whut? The GOPATH was a simple solution that allowed Go developers to gain real-world experience and then design a proper module system. And it's one of the best, with built-in support for repeatable builds and package notarization. On the subject of builds, I have a huge project in Go and I can build it within a couple of seconds. Resulting in a ready-to-run fully-static binary. I'm not aware of any other language that can do the same. > Yes but there are many other issues with the design. Maybe not subjectively glaring to everyone. Which ones? Please note, that verbosity is not an issue per se. > The only thing that speaks for Go is Google's massive marketing machinery. Apple has a comparable marketing machine, yet Swift is not particularly popular. C# has not gained acceptance outside of MS, etc. You actually need a good product for that.
Posted Feb 18, 2021 21:11 UTC (Thu) by xnor (guest, #125308) [Link] (3 responses)
Even the most simple things that one would expect from a language created in the past decades were misdesigned. Also, have you missed some of the larger past releases where they worked on some of the stuff that's not unfixable?
Please confirm that your comment was sarcastic.
Go 1.16 released Posted Feb 18, 2021 21:21 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses) > Eh, what? Where've you been the past couple of years? Running multiple high-performance services in Go, so far I'm extremely impressed with it. > the forced synchronous I/O Whut? You can use epoll with Go just fine ( https://www.freecodecamp.org/news/million-websockets-and-... ). Regular IO in Go looks "synchronous" but in reality it's built on top of asynchronous IO. > GOPATH It's not used anymore, there's now a module system. > the memory model (with no safety which is just priceless given the two points before) Go actually doesn't have a formal memory model, mostly because nobody cares to write it up. > GC issues in certain use cases... GC in Go in my experience works way better than GC in Java. Even though Java GC has a much more complicated internals. > Even the most simple things that one would expect from a language created in the past decades were misdesigned. The only glaring mis-design is the lack of easy way to check for nil interface. Maybe also variable shadowing. But honestly, they are minor. Go 1.16 released Posted Feb 18, 2021 22:39 UTC (Thu) by xnor (guest, #125308) [Link] (1 responses) >Whut? You can use epoll with Go just fine Oh so to get high performance you must not use the "extremely high-quality, designed by practical engineers, not computer science theorists" designs and language features. I see. >Regular IO in Go looks "synchronous" That was the point. This "model" is forced upon the user, which in turn forces the user into concurrency/parallelism, which is ironic given that the "brilliant" (sarcasm) language design doesn't offer any safety in that regard. > It's not used anymore, there's now a module system. So it was not so good design after all, and not very practical despite being designed by practical engineers? >Go actually doesn't have a formal memory model Yeah, there's a chapter on it in the docs that points out some random pitfalls. That's pretty ridiculous. > The only glaring mis-design is the lack of easy way to check for nil interface. Maybe also variable shadowing. Yes but there are many other issues with the design. Maybe not subjectively glaring to everyone. The only thing that speaks for Go is Google's massive marketing machinery. Go 1.16 released Posted Feb 18, 2021 22:54 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] > Oh so to get high performance you must not use the "extremely high-quality, designed by practical engineers, not computer science theorists" designs and language features. I see. Golang can scale just fine. epoll() is needed for EXTREME scaling, like tens of millions connections per _server_. If you need mere hundreds of thousands then you don't need to bother. > That was the point. This "model" is forced upon the user, which in turn forces the user into concurrency/parallelism, which is ironic given that the "brilliant" (sarcasm) language design doesn't offer any safety in that regard. The new generics will allow more structured parallelism. Go is a bit low-level in concurrency, but it does have good validation tools (race detector). > So it was not so good design after all, and not very practical despite being designed by practical engineers? Whut? The GOPATH was a simple solution that allowed Go developers to gain real-world experience and then design a proper module system. And it's one of the best, with built-in support for repeatable builds and package notarization. On the subject of builds, I have a huge project in Go and I can build it within a couple of seconds. Resulting in a ready-to-run fully-static binary. I'm not aware of any other language that can do the same. > Yes but there are many other issues with the design. Maybe not subjectively glaring to everyone. Which ones? Please note, that verbosity is not an issue per se. > The only thing that speaks for Go is Google's massive marketing machinery. Apple has a comparable marketing machine, yet Swift is not particularly popular. C# has not gained acceptance outside of MS, etc. You actually need a good product for that.
Posted Feb 18, 2021 21:21 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)
> the forced synchronous I/O Whut? You can use epoll with Go just fine ( https://www.freecodecamp.org/news/million-websockets-and-... ).
Regular IO in Go looks "synchronous" but in reality it's built on top of asynchronous IO.
> GOPATH It's not used anymore, there's now a module system.
> the memory model (with no safety which is just priceless given the two points before) Go actually doesn't have a formal memory model, mostly because nobody cares to write it up.
> GC issues in certain use cases... GC in Go in my experience works way better than GC in Java. Even though Java GC has a much more complicated internals.
> Even the most simple things that one would expect from a language created in the past decades were misdesigned. The only glaring mis-design is the lack of easy way to check for nil interface. Maybe also variable shadowing.
But honestly, they are minor.
Go 1.16 released Posted Feb 18, 2021 22:39 UTC (Thu) by xnor (guest, #125308) [Link] (1 responses) >Whut? You can use epoll with Go just fine Oh so to get high performance you must not use the "extremely high-quality, designed by practical engineers, not computer science theorists" designs and language features. I see. >Regular IO in Go looks "synchronous" That was the point. This "model" is forced upon the user, which in turn forces the user into concurrency/parallelism, which is ironic given that the "brilliant" (sarcasm) language design doesn't offer any safety in that regard. > It's not used anymore, there's now a module system. So it was not so good design after all, and not very practical despite being designed by practical engineers? >Go actually doesn't have a formal memory model Yeah, there's a chapter on it in the docs that points out some random pitfalls. That's pretty ridiculous. > The only glaring mis-design is the lack of easy way to check for nil interface. Maybe also variable shadowing. Yes but there are many other issues with the design. Maybe not subjectively glaring to everyone. The only thing that speaks for Go is Google's massive marketing machinery. Go 1.16 released Posted Feb 18, 2021 22:54 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] > Oh so to get high performance you must not use the "extremely high-quality, designed by practical engineers, not computer science theorists" designs and language features. I see. Golang can scale just fine. epoll() is needed for EXTREME scaling, like tens of millions connections per _server_. If you need mere hundreds of thousands then you don't need to bother. > That was the point. This "model" is forced upon the user, which in turn forces the user into concurrency/parallelism, which is ironic given that the "brilliant" (sarcasm) language design doesn't offer any safety in that regard. The new generics will allow more structured parallelism. Go is a bit low-level in concurrency, but it does have good validation tools (race detector). > So it was not so good design after all, and not very practical despite being designed by practical engineers? Whut? The GOPATH was a simple solution that allowed Go developers to gain real-world experience and then design a proper module system. And it's one of the best, with built-in support for repeatable builds and package notarization. On the subject of builds, I have a huge project in Go and I can build it within a couple of seconds. Resulting in a ready-to-run fully-static binary. I'm not aware of any other language that can do the same. > Yes but there are many other issues with the design. Maybe not subjectively glaring to everyone. Which ones? Please note, that verbosity is not an issue per se. > The only thing that speaks for Go is Google's massive marketing machinery. Apple has a comparable marketing machine, yet Swift is not particularly popular. C# has not gained acceptance outside of MS, etc. You actually need a good product for that.
Posted Feb 18, 2021 22:39 UTC (Thu) by xnor (guest, #125308) [Link] (1 responses)
>Regular IO in Go looks "synchronous" That was the point. This "model" is forced upon the user, which in turn forces the user into concurrency/parallelism, which is ironic given that the "brilliant" (sarcasm) language design doesn't offer any safety in that regard.
> It's not used anymore, there's now a module system. So it was not so good design after all, and not very practical despite being designed by practical engineers?
>Go actually doesn't have a formal memory model Yeah, there's a chapter on it in the docs that points out some random pitfalls. That's pretty ridiculous.
> The only glaring mis-design is the lack of easy way to check for nil interface. Maybe also variable shadowing. Yes but there are many other issues with the design. Maybe not subjectively glaring to everyone.
The only thing that speaks for Go is Google's massive marketing machinery.
Go 1.16 released Posted Feb 18, 2021 22:54 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] > Oh so to get high performance you must not use the "extremely high-quality, designed by practical engineers, not computer science theorists" designs and language features. I see. Golang can scale just fine. epoll() is needed for EXTREME scaling, like tens of millions connections per _server_. If you need mere hundreds of thousands then you don't need to bother. > That was the point. This "model" is forced upon the user, which in turn forces the user into concurrency/parallelism, which is ironic given that the "brilliant" (sarcasm) language design doesn't offer any safety in that regard. The new generics will allow more structured parallelism. Go is a bit low-level in concurrency, but it does have good validation tools (race detector). > So it was not so good design after all, and not very practical despite being designed by practical engineers? Whut? The GOPATH was a simple solution that allowed Go developers to gain real-world experience and then design a proper module system. And it's one of the best, with built-in support for repeatable builds and package notarization. On the subject of builds, I have a huge project in Go and I can build it within a couple of seconds. Resulting in a ready-to-run fully-static binary. I'm not aware of any other language that can do the same. > Yes but there are many other issues with the design. Maybe not subjectively glaring to everyone. Which ones? Please note, that verbosity is not an issue per se. > The only thing that speaks for Go is Google's massive marketing machinery. Apple has a comparable marketing machine, yet Swift is not particularly popular. C# has not gained acceptance outside of MS, etc. You actually need a good product for that.
Posted Feb 18, 2021 22:54 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
If you need mere hundreds of thousands then you don't need to bother.
> That was the point. This "model" is forced upon the user, which in turn forces the user into concurrency/parallelism, which is ironic given that the "brilliant" (sarcasm) language design doesn't offer any safety in that regard. The new generics will allow more structured parallelism. Go is a bit low-level in concurrency, but it does have good validation tools (race detector).
> So it was not so good design after all, and not very practical despite being designed by practical engineers? Whut? The GOPATH was a simple solution that allowed Go developers to gain real-world experience and then design a proper module system. And it's one of the best, with built-in support for repeatable builds and package notarization.
On the subject of builds, I have a huge project in Go and I can build it within a couple of seconds. Resulting in a ready-to-run fully-static binary. I'm not aware of any other language that can do the same.
> Yes but there are many other issues with the design. Maybe not subjectively glaring to everyone. Which ones? Please note, that verbosity is not an issue per se.
> The only thing that speaks for Go is Google's massive marketing machinery. Apple has a comparable marketing machine, yet Swift is not particularly popular. C# has not gained acceptance outside of MS, etc.
You actually need a good product for that.
Posted Feb 18, 2021 7:13 UTC (Thu) by mti (subscriber, #5390) [Link] (8 responses)
What is bad with Go? I have only tried it a little but it seemed like a really good language.
What language should you use instead?
Go 1.16 released Posted Feb 18, 2021 9:38 UTC (Thu) by ibukanov (subscriber, #3942) [Link] (7 responses) Go is not good for low-level system programming. It’s GC and threading model makes things too abstract. Resent Go releases fixed few problems in that area, but still for system programming one better sticks to languages without runtime. Another problem is GUI. Realistically one cannot use Go for that. Surely there are bindings to various GUI frameworks, but they are awkward. But for implementing network services, the area Go was designed initially, Go is very good. Go 1.16 released Posted Feb 18, 2021 10:13 UTC (Thu) by mti (subscriber, #5390) [Link] (6 responses) Interesting. Exactly what do you mean by "low-level system programming"? I never fully understood what is meant by that expression. But I think I agree. One thing I tried to write in Go was a Lua interpreter. Both memory layout issues and the GC caused some hard to solve problems. It could be done but not as efficiently as in e.g. C or C++. But for the other 99 % of programs I write for Linux I believe Go could be an alternative. > better sticks to languages without runtime. Which leaves C, C++, and a lot of older/less common languages? Rust? I often use C but people always tell me that is wrong by definition ;-) Go 1.16 released Posted Feb 18, 2021 11:58 UTC (Thu) by Wol (subscriber, #4433) [Link] > Interesting. Exactly what do you mean by "low-level system programming"? I never fully understood what is meant by that expression. Imho "low level" means "close to the hardware". So a network card driver is low level programming. Assembly is a low level language. The trouble with programming close to the hardware with a high level language is the language tries to abstract away all the nitty gritty that the program is meant to be doing - "the hardware driver will deal with that - but I AM the hardware driver - oops!" That's all this fuss about C now - it still thinks its a low level language, but hardware has evolved ... Cheers, Wol Go 1.16 released Posted Feb 20, 2021 18:42 UTC (Sat) by ibukanov (subscriber, #3942) [Link] (4 responses) By system-level programming I meant code that needs precise control over threads, signals, various IPC mechanisms and system resources like file handles. As for modern languages without runtime Zig is interesting. Plus Swift does not need one. Surely it extensively uses reference counting and weak pointers, but it does not preclude precise control over system resources. Too bad Apple is not particularly interested in cross-platform support. Go 1.16 released Posted Feb 20, 2021 19:20 UTC (Sat) by mti (subscriber, #5390) [Link] (3 responses) Ok, I think I see what you mean. But it is not black and white, rather a grayscale. Go gives you much more control than e.g. Java but less than e.g. C. On Linux I seldom feel that I need that level of control. The only program I can think of is one that needed real time performance in the millisecond range. C++ seemed like a good compromise. We also do a lot of soft real time and then Java seems good enough. I would have preferred Go. But the language itself is not the only factor. You need to be able to find developers that know the language or you might need to know that the language (and developers) will be available in ten or twenty years. Zig and Swift are indeed interesting but I think I count them as "less common languages". Go 1.16 released Posted Feb 21, 2021 7:52 UTC (Sun) by edomaur (subscriber, #14520) [Link] (2 responses) For system programming, well, the language du jour seems to be Rust (which is a language I really like) but you have some choice around that with Zig, D-lang, Nim (which has an interesting python-like syntax) or Swift (but outside Apple it's not really supported, it seems) Go 1.16 released Posted Feb 21, 2021 17:16 UTC (Sun) by mathstuf (subscriber, #69389) [Link] (1 responses) There's support for compiling Swift for Linux with CMake. But I think part of the problem was that the only defined interface had been Xcode for the longest time. The command line `swiftc` was either undocumented or explicitly "unsupported; keep both pieces" territory. I *think* that has changed a bit, but I believe that is mostly external contributor work than Apple engineers on Apple time[1] (but I could be mis-remembering this). [1] Though non-Apple time is probably covered under some NDA/non-compete clause, so that seems unlikely too. Go 1.16 released Posted Feb 22, 2021 4:56 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] You can use Swift on Linux just fine, it's officially supported. But there aren't many useful libraries or bindings for it on anything but Apple.
Posted Feb 18, 2021 9:38 UTC (Thu) by ibukanov (subscriber, #3942) [Link] (7 responses)
Another problem is GUI. Realistically one cannot use Go for that. Surely there are bindings to various GUI frameworks, but they are awkward.
But for implementing network services, the area Go was designed initially, Go is very good.
Go 1.16 released Posted Feb 18, 2021 10:13 UTC (Thu) by mti (subscriber, #5390) [Link] (6 responses) Interesting. Exactly what do you mean by "low-level system programming"? I never fully understood what is meant by that expression. But I think I agree. One thing I tried to write in Go was a Lua interpreter. Both memory layout issues and the GC caused some hard to solve problems. It could be done but not as efficiently as in e.g. C or C++. But for the other 99 % of programs I write for Linux I believe Go could be an alternative. > better sticks to languages without runtime. Which leaves C, C++, and a lot of older/less common languages? Rust? I often use C but people always tell me that is wrong by definition ;-) Go 1.16 released Posted Feb 18, 2021 11:58 UTC (Thu) by Wol (subscriber, #4433) [Link] > Interesting. Exactly what do you mean by "low-level system programming"? I never fully understood what is meant by that expression. Imho "low level" means "close to the hardware". So a network card driver is low level programming. Assembly is a low level language. The trouble with programming close to the hardware with a high level language is the language tries to abstract away all the nitty gritty that the program is meant to be doing - "the hardware driver will deal with that - but I AM the hardware driver - oops!" That's all this fuss about C now - it still thinks its a low level language, but hardware has evolved ... Cheers, Wol Go 1.16 released Posted Feb 20, 2021 18:42 UTC (Sat) by ibukanov (subscriber, #3942) [Link] (4 responses) By system-level programming I meant code that needs precise control over threads, signals, various IPC mechanisms and system resources like file handles. As for modern languages without runtime Zig is interesting. Plus Swift does not need one. Surely it extensively uses reference counting and weak pointers, but it does not preclude precise control over system resources. Too bad Apple is not particularly interested in cross-platform support. Go 1.16 released Posted Feb 20, 2021 19:20 UTC (Sat) by mti (subscriber, #5390) [Link] (3 responses) Ok, I think I see what you mean. But it is not black and white, rather a grayscale. Go gives you much more control than e.g. Java but less than e.g. C. On Linux I seldom feel that I need that level of control. The only program I can think of is one that needed real time performance in the millisecond range. C++ seemed like a good compromise. We also do a lot of soft real time and then Java seems good enough. I would have preferred Go. But the language itself is not the only factor. You need to be able to find developers that know the language or you might need to know that the language (and developers) will be available in ten or twenty years. Zig and Swift are indeed interesting but I think I count them as "less common languages". Go 1.16 released Posted Feb 21, 2021 7:52 UTC (Sun) by edomaur (subscriber, #14520) [Link] (2 responses) For system programming, well, the language du jour seems to be Rust (which is a language I really like) but you have some choice around that with Zig, D-lang, Nim (which has an interesting python-like syntax) or Swift (but outside Apple it's not really supported, it seems) Go 1.16 released Posted Feb 21, 2021 17:16 UTC (Sun) by mathstuf (subscriber, #69389) [Link] (1 responses) There's support for compiling Swift for Linux with CMake. But I think part of the problem was that the only defined interface had been Xcode for the longest time. The command line `swiftc` was either undocumented or explicitly "unsupported; keep both pieces" territory. I *think* that has changed a bit, but I believe that is mostly external contributor work than Apple engineers on Apple time[1] (but I could be mis-remembering this). [1] Though non-Apple time is probably covered under some NDA/non-compete clause, so that seems unlikely too. Go 1.16 released Posted Feb 22, 2021 4:56 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] You can use Swift on Linux just fine, it's officially supported. But there aren't many useful libraries or bindings for it on anything but Apple.
Posted Feb 18, 2021 10:13 UTC (Thu) by mti (subscriber, #5390) [Link] (6 responses)
But I think I agree. One thing I tried to write in Go was a Lua interpreter. Both memory layout issues and the GC caused some hard to solve problems. It could be done but not as efficiently as in e.g. C or C++. But for the other 99 % of programs I write for Linux I believe Go could be an alternative.
> better sticks to languages without runtime.
Which leaves C, C++, and a lot of older/less common languages? Rust?
I often use C but people always tell me that is wrong by definition ;-)
Go 1.16 released Posted Feb 18, 2021 11:58 UTC (Thu) by Wol (subscriber, #4433) [Link] > Interesting. Exactly what do you mean by "low-level system programming"? I never fully understood what is meant by that expression. Imho "low level" means "close to the hardware". So a network card driver is low level programming. Assembly is a low level language. The trouble with programming close to the hardware with a high level language is the language tries to abstract away all the nitty gritty that the program is meant to be doing - "the hardware driver will deal with that - but I AM the hardware driver - oops!" That's all this fuss about C now - it still thinks its a low level language, but hardware has evolved ... Cheers, Wol Go 1.16 released Posted Feb 20, 2021 18:42 UTC (Sat) by ibukanov (subscriber, #3942) [Link] (4 responses) By system-level programming I meant code that needs precise control over threads, signals, various IPC mechanisms and system resources like file handles. As for modern languages without runtime Zig is interesting. Plus Swift does not need one. Surely it extensively uses reference counting and weak pointers, but it does not preclude precise control over system resources. Too bad Apple is not particularly interested in cross-platform support. Go 1.16 released Posted Feb 20, 2021 19:20 UTC (Sat) by mti (subscriber, #5390) [Link] (3 responses) Ok, I think I see what you mean. But it is not black and white, rather a grayscale. Go gives you much more control than e.g. Java but less than e.g. C. On Linux I seldom feel that I need that level of control. The only program I can think of is one that needed real time performance in the millisecond range. C++ seemed like a good compromise. We also do a lot of soft real time and then Java seems good enough. I would have preferred Go. But the language itself is not the only factor. You need to be able to find developers that know the language or you might need to know that the language (and developers) will be available in ten or twenty years. Zig and Swift are indeed interesting but I think I count them as "less common languages". Go 1.16 released Posted Feb 21, 2021 7:52 UTC (Sun) by edomaur (subscriber, #14520) [Link] (2 responses) For system programming, well, the language du jour seems to be Rust (which is a language I really like) but you have some choice around that with Zig, D-lang, Nim (which has an interesting python-like syntax) or Swift (but outside Apple it's not really supported, it seems) Go 1.16 released Posted Feb 21, 2021 17:16 UTC (Sun) by mathstuf (subscriber, #69389) [Link] (1 responses) There's support for compiling Swift for Linux with CMake. But I think part of the problem was that the only defined interface had been Xcode for the longest time. The command line `swiftc` was either undocumented or explicitly "unsupported; keep both pieces" territory. I *think* that has changed a bit, but I believe that is mostly external contributor work than Apple engineers on Apple time[1] (but I could be mis-remembering this). [1] Though non-Apple time is probably covered under some NDA/non-compete clause, so that seems unlikely too. Go 1.16 released Posted Feb 22, 2021 4:56 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] You can use Swift on Linux just fine, it's officially supported. But there aren't many useful libraries or bindings for it on anything but Apple.
Posted Feb 18, 2021 11:58 UTC (Thu) by Wol (subscriber, #4433) [Link]
Imho "low level" means "close to the hardware". So a network card driver is low level programming. Assembly is a low level language. The trouble with programming close to the hardware with a high level language is the language tries to abstract away all the nitty gritty that the program is meant to be doing - "the hardware driver will deal with that - but I AM the hardware driver - oops!"
That's all this fuss about C now - it still thinks its a low level language, but hardware has evolved ...
Cheers, Wol
Posted Feb 20, 2021 18:42 UTC (Sat) by ibukanov (subscriber, #3942) [Link] (4 responses)
As for modern languages without runtime Zig is interesting. Plus Swift does not need one. Surely it extensively uses reference counting and weak pointers, but it does not preclude precise control over system resources. Too bad Apple is not particularly interested in cross-platform support.
Go 1.16 released Posted Feb 20, 2021 19:20 UTC (Sat) by mti (subscriber, #5390) [Link] (3 responses) Ok, I think I see what you mean. But it is not black and white, rather a grayscale. Go gives you much more control than e.g. Java but less than e.g. C. On Linux I seldom feel that I need that level of control. The only program I can think of is one that needed real time performance in the millisecond range. C++ seemed like a good compromise. We also do a lot of soft real time and then Java seems good enough. I would have preferred Go. But the language itself is not the only factor. You need to be able to find developers that know the language or you might need to know that the language (and developers) will be available in ten or twenty years. Zig and Swift are indeed interesting but I think I count them as "less common languages". Go 1.16 released Posted Feb 21, 2021 7:52 UTC (Sun) by edomaur (subscriber, #14520) [Link] (2 responses) For system programming, well, the language du jour seems to be Rust (which is a language I really like) but you have some choice around that with Zig, D-lang, Nim (which has an interesting python-like syntax) or Swift (but outside Apple it's not really supported, it seems) Go 1.16 released Posted Feb 21, 2021 17:16 UTC (Sun) by mathstuf (subscriber, #69389) [Link] (1 responses) There's support for compiling Swift for Linux with CMake. But I think part of the problem was that the only defined interface had been Xcode for the longest time. The command line `swiftc` was either undocumented or explicitly "unsupported; keep both pieces" territory. I *think* that has changed a bit, but I believe that is mostly external contributor work than Apple engineers on Apple time[1] (but I could be mis-remembering this). [1] Though non-Apple time is probably covered under some NDA/non-compete clause, so that seems unlikely too. Go 1.16 released Posted Feb 22, 2021 4:56 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] You can use Swift on Linux just fine, it's officially supported. But there aren't many useful libraries or bindings for it on anything but Apple.
Posted Feb 20, 2021 19:20 UTC (Sat) by mti (subscriber, #5390) [Link] (3 responses)
On Linux I seldom feel that I need that level of control. The only program I can think of is one that needed real time performance in the millisecond range. C++ seemed like a good compromise. We also do a lot of soft real time and then Java seems good enough. I would have preferred Go. But the language itself is not the only factor. You need to be able to find developers that know the language or you might need to know that the language (and developers) will be available in ten or twenty years.
Zig and Swift are indeed interesting but I think I count them as "less common languages".
Go 1.16 released Posted Feb 21, 2021 7:52 UTC (Sun) by edomaur (subscriber, #14520) [Link] (2 responses) For system programming, well, the language du jour seems to be Rust (which is a language I really like) but you have some choice around that with Zig, D-lang, Nim (which has an interesting python-like syntax) or Swift (but outside Apple it's not really supported, it seems) Go 1.16 released Posted Feb 21, 2021 17:16 UTC (Sun) by mathstuf (subscriber, #69389) [Link] (1 responses) There's support for compiling Swift for Linux with CMake. But I think part of the problem was that the only defined interface had been Xcode for the longest time. The command line `swiftc` was either undocumented or explicitly "unsupported; keep both pieces" territory. I *think* that has changed a bit, but I believe that is mostly external contributor work than Apple engineers on Apple time[1] (but I could be mis-remembering this). [1] Though non-Apple time is probably covered under some NDA/non-compete clause, so that seems unlikely too. Go 1.16 released Posted Feb 22, 2021 4:56 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] You can use Swift on Linux just fine, it's officially supported. But there aren't many useful libraries or bindings for it on anything but Apple.
Posted Feb 21, 2021 7:52 UTC (Sun) by edomaur (subscriber, #14520) [Link] (2 responses)
Go 1.16 released Posted Feb 21, 2021 17:16 UTC (Sun) by mathstuf (subscriber, #69389) [Link] (1 responses) There's support for compiling Swift for Linux with CMake. But I think part of the problem was that the only defined interface had been Xcode for the longest time. The command line `swiftc` was either undocumented or explicitly "unsupported; keep both pieces" territory. I *think* that has changed a bit, but I believe that is mostly external contributor work than Apple engineers on Apple time[1] (but I could be mis-remembering this). [1] Though non-Apple time is probably covered under some NDA/non-compete clause, so that seems unlikely too. Go 1.16 released Posted Feb 22, 2021 4:56 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] You can use Swift on Linux just fine, it's officially supported. But there aren't many useful libraries or bindings for it on anything but Apple.
Posted Feb 21, 2021 17:16 UTC (Sun) by mathstuf (subscriber, #69389) [Link] (1 responses)
[1] Though non-Apple time is probably covered under some NDA/non-compete clause, so that seems unlikely too.
Go 1.16 released Posted Feb 22, 2021 4:56 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] You can use Swift on Linux just fine, it's officially supported. But there aren't many useful libraries or bindings for it on anything but Apple.
Posted Feb 22, 2021 4:56 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
Posted Feb 22, 2021 18:39 UTC (Mon) by mebrown (subscriber, #7960) [Link]
It's a language initially sponsored by google. It's currently successfully used in many very large projects. You can easily find the reasoning for any of those just by looking. Your comment just sets up a false narrative and sets up for trolling.
As somebody who is currently using go for several medium to large projects internally, go occupies a niche that no other available language satisfies and is literally the only option to accomplish the very specific requirements *I* have, and it's not my responsibility to educate you. Attacking others for their language choice is just silly.
Posted Feb 20, 2021 13:20 UTC (Sat) by kunitz (subscriber, #3965) [Link]
1. epoll
Go is using epoll under the hood. It is used for network sockets and since a few versions also for file io. Apparently it is so well hidden from users that people don't know that.
See https://go.googlesource.com/go/+/go1.16/src/runtime/netpo...
2. Memory model
Go has a memory model for seven years: https://golang.org/ref/mem
3. Generics
The feature will be called type parameters and the specification can be found here: https://go.googlesource.com/proposal/+/refs/heads/master/...
Work to support type parameters is currently in progress and there is a good chance it will be part of the release in a year from now. If you don't want that long you can experiment with the go2go tool.
https://go.googlesource.com/go/+/refs/heads/dev.go2go/REA...
Posted Feb 22, 2021 18:33 UTC (Mon) by mebrown (subscriber, #7960) [Link]
I don't quite get why somebody isn't allowed to like a language without getting harassed. This is downright silly.
Copyright © 2021, Eklektix, Inc. Comments and public postings are copyrighted by their creators. Linux is a registered trademark of Linus Torvalds
LWN