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

Why Go Is Not Good

yager.io

Post reply on HN
Print view View original

281–290 of 367 posts

Re: Why Go Is Not Good

#281

Post by lmm »

jacquesm wrote: post #209
ScottBurson wrote: post #109

Earlier quoted context omitted.

You rolled your own? Why not use the Boehm conservative collector?

In three letters: NIH. Management decision was that all IP had to be 100% owned by the company and had to be in 'C', in spite of an enormous amount of friction between C and the project as well as a bunch of work by others that could have been leveraged if we had decided to use code from other contributors. I got called in long after these decisions were made and it was very clear they weren't going to budge on those…

Reminds me of my last^2 job: we were using Scala and the "technical architect" made two decisions that were mildly wrong in isolation but interacted rather badly: we'd make heavy use of monads for core functionality, and we wouldn't use scalaz. So I spent a while reimplementing parts of scalaz, and learned quite a lot (though I doubt I was adding much business value while doing so).

Re: Why Go Is Not Good

#282

Post by steveklabnik »

jvermillard wrote: post #264

I'm reading that while doing my daily Java code and I stumble on this error : Bound mismatch: The generic method immutableEnumSet(Iterable ) of type Sets is not applicable for the arguments (Integer). The inferred type Integer is not a valid substitute for the bounded parameter > Sorry for advanced type systems but I really want to go back hacking Go code :)

You have an Integer where it expects a Set.

Re: Why Go Is Not Good

#283

Post by lmm »

waps wrote: post #228
cantankerous wrote: post #178

Earlier quoted context omitted.

You'll probably be looking for a Go runtime that fills a kernel shaped hole. Without a kernel, where do all your syscalls go?

Yes but the point of the parent poster was that go can work on minimal embedded systems, which to my knowledge it cannot, so I enquired.

No, the point of the parent poster was that "systems" is not the same as "embedded", and that while go may not work on the latter it can work on the former.

Re: Why Go Is Not Good

#284

Post by koffiezet »

lmm wrote: post #277
mustpax wrote: post #114

Earlier quoted context omitted.

There's no question that Rust and Haskell have better tools than C++ for abstracting code. Go is just demonstrating that you can write great software without the aid (and cost) of generics.

Is there demonstrably great software written in Go yet? I've seen some people using it but I've yet to see a "killer app" (the way e.g. MLDonkey convinced me I should take OCaml seriously, or Pandoc convinced me I should take Haskell seriously).

Docker.io?

Re: Why Go Is Not Good

#285

Post by orbifold »

coldtea wrote: post #225
Peaker wrote: post #187

Earlier quoted context omitted.

You seem to be brushing this off as a minor nuisance, when in many cases it is a showstopper. Need it for floats, duplicate it again. This is a solved problem -- the fact Go doesn't have the solution reflects very poorly on Go.

There are some batshit crazy "solutions" offered from Go fans, like "no biggie, just use a templating engine to generate the code for the types you want and compile it".

Ironically that is the solution c++ essentially uses.

Re: Why Go Is Not Good

#286

Post by Peaker »

lmm wrote: post #252
briantakita wrote: post #213

Earlier quoted context omitted.

> It explains how natural language is a very poor way to express programs, and how it held back science and progress for many centuries. I'm not interested in using natural language to implement the software (write code). I'm interested in using natural/technical language to create an ontology for the architecture. This is where things get gray. When I think of an architecture, I think of something that evolves over…

> I usually use guard clauses to protect against nulls. An interesting (to me) insight was that in a language with a flexible type system, the types are effectively just a set of assertions at the start and return of every function, that say that the inputs and outputs have certain properties. With a compact syntax and zero runtime overhead, which is nice. I do think that some strongly typed languages make it too dif…

It's much more than just at the start end return of every function. But OTOH, it's much less than assertions, since they're restricted to a subset that can be proven (usually automatically).

Note the Scala verbosity here is Scala-specific. In HM-style languages, type inference works much better and you don't have to do such things. You might still have to explicitly "lift" a value from one type to another (e.g: Wrap a value in "Just", or use "lift"), but that's a much more minor price to pay.

Re: Why Go Is Not Good

#287

Post by Peaker »

briantakita wrote: post #244
Peaker wrote: post #233

Earlier quoted context omitted.

> This ontology evolves over time as the software, understanding of the domain, & the domain itself changes. So what does this have to do with Go or type systems? > I usually use guard clauses to protect against nulls. I rely on my tests & production monitoring systems to prove that the implementation is incorrect. And that's a bad thing. There are better tools for this job. What's the downside of encoding nullabilit…

> This ontology evolves over time as the software, understanding of the domain, & the domain itself changes. > So what does this have to do with Go or type systems? I've found that type systems, that aren't utilizing Duck Typing, as being restrictive & causing incidental complexity when evolving the design. I don't really care if something is a categorization of something else. I usually (> 98% of the time) only care…

> I usually (> 98% of the time) only care if that something adheres to an interface.

Well, whether something is "nil" or not definitely matters to whether it adheres to the interface, doesn't it?

> There's no downside in encoding nullability, unless extra syntax & incidental complexity is added

You just need sum types and pattern-matching, which are a straight-forward addition to the language -- and very fundamental to computation, so not quite "incidental complexity".

> I'd rather be opted out by default and opt in when I want to

Then why do you use Go and not a fully dynamically typed language? In Go you opt out explicitly with "interface {}".

Why would you rather opt in? Opt out makes sense because types are so cheap 99% of the time.

Re: Why Go Is Not Good

#288

Post by Peaker »

zik wrote: post #262
Peaker wrote: post #199

Earlier quoted context omitted.

Writing a language in Go, which doesn't have sum types won't be fun. Also, if you want to implement a compiler, and not an interpreter, the host language having GC is not very useful to get GC. Haskell is going to make working with ASTs much easier and safer. It also has a superset of the concurrency features of Go.

I'm writing a language in Go. It is fun. Sum types (and ASTs) are implemented with interfaces which provide a pretty clean and type safe way of doing this.

Can you show some small example encoding of an AST in Go?

Re: Why Go Is Not Good

#289

Post by TheCoelacanth »

jvermillard wrote: post #264

I'm reading that while doing my daily Java code and I stumble on this error : Bound mismatch: The generic method immutableEnumSet(Iterable ) of type Sets is not applicable for the arguments (Integer). The inferred type Integer is not a valid substitute for the bounded parameter > Sorry for advanced type systems but I really want to go back hacking Go code :)

Java's type system is hardly advanced; in fact it's quite primitive.

Re: Why Go Is Not Good

#290

Post by Peaker »

orbifold wrote: post #285
coldtea wrote: post #225

Earlier quoted context omitted.

There are some batshit crazy "solutions" offered from Go fans, like "no biggie, just use a templating engine to generate the code for the types you want and compile it".

Ironically that is the solution c++ essentially uses.

Not quite, given that C++ templates do higher-level type-checking than just expanding and checking.

Also, they support higher-order kinds (a template parameterized by a template). And specialization (specifying special cases). And automatic instantiation based on the static types at the call site. Etc.

Post reply on HN