Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Seven years of Go

blog.golang.org

Post reply on HN
Print view View original

251–260 of 318 posts

Re: Seven years of Go

#251

Post by weberc2 »

Manishearth wrote: post #233
weberc2 wrote: post #173

Earlier quoted context omitted.

> such as wasting memory Granted, but I'll happily trade a few bytes of stack for zero allocs in many cases. > rather than benefiting from overlapping storage ala Rust enums or C tagged unions Of course, but we don't have those in Go, do we? > as well as losing type safety Tagged structs are not meaningfully less type safe than interfaces. > one has to manually remember which (groups of) fields correspond to which ta…

> Tagged structs are not meaningfully less type safe than interfaces. Of course they are. What if you read from or write to the wrong field? > Use an enum for the tag Your example has one contained type per variant. In Rust it is common to have an enum like enum Foo { Variant1(String, u8, Vec ), Variant2(u8), Variant3(String), Variant4(f32), Variant6(f32) Variant5(bool, bool, String) } Naming tags for something like…

> Of course they are. What if you read from or write to the wrong field?

This falls under the rubric of "not meaningfully less type safe". This data structure is central in a large project of mine, and I have maybe 3 places where I switch on the type flag. I'm not proposing this as a general purpose replacement for interfaces, only a useful way to abstract over a few known types when you can't afford all of the allocs.

> Your example has one contained type per variant. In Rust it is common to have an enum like enum Foo { Variant1(String, u8, Vec), Variant2(u8), Variant3(String), Variant4(f32), Variant6(f32) Variant5(bool, bool, String) }

I agree. I don't propose this as a general purpose replacement for Rust's enums.

Re: Seven years of Go

#252

Post by Thaxll »

pcwalton wrote: post #134
weberc2 wrote: post #118

Earlier quoted context omitted.

I'm a former C++ dev. I've made repeated attempts to learn Rust over the last few years. I now feel like I'm capable of building things with much effort and frustration and constant Googling, but with a small fraction of the effort. By comparison, I got to the same point in Go in an afternoon.

I'm not interested in debating which language is easier to learn for C++ programmers. I'm pushing back against the (clearly false, IMO) idea that adopting Rust is a mistake .

It's about the learning curve, especially people coming from Python to build websites, I mean seriously you would recommend Rust over Go to someone that build api / websites? It's telling someone that used to Ruby to go the C++ way, terrible idea for Python/ruby.

Re: Seven years of Go

#253

Post by weberc2 »

pcwalton wrote: post #239
weberc2 wrote: post #232

Earlier quoted context omitted.

> Generics, pattern matching, functional features, modules, easy FFI, are productivity features! They have nothing to do with safety and performance I dispute that these features improve productivity. With the exception of modules (whose purpose has always eluded me) all are available in Go (or could be trivially implemented) at the expense of safety and/or performance. > I suspect the numbers are like: 95% of applic…

> I dispute that these features improve productivity. With the exception of modules (whose purpose has always eluded me) all are available in Go (or could be trivially implemented) at the expense of safety and/or performance. OK. How do you implement array.map() in Golang?

Probably like this: https://gist.github.com/ParthDesai/5e0f1d4725a644f1e632

Re: Seven years of Go

#254

Post by sethammons »

biztos wrote: post #88
gtrubetskoy wrote: post #24

I have decided to get proficient in Go about 3 years ago and I am glad I did. One of the discoveries in the process was that Go enables you to do things that previously were extremely difficult and you'd typically not even consider as options. Many of the "old" ways of thinking do not apply to Go, and I had to get over the phase of looking for an ORM or webapp or testing frameworks - they don't exist because they are…

I use a testing framework[0] all the time in Go, and while I appreciate it's possible to write tests without one I think it's just pig-headed to not have something like that in the standard library. If you just use testing.T you will most likely end up with a lousy, developer-hostile test suite. (Also, the default coverage metrics are very very weak. But I love Go just the same.) [0]: https://github.com/stretchr/test…

I disagree that you will end up with a `lousy, developer-hostile test suite`. All testify does, to my experience, is change three line if-statement to a one line assert/require that ignores type safety. Aside from that, it is up to the developer to still write good cases, adopt table driven tests when they make sense, and provide enough feedback in test output to debug a broken test.

Re: Seven years of Go

#255

Post by sethammons »

tptacek wrote: post #33
gtrubetskoy wrote: post #24

I have decided to get proficient in Go about 3 years ago and I am glad I did. One of the discoveries in the process was that Go enables you to do things that previously were extremely difficult and you'd typically not even consider as options. Many of the "old" ways of thinking do not apply to Go, and I had to get over the phase of looking for an ORM or webapp or testing frameworks - they don't exist because they are…

