No, it's presentation software that's implemented via a website. The primary user of this software is the person giving the talk, not people on the internet. The fact that people on the internet can also see it is a bonus that comes with the choice of the implementation.
Complaining that this doesn't work on mobile is like complaining Powerpoint doesn't work on mobile.
The issue isn't describing what I see on Android. It's chopped off on the left and I can't zoom out. Not usable at all. As mentioned elsewhere, forcing the desktop view is better.
Looks like a very minor release. No changes to the language spec and the changes to the standard library are all marked "minor". The most significant thing is the deprecation of `godoc`'s command-line features in favor of `go doc` (maybe someone with more info could explain the difference between the tools or the rationale for having two similarly named tools and why the CLI features are moving from one and into the other?).
>Now that we have the cmd/go "go doc" CLI for getting documentation, does it make sense for x/tools/cmd/godoc to also have CLI support?
>I propose we delete x/tools/cmd/godoc's CLI support and keep it being a web-only tool. Users who want CLI support can use "go doc". Both are shipped with Go releases.
It looks like you're trying to point out an inconsistency with my post, but I'm not seeing it. My observation, "No changes to the language spec" is entirely consistent with my claim, "a very minor release" and your observation, "It's 1.11->1.12, not 1.11->2.0".
Is this a bad attempt at pedantry? “Minor” WRT version numbers doesn’t mean “boring” or “insignificant”. Go introduced modules in a minor version, for example. Other minor versions cut GC pause times considerably. Others improved compile times a bunch. It’s pretty clear that the aforementioned changes are all more significant/interesting than anything in 1.12.
The problem, at least on Safari, is that about 75% of each slide is outside the viewport, no matter what orientation. And pinch zoom doesn’t work, neither does scrolling by swiping.
They implement everything themselves, in part so you can build truly static libraries without paying the significant cgo tax.
The biggest thing they implemented themselves is effectively their own linux libc (including dns and networking stack).
This results in wonderful bugs like them not having a working POSIX Setuid [0] because that's implemented correctly in libc, not the linux syscall of the same name.
This release also contains the UserHomeDir function which is another example where they didn't use libc and thus implemented it incorrectly.
You have to justify using any outside libraries in the go stdlib because right now there are no required external dependencies, so adding one is a very high bar indeed.
I'm actually super excited about printing maps in sorted order. I have a CLI use case for this.
When I need a real language with a fleshed out type system I use Rust, but Go has been great for writing small CLIs and things where I'm the only developer. It's also been great for small fan out tasks. I do wish flags had a way to do subcommands that didn't involve a lot of boilerplate.
- no generics. Without generics you can't build reusable data structures or algorithms that are type safe. The only ones that are available are hard coded into the language.
- lacking sum types (enums), which is why you have to explicitly check every return value with if err != nil. Sum types enable useful patterns like Maybe, Either, etc.
- general wackiness, from a computer science perspective Golang bakes a lot of special cases into its semantics that could be handled by including fundamental types. If you want to do multi-value return, the sane thing is to use a tuple, which is a core data structure we all learn about in CS undergrad, and use that as a return type and have functions return a single value. This is how Python and Rust work. (Tuples are also useful in many other contexts). The Go way is to have a rule that a function can return multiple values from a function and receive them at a call site. It's not pattern matching, and its not tuples, it's just a special case that defies the mathematical model of a function (a mapping of a domain to a single codomain).
As someone who enjoys programming in both Go and Rust I find this sort of fanatical comment distressing.
Go makes different tradeoffs. Get over it.
Nobody has written anything as important as Kubernetes in Rust yet. I hope that someday somebody does write something worthwhile but please less of the fundamentalist attitude that had poisoned religion and politics.
A tuple is a type constructor. A multi value return is not a type. It’s a semantic hard coded into the language spec. If you have tuples, you don’t have to add that special case to the language. You can also type alias a tuple, store it as a value, and just generally treat it like any other type.
This is a strange list. The reasons for putting off generics have been made very clear. Fast compilation and simpler syntax are not unreasonable tradeoffs to make in exchange for waiting for a fast and simple generic syntax.
And your argument against multiple return values makes no sense. How is using a tuple type better (or even different, in practice)? And your pointing to the mathematical definition of a function is pointless. A function has a very different meaning in programming languages than it does in mathematics. Mapping a domain to a single co-domain is not what functions do in the vast majority of programs.
You can return (string, error), but then what? You can't send them over a chan (string, error) or append them to a [](string, error). You can work around this by defining a bunch of struct types, but that's exactly what multiple return values was trying to avoid, and making a human being read and write that boilerplate is far more expensive than having the compiler supply it.
So much this. Every time I want to make a function async, I have to write my 5010th `ErrorOr` struct to send over a channel. Even if they would only add the multiple return hack to channels, that would save me a bunch of pain.
You do not know what you are talking about. It is very clear (based on the above statements) that you have minimal, if zero real computer science education. Please stop commenting on things that you know nothing about. Not having generics / sum types, etc., do not disqualify Go, as those are merely semantic conveniences in other languages. Additionally, from real world experience (~6 years developing major systems with Go), I can attest that none of those features are necessary for a language, and actually their presence in a language would cause me to reevaluate said programming language. Go is a breath of fresh air that is badly needed. Please stop with un- or ill- informed FUD.
> You do not know what you are talking about. It is very clear (based on the above statements) that you have minimal, if zero real computer science education.
I don't know why you're attacking me personally. I went to a UC school with a great computer science program and have a masters degree... does that count?
> Not having generics / sum types, etc., do not disqualify Go, as those are merely semantic conveniences in other languages.
Sure, and Go is merely a collection of semantic conveniences over Brainfuck, it's Turing Complete, so what do we need Go for?
The point is that Go heavily limits a programmers ability to create new abstractions and write reusable algorithms. For writing glue code, cli tools, or web services, that's probably fine. But there's a purpose behind those pesky data structure and algorithms they teach you in school, and when you run into what I consider to be the "real problems" Go is not a "real language" that can tackle those problems without the same pain as Brainfuck.
> actually their presence in a language would cause me to reevaluate said programming language
This is completely ridiculous. I hope you realize this statement is completely ridiculous. Just because a language has something you don't understand or don't find useful doesn't disqualify it from being a better language than Go. You have your own blinders on.
> Go is a breath of fresh air that is badly needed.
Go appeals to the lowest common denominator. In fact, one of the goals was to come up with a language that new grads coming in to Google could easily pick up. It's designed to appeal to new people. This is fine, Go is a great language for a lot of small tasks. But as you grow as a developer, you need to tackle larger problems. Go is not a language that facilitates tackling larger problems.
> Please stop with un- or ill- informed FUD.
You certainly need a dose of skepticism. Radically following one language or one technology isn't a good move for an engineer. Go has flaws, and if you can't discuss them then you're not separating the technology from an argument from emotion.
It’s weird how I’ve managed to write so much reliable, production code at my work without “sum types” and “real generics”. Man, all those people who wrote OS kernels in C or mobile apps for iOS in Objective-C need to just throw away their work - it’s all garbage written in non-real programming languages.
So first of all, Apple invented a new language to replace Objective-C (they also added generics to Objective-C), you might have heard of it. Secondly, some kernels have already been written or partially written in C++ (the NT kernel for example). Of course, not many people are writing kernels, but those writing new kernels (fuschia, redox) are being written in either a mix of languages or a completely new language. Otherwise, older kernels like Linux were written decades ago in a very different landscape when other languages made little to no sense. Things have changed.
So your comment is kind of unsubstantiated. And as I said, things have changed, and things will change. We can either do as you imply and keep using C and languages without "sum types" and "real generics", and keep creating security vulnerabilities and broken software, moving at a snails pace because we have poor methods of reuse, or we can aspire to build better tools to build better software. I am squarely in the latter camp, I think we should aspire to keep evolving.
- in spite of theoretical weaknesses, Go empowers developers to get shit done, causing dreadful cognitive dissonance for academic programming linguists
I feel you, though. I was you some time ago. You need to let go of the feeling that programming languages are the most important thing in the world. Until you do, that feeling will just pull you down to a place where nothing's good enough.
> If you want to do multi-value return, the sane thing is to use a tuple, which is a core data structure we all learn about in CS undergrad, and use that as a return type and have functions return a single value
You could say the same about function argument lists--that functions should only take a tuple.
IME the reason some particular language only permits returning a single value is typically either (a) convention or (b) a reflection of implementation details.
60 comments
[ 3.1 ms ] story [ 116 ms ] threadI get that some websites might not scale well, but this just goes beyond that. :(
Complaining that this doesn't work on mobile is like complaining Powerpoint doesn't work on mobile.
Also, it is an issue: https://github.com/golang/go/issues/27026. Marked as "help wanted".
Interesting though, that iOS Safari is borked too. Did they just take wild guesses on the mobile css and hope for the best?
>Now that we have the cmd/go "go doc" CLI for getting documentation, does it make sense for x/tools/cmd/godoc to also have CLI support?
>I propose we delete x/tools/cmd/godoc's CLI support and keep it being a web-only tool. Users who want CLI support can use "go doc". Both are shipped with Go releases.
It's a deduplication of code and effort.
That's just an awful viewer at the end of the day, no ifs and buts about it.
The problem is I can only see about 50% of the slide, and pinch-to-zoom doesn’t work.
HUGE deal for large companies Possible for certain code patterns to bully the runtime Redesign the runtime to remove those edge cases
wow.
The biggest thing they implemented themselves is effectively their own linux libc (including dns and networking stack).
This results in wonderful bugs like them not having a working POSIX Setuid [0] because that's implemented correctly in libc, not the linux syscall of the same name. This release also contains the UserHomeDir function which is another example where they didn't use libc and thus implemented it incorrectly.
You have to justify using any outside libraries in the go stdlib because right now there are no required external dependencies, so adding one is a very high bar indeed.
[0]: https://github.com/golang/go/issues/1435
When I need a real language with a fleshed out type system I use Rust, but Go has been great for writing small CLIs and things where I'm the only developer. It's also been great for small fan out tasks. I do wish flags had a way to do subcommands that didn't involve a lot of boilerplate.
- lacking sum types (enums), which is why you have to explicitly check every return value with if err != nil. Sum types enable useful patterns like Maybe, Either, etc.
- general wackiness, from a computer science perspective Golang bakes a lot of special cases into its semantics that could be handled by including fundamental types. If you want to do multi-value return, the sane thing is to use a tuple, which is a core data structure we all learn about in CS undergrad, and use that as a return type and have functions return a single value. This is how Python and Rust work. (Tuples are also useful in many other contexts). The Go way is to have a rule that a function can return multiple values from a function and receive them at a call site. It's not pattern matching, and its not tuples, it's just a special case that defies the mathematical model of a function (a mapping of a domain to a single codomain).
Go makes different tradeoffs. Get over it.
Nobody has written anything as important as Kubernetes in Rust yet. I hope that someday somebody does write something worthwhile but please less of the fundamentalist attitude that had poisoned religion and politics.
Trade offs are one thing, defecencies are another.
And if you can think of a reason why hard coding multivalue return signatures would be better than a tuple type, then I’d like to hear it.
Those go softs are usually stable and easy to install. We have yet to use a rust developed program.
Usability matters, and the much much higher learning curve as played against rust.
And your argument against multiple return values makes no sense. How is using a tuple type better (or even different, in practice)? And your pointing to the mathematical definition of a function is pointless. A function has a very different meaning in programming languages than it does in mathematics. Mapping a domain to a single co-domain is not what functions do in the vast majority of programs.
I don't know why you're attacking me personally. I went to a UC school with a great computer science program and have a masters degree... does that count?
> Not having generics / sum types, etc., do not disqualify Go, as those are merely semantic conveniences in other languages.
Sure, and Go is merely a collection of semantic conveniences over Brainfuck, it's Turing Complete, so what do we need Go for?
The point is that Go heavily limits a programmers ability to create new abstractions and write reusable algorithms. For writing glue code, cli tools, or web services, that's probably fine. But there's a purpose behind those pesky data structure and algorithms they teach you in school, and when you run into what I consider to be the "real problems" Go is not a "real language" that can tackle those problems without the same pain as Brainfuck.
> actually their presence in a language would cause me to reevaluate said programming language
This is completely ridiculous. I hope you realize this statement is completely ridiculous. Just because a language has something you don't understand or don't find useful doesn't disqualify it from being a better language than Go. You have your own blinders on.
> Go is a breath of fresh air that is badly needed.
Go appeals to the lowest common denominator. In fact, one of the goals was to come up with a language that new grads coming in to Google could easily pick up. It's designed to appeal to new people. This is fine, Go is a great language for a lot of small tasks. But as you grow as a developer, you need to tackle larger problems. Go is not a language that facilitates tackling larger problems.
> Please stop with un- or ill- informed FUD.
You certainly need a dose of skepticism. Radically following one language or one technology isn't a good move for an engineer. Go has flaws, and if you can't discuss them then you're not separating the technology from an argument from emotion.
So your comment is kind of unsubstantiated. And as I said, things have changed, and things will change. We can either do as you imply and keep using C and languages without "sum types" and "real generics", and keep creating security vulnerabilities and broken software, moving at a snails pace because we have poor methods of reuse, or we can aspire to build better tools to build better software. I am squarely in the latter camp, I think we should aspire to keep evolving.
- in spite of theoretical weaknesses, Go empowers developers to get shit done, causing dreadful cognitive dissonance for academic programming linguists
I feel you, though. I was you some time ago. You need to let go of the feeling that programming languages are the most important thing in the world. Until you do, that feeling will just pull you down to a place where nothing's good enough.
You could say the same about function argument lists--that functions should only take a tuple.
IME the reason some particular language only permits returning a single value is typically either (a) convention or (b) a reflection of implementation details.