I'm on my iPhone and the slides are terrible to navigate on a mobile browser.
Yeah I came here to comment about that, too. It's surprising to me - I would have expected the Go team to have implemented/fixed that
The State of Go
131–140 of 402 posts
Re: The State of Go
#132I don't share some of the opinions I see in the comments here. I've recently started programming in Go and I am having a blast. Plus, I am making my systems faster and simpler with Go. I love concurrency in Go. I love the concept of Goroutines, the simple and intuitive use of Select. Channels still present a few mysteries here and there... But I'll get it at some point. But the n#1 thing for me in Go is: It's written…
I don't know. I feel like if I need something productive, I would go very high level like Python. In the VERY rare case Python is too slow, I would go really low level like rust. I don't see the interest for something that not really low level, but not realy high level either like Go. If concurrency is the main issue and is the niche I'm targeting, I would go Erlang or Elixir. I have a hard time finding any use case…
The target audience is people who don't know Elixir and Rust, have no time and not enough conceptual base to learn them in a reasonable time, and have to ship concurrent code, fast. Go is stupidly simple; this can also be an upside.
Python's concurrency story is much better in 3.5+ than in 2.x, but a lot of people use 2.x for various reasons.
Re: The State of Go
#133I don't share some of the opinions I see in the comments here. I've recently started programming in Go and I am having a blast. Plus, I am making my systems faster and simpler with Go. I love concurrency in Go. I love the concept of Goroutines, the simple and intuitive use of Select. Channels still present a few mysteries here and there... But I'll get it at some point. But the n#1 thing for me in Go is: It's written…
I really enjoy programming in golang, having recently taught quite a few people the language I am forever thankful for its simplicity.
This paired with vscode + click to see other peoples code is a great platform to get started with systems programming and tools development.
Can't thank the go developers enough.
Re: The State of Go
#134Earlier quoted context omitted.
Maps and folds are implicit loops. For some explicit is simpler.
No, maps are conversions between types containing other types. Maps are much more powerful than just doing something over an array in languages that support a functional style.
The original comment was comparing maps and folds to loops, not the general application of maps.
Re: The State of Go
#135I'm at FOSDEM where this talk was just given. Francesc was hilarious.
well thanks
I love your Just For Func videos! I wondered if you could make one explaining pointers in Go. No explanation I've found really settles in for me, and while I'm getting a 'feel' for them writing more code and getting feedback from the compiler, I'd like to find a good explanation of them. I'm asking you specifically because you have a really great way of explaining things, and a warm presentation style. Either way, thanks for all you've given through your talks and videos!
Re: The State of Go
#136I don't share some of the opinions I see in the comments here. I've recently started programming in Go and I am having a blast. Plus, I am making my systems faster and simpler with Go. I love concurrency in Go. I love the concept of Goroutines, the simple and intuitive use of Select. Channels still present a few mysteries here and there... But I'll get it at some point. But the n#1 thing for me in Go is: It's written…
Maybe it's because I don't have the "depth"
of some of the HN users, but Go feels great to me.
When I moved from Python to Go not only did my code become more safe, I actually became a better programmer. There are a lot of silly things that you can do in Python that you can justify saying "just this once!" or "it's only temporary!" that are much harder to do with Go. I started writing a lot less complicated functions that did different things with different types, and moved to writing simpler, single purpose functions whenever possible. This was great and I learned a lot.
Then I moved from Go to Haskell, and the same thing happened again.
Haskell makes you specify whether a type can be null or not. It has referential transparency, so you can't mutate variables as a side effect of a function. It has sum types, eg:
data User = Unauthenticated | Normal UserId | Admin UserId
Now there are downsides -- Go has a great standard library, and it's tooling is fantastic (even down to little things like gofmt). I'm not saying you'd have a better experience with Haskell, just that there are real reasons why someone wouldn't want to go back after trying a more featureful language than Go.
Re: The State of Go
#137IMO the Go goal is to be an enhancement of C. It is not as expressive as some existing languages (i.e., Go programs may be longer), but it is very good for translating clearly thought through logic into efficient machine code. It supports some of the features that original C lacks (networking, parallelism, channels, etc.), which to me is a very good thing. With minimal forethought this allows writing programs that ca…
In my experience writing go is very fast and reading go is also very fast. The language was designed to be very comfortable, and they did a great job with that. You sit down to write something and you don't have to think too much about the best way to tackle the problem, the lines of code just flow from your fingertips. There's mostly one way to do everything, which makes doing things easy.
Code review is much the same.
Re: The State of Go
#138I don't share some of the opinions I see in the comments here. I've recently started programming in Go and I am having a blast. Plus, I am making my systems faster and simpler with Go. I love concurrency in Go. I love the concept of Goroutines, the simple and intuitive use of Select. Channels still present a few mysteries here and there... But I'll get it at some point. But the n#1 thing for me in Go is: It's written…
I really enjoy programming in golang, having recently taught quite a few people the language I am forever thankful for its simplicity. This paired with vscode + click to see other peoples code is a great platform to get started with systems programming and tools development. Can't thank the go developers enough.
I also enjoy it, but just wanted to note that Go is not really a systems programming language, unless you mean "cloud/network systems".
Re: The State of Go
#139My impression is that Go is a language that was cobbled together to simplify the coding of some specific applications, such as simple servers. It lacks any kind of purity, is not the best choice for any specific task, but is just good enough for some (many?) tasks. And poor type safety! Frankly, I can't help being disappointed by how bland this language is, and I have zero interest in using it. Maybe because I like c…
It lacks any kind of purity
What language is pure anything? Even Smalltalk wasn't pure Objects. Programming languages are pretty complex. If you look deep enough, you'll find the leak in the abstractions.
Re: The State of Go
#140My impression is that Go is a language that was cobbled together to simplify the coding of some specific applications, such as simple servers. It lacks any kind of purity, is not the best choice for any specific task, but is just good enough for some (many?) tasks. And poor type safety! Frankly, I can't help being disappointed by how bland this language is, and I have zero interest in using it. Maybe because I like c…
I've always believed that blandness is the reason why the language was created. Google has a ton of developers working on a giant codebase. If Google were written in something interesting and complex (eg scala or ocaml) then some parts of the codebase would be remarkably complex while others would be simply a ton of library imports and then something procedural. Whether you are in the former or the later would be dev…
It's more than "bland." There's a whole lot of "just works" in the whole ecosystem.
Now, say you're a Google exec, you know you're losing a ton of developer hours as people ramp up
Why wouldn't ramp-up time be a big company's most significant cost?