Strong, strong disagree on the idea that ORMs aren't necessary because of some property of Golang itself. Lack of decent ORMs is probably my biggest complaint about Go, and I think if you look at a lot of large web app packages you'll find people are all writing their own 40-60% of an ORM.

I find the majority of what you contribute to HN very insightful; I appreciate your activity here! I've yet to use an ORM that I've found added much or any value, and usually I have to fight it. I find "select id from user where email='foo@example.com'" much easier to work with than some odd query build that requires some DSL that made sense to some developer for their particular use case, like user.Get(id).Where().Email("foo@example.com). My most recent case of growing disdain for ORMs being SQLAlchemy. What ORMs do you find (in any language) that you like and what is it about them that helps you?

Re: Seven years of Go

#256

Post by Skinney »

ramchip wrote: post #148
Skinney wrote: post #137

Earlier quoted context omitted.

Erlang isn't necessarily better than Go in this regard. Since Erlang is interpreted and everything has to copied between processes, Go is bound to be faster than Erlang, especially when it comes to parallelism. Go is also statically typed, which in my experience makes it easier to avoid bugs in large teams. Erlang, however, is much better at distributed concurrency. There are few who suits this use case better. As in…

Erlang is actually compiled, and binaries above a certain size are reference-counted rather than copied between processes. It still makes various compromises like using bignums and doing preemptive scheduling which make it slower in general.

It's compiled to erlang bytecode, yes, but not to machine code. You do have the option of doing that, but I do believe you miss out on live updates? Not sure.

Erlang is great though, especially Elixir, but for some use cases Go is better.

Re: Seven years of Go

#257

Post by Manishearth »

weberc2 wrote: post #251
Manishearth wrote: post #233

Earlier quoted context omitted.

> Tagged structs are not meaningfully less type safe than interfaces. Of course they are. What if you read from or write to the wrong field? > Use an enum for the tag Your example has one contained type per variant. In Rust it is common to have an enum like enum Foo { Variant1(String, u8, Vec ), Variant2(u8), Variant3(String), Variant4(f32), Variant6(f32) Variant5(bool, bool, String) } Naming tags for something like…

> Of course they are. What if you read from or write to the wrong field? This falls under the rubric of "not meaningfully less type safe". This data structure is central in a large project of mine, and I have maybe 3 places where I switch on the type flag. I'm not proposing this as a general purpose replacement for interfaces, only a useful way to abstract over a few known types when you can't afford all of the alloc…

> I agree. I don't propose this as a general purpose replacement for Rust's enums.

Yeah, that's the thing, Rust enums used this way are very powerful. I'm fine with making tagged structy things in cases like the one mentioned, I feel Go can handle that. I'm missing out on all the useful stuff I can do with proper algebraic datatypes.

Re: Seven years of Go

#258

Post by Skinney »

wyager wrote: post #169
Skinney wrote: post #137

Earlier quoted context omitted.

Erlang isn't necessarily better than Go in this regard. Since Erlang is interpreted and everything has to copied between processes, Go is bound to be faster than Erlang, especially when it comes to parallelism. Go is also statically typed, which in my experience makes it easier to avoid bugs in large teams. Erlang, however, is much better at distributed concurrency. There are few who suits this use case better. As in…

If the first paragraph is the extent of your concerns with Erlang (which are reasonable), they are more than addressed by Haskell. Compiled and very statically typed.

Yeah, but it's more difficult to teach others Haskell (what's a monad?) than Go. I know all three languages, I mostly prefer Go for backend work because it's easier for others to join in on.

Point is that they all have their strengths, but one is not necessarily better than the other. As with all things digital, it depends.

Re: Seven years of Go

#259

Post by wtetzner »

weberc2 wrote: post #215
wtetzner wrote: post #198

Earlier quoted context omitted.

> And good luck finding Haskell and Erlang developers. Unless you need a massive number of developers, or you're located out in the middle of nowhere, it really shouldn't be too difficult.

I disagree.

Have you tried hiring Erlang or Haskell developers? It's not like they don't exist. In fact, there are likely many developers that would love to take an Erlang or Haskell job, but there aren't that many opportunities.

Re: Seven years of Go

#260

Post by wtetzner »

weberc2 wrote: post #253
pcwalton wrote: post #239

Earlier quoted context omitted.

> I dispute that these features improve productivity. With the exception of modules (whose purpose has always eluded me) all are available in Go (or could be trivially implemented) at the expense of safety and/or performance. OK. How do you implement array.map() in Golang?

Probably like this: https://gist.github.com/ParthDesai/5e0f1d4725a644f1e632

Wow. That seems very complicated for an implementation of map().

It seems like this is a perfect example of how generics are a productivity feature.

Post reply on HN