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

Go is Google's language, not ours

utcc.utoronto.ca

Post reply on HN
Print view View original

611–620 of 679 posts

Re: Go is Google's language, not ours

#611

Post by erik_seaberg »

satyenr wrote: post #537
erik_seaberg wrote: post #487

Earlier quoted context omitted.

This. If you want to revolutionize the profession, come up with something that helps with reading as much as modern IDEs help with writing. My answer is that boilerplate should be generated somewhere else and largely ignored.

IMO, boilerplate source code shouldn’t be generated at all — the tool chain should directly emit the required object code. And code generation shouldn’t require a different language — or special comment syntax.

Depends on the toolchain. Everybody knows how to generate ugly source files, but it takes more effort to add AST nodes during compilation (or symbol table entries with types plus object code) and might lead to errors nobody understands how to fix (because you can't read the declaration of the thing you're trying to interact with).

Re: Go is Google's language, not ours

#612

Post by crimsonalucard »

pjmlp wrote: post #220
_ph_ wrote: post #173

Earlier quoted context omitted.

No one claimed, that languages with generics don't exist. But if you follow the discussion about generics in Go, Russ Cox did a thorough discussion of all the proposals on the table and why they would mean giving up some of the core traits of the Go language. As soon anyone suggests an implementation not colliding with the core Go goals, the Go team probably would pick it up quickly. Or phrased it in another way: wit…

Not at all, he focused on how Java and C++ do it, and later on the Go 2.0 proposal admited that they were a bit closed minded to look for how other language implementations work. "In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier." https://go.googlesource.com/proposal/+/master/design/go2…

This is definitive proof that the lack of generics was a mistake from the beginning.

Re: Go is Google's language, not ours

#613

Post by hackerpacker »

reallydude wrote: post #498
StevePerkins wrote: post #287

Earlier quoted context omitted.

I have no idea what having a "soul" means. But I suspect that my career has been well-served by being dead inside.

> I have no idea what having a "soul" means A design philosophy. Some sort of measurable practice that influences design. This is not limited to Java. Design by committee has been destroying the maintainability of many languages.

"Some sort of measurable practice", not anything remotely like a "soul", in fact invoking "you have no soul" usually means you lost the argument and are now desperate enough to say anything.

Re: Go is Google's language, not ours

#614

Post by pjmlp »

pron wrote: post #563
pjmlp wrote: post #542

Earlier quoted context omitted.

In 1995 I was enjoying Oberon, Component Pascal, Eiffel and Delphi. Value types were pretty much obvious as necessary. More so when one dives deep into how languages like CLU and Mesa/Cedar were designed. Having a AOT support doesn't preclude having a JIT as well, like Common Lisp or Eiffel already had in 1995.

There's a difference between useful, and even very useful, and absolutely necessary. Clearly value types weren't absolutely necessary, as Java did well without them (and JS still does). Gosling said that his goal was to have nothing you can somehow live without (I don't know how well early Java lived up that ideal, but that was the ideal). Hardware changes made user-defined value types absolutely necessary for worklo…

Being there since the beginning, I wrote my first Java game in 1996, early Java only did well thanks to Sun's marketing weight and it being free beer vs the alternative of having to pay for a compiler like Delphi.

Re: Go is Google's language, not ours

#615

Post by pjmlp »

pron wrote: post #558
emn13 wrote: post #536

Earlier quoted context omitted.

Value types aren't "necessary", but they would have been valueable at day 1. The GC heap is simply inefficient; not necessarily because of the GC (which indeed is harder with massive multicore), but simply because of the per-object memory overhead. There's a reason java had built-in value types from day 1, because it made sense even back then. Frankly, I think both java and C# kind of got this wrong. There was an ove…

> because it made sense even back then. That was necessary for performance back then. User-defined value types weren't, and Java has done well without them. > Object has semantics, and that was a mistake, because it contributes to the bloat. I think most of the RAM bloat is due to the GC trading off extra RAM for speed rather than object headers, and I'm not sure trading off complexity for headers was right 25 years…

I advise you to read Mesa/Cedar report on the impact of garbage collection algorithms available at Xerox PARC bitsavers archive, EthOS or SpinOS experience with Modula-3.

All of them refer that having value types alongside GC had a relevant impact improving performance.

All systems designed before Java was a thing.

Or since you refer to JS, the paper about SELF's design.

Even Dylan was designed with AOT/JIT and value types support, which is relevant here given that its domain was being a systems language for the Newton. That politics killed it is another matter.

Re: Go is Google's language, not ours

#616

Post by [deleted] »

underdeserver wrote: post #479
baby wrote: post #418

Security consultant here. I have audited many codebases in many languages. Go is by far the easiest language to audit: it always looks the same, it's not too verbose, there are no generics or OOP. Coincidentally it's always the most secure as well. My take on this is that it is easier to see logic problems because it is easier to read, understand and reason about. On top of that the standard library does so much for…

Could it be because Go is newer and handles buffer overflows correctly?

[deleted]

Re: Go is Google's language, not ours

#617

Post by takeda »

doesnt_know wrote: post #162

I'm going to risk being labeled an ~incompetent dev~ or whatever but learning golang was seriously a breath of fresh air compared to literally any language I have ever tried to grok before. Everything felt like it was there on purpose. It always seemed like there was a "proper" way to achieve something. Being told to use this opinionated formatter was like removing a 40kg bag after a bush walk. You never have to worr…

My experience is different. Believe it or not the type checker is actually inferior to Python + mypy. For example it is possible for variable to be nil, even when it is not a reference.

Types, it has int, int8, int16, int32, int64, uint, uint8, uint16, uint32, uint64 and also float32 and float64.

If you use anything besides int, int64 or float64 you will just have a lot of fun casting.

math.max() and math.min() only work on float64, you can easily use it with different types, and actually it is discouraged to use it with integers. So you need to roll your own if you want to work with integers. But ok, it is math so when you do math apparently you should work on floats because that's what scientists do, but then why it doesn't work with float32? You actually have to cast like

result := float32(math.max(float64(left), float64(right))

If you want to convert a string to an integer, you have nice strconv.ParseInt() where you can specify among other things a bitSize, great, but the resulting type is still int64, you will need to cast it. What about other types, using them is a nightmare, if they were not supposed to be used why not just have int and float type?

If you try to implement a data structure that stores objects, you either have to duplicate the code, use interface {} (looks like that's most common, but then you no longer get help from a type checker) or use generator (this seems best to me, but it is just automation of the first approach).

I don't understand why Go is getting so much good opinions, it is not an enjoyable language to program. The supposed killer feature which were go routines and channels are kind of meh and nothing that you couldn't replicate in other languages. Seems like people like its simplicity, does that mean the other languages are overwhelming?

Re: Go is Google's language, not ours

#618

Post by karmakaze »

crimsonalucard wrote: post #52
theshrike79 wrote: post #37

Earlier quoted context omitted.

In my opinion the way they are handling adding Generics to Go is proof of this model working. They are actually trying to pick the implementation that solves real world issues, not just trying to tick [x] Generics in the Go spec sheet.

Parametric polymorphism is a real world issue. The fact that it wasn't checked off indicates to me that they are of the opinion that it's not as important. It's ok to have this opinion, I just disagree with it. I do agree that it's important to think it through, I do not agree that the language should be brought to 1.0 without it.

The one thing that I do like about Go not having generics early on is that it became a language for lower-level work with many good libraries. I wouldn't quite call it a systems language like they like to say but I like its positioning which filled a void.

Now when Go 2 gets generics it will be used for all kinds of applications and frameworks, which is fine but isn't really filling a void. I expect the ergonomics (e.g. wicked fast compiles to single binary) to be better than current app dev langs. I stopped using Go and look foward to trying it again. Even then I don't think it will be one of my favorites and likely used for smaller work. Long-term I want Pony to succeed. Medium term I'll take Kotlin, Elixir, or Dart.

Re: Go is Google's language, not ours

#619

Post by baby »

erik_seaberg wrote: post #514
baby wrote: post #431

Earlier quoted context omitted.

It would objectively have made Golang harder to read. Can we agree on that? People tend to abuse generics.

Uses of https://golang.org/pkg/sync/#Map are objectively harder to read than if they allowed a library to implement a type that conforms to builtin map[K]V. Instead you have to learn method names and cast return values, and builtin maps don't even support those methods.

Let’s agree to disagree. Maybe you’re used to reading generics after years of doing it.

Re: Go is Google's language, not ours

#620

Post by baby »

ncmncm wrote: post #610
baby wrote: post #429

Earlier quoted context omitted.

It's a very different language than Golang though, very expressive, generics, no GC, etc.

You say that like those are bad things. Yes, the borrow checker is a PITA vs. Go, but there are compensations.

These are not bad things if you’re writing system code.
Post reply on HN