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

201–210 of 367 posts

Re: Why Go Is Not Good

#201

Post by oscargrouch »

jerf wrote: post #159
oscargrouch wrote: post #74

Earlier quoted context omitted.

The problem is when you have to maintain your code with millions of lines, and hundreds of abstractions.. those "features" will hunt you in your nightmares at night This is the "The Curse of C++" and some languages pointed in the article while beautiful and correct at first sight are going down in the same road.. Do we use a programming language to look smart, to create correct code or to efficiently solve problems i…

To understand a language, one must know what problem it was designed to solve. It isn't always obvious, or what it initially looks like it was designed to solve, or even what the community thinks it was designed to solve. Erlang, for instance, isn't about concurrency. It's about reliability. Go, I think, is also not about concurrency. It's about building a language that can be sanely used by reasonably large groups o…

I have the same line of thinking as you do.. is the difference in use something you like and can work, and choose something you can use in a bigger group..

HN crowd are top smart.. things like Rust and Haskell are a breeze for people here.. but this is not the reality of the tech field.. the majority of people i know in tech, cant handle more powerful languages.. its too much for them

In the end is just that.. know how to choose the right tool for the job.. and dont do it with your ego..

Adaptation is really important.. and in your thoughts we can see a lot of that..

In Wonderland people may have the IQ to spend for the extra concepts and power a language may provide.. but experience is antagonic to this dream..

The cool thing of smart people to make complex things more simple, is that much more people are able to follow.. is the democratization of computing.. this is in total odds against the elitism we can see in some tech circles.. and im totally against it..

Re: Why Go Is Not Good

#202

Post by Peaker »

briantakita wrote: post #121

This article presumes that everybody wants an elaborate type system. I'm not sure that is the case. I still see an elaborate type system as incidental complexity. I may be in the minority and I may not have worked in domains which benefit from such modeling. Maybe I'm stuck in a blub paradigm. Here's my reasoning. I'm a fan of human language & domain ontologies. Word definitions are quite flexible & do not have an el…

I recommend Dijkstra's paper: "On the foolishness of "natural language programming" [1].

It explains how natural language is a very poor way to express programs, and how it held back science and progress for many centuries.

Strong types describe your code precisely. If your code doesn't match the model yet, that's fine.

But your code has invariants in it. Things like: "this variable can never be nil, that variable can". These invariants can relatively easily be encoded as static types. Not doing so is just throwing away safety and documentation for virtually no benefit.

Other invariants are similar. Instead of documenting them or keeping them in your head, you let your compiler worry about them. And then when you break those invariants, the compiler is your friend! He helps you go and find all the other pieces of code that relied on the broken invariant, so you can fix them.

You say you prefer a more flexible language: But Go is extremely inflexible. It has a very primitive set of tools to do everything, clumsily. A language like Haskell, for example, lets you have Go-like coroutines and channels. But it also lets you program with software transactional memory, or use other parallelism constructs.

Also, the inability to specify invariants of your program isn't flexibility. The ability to specify them or opt out of specifying them, which is what strong type systems give you, is.

1. https://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/E...

Re: Why Go Is Not Good

#203

Post by shadowmint »

wyager wrote: post #30
tshadwell wrote: post #27

For fear of disagree downvotes: I would say that many of the qualms brought up in this article are problems that are encountered fighting the language. The problem of 'summing any kind of list' is not a problem that is solved in Go via the proposed kind of parametric polymorphism. Instead, one might define a type, `type Adder Interface{Add(Adder)Adder}`, and then a function to add anything you want is fairly trivial,…

>The writer seems to believe that functions on nil pointers crash the program, this is not the case. It's a common pattern in lazy construction to check if the receiving pointer is nil before continuing. And what happens when you don't check? It crashes. That's the unsafe part. These crashes are simply not possible in Rust and Haskell, and the type system notifies you if failure is possible (because the function will…

Woa, Rust is great, but I think you're going a little far on the hyperbole there.

You can easily generate a segfault in Rust in 'unsafe' (or 'trusted') code; that might only restrict errors of that nature to code that uses unsafe blocks.

Practically speaking that's pretty common; once you enter an FFI unsafe block, you lose all type safety; but you can totally do it without FFI too. Eg. using transmute().

In fact, there's no way to know if you code contains 'hidden' unsafe blocks wrapped in a safe api in some 3rd party library that might cause a mysterious segfault later on.

You can argue that 'if you break the type system you can do anything, obviously'; that's totally true.

I'm just pointing out the statement: "These crashes are simply not possible in Rust and Haskell" categorically false.

You can chop your own arms off in Rust just like anything else (including Go).

Re: Why Go Is Not Good

#204

Post by codygman »

oscargrouch wrote: post #183
codygman wrote: post #169

Earlier quoted context omitted.

You made the claim that "in the end you write less code to do the same thing, as you would in C++, Haskell or Rust". Can you provide any examples where the Haskell equivalent isn't more concise than the Go equivalent? As a data point, here are links to the Haskell and Go implementations of the TechEmpower benchmarks: Haskell (78 sloc) https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... Go (164 sloc) https…

Anyone can encapsulate or "hide" the inner workings so the resulting code will look small.. how much of that code in the frontend is already implemented in the standard library of each language?? To see the reality of it.. a better example would be something without any support library... Cherry picking is easy.. From the same benchmarks Game: spectral-norm - Go http://benchmarksgame.alioth.debian.org/u64/program.php…

Picking something without a library will give an advantage to the other language in most cases because Haskell is very library based.

I didn't cherry-pick btw, I just went to the first benchmark which included community-written snippets of both Go and Haskell I could think of. Cherry-picking would be me intentionally skipping over examples such as the one you provided and instead posting my example.

Re: Why Go Is Not Good

#205

Post by [deleted] »

oscargrouch wrote: post #183
codygman wrote: post #169

Earlier quoted context omitted.

You made the claim that "in the end you write less code to do the same thing, as you would in C++, Haskell or Rust". Can you provide any examples where the Haskell equivalent isn't more concise than the Go equivalent? As a data point, here are links to the Haskell and Go implementations of the TechEmpower benchmarks: Haskell (78 sloc) https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... Go (164 sloc) https…

Anyone can encapsulate or "hide" the inner workings so the resulting code will look small.. how much of that code in the frontend is already implemented in the standard library of each language?? To see the reality of it.. a better example would be something without any support library... Cherry picking is easy.. From the same benchmarks Game: spectral-norm - Go http://benchmarksgame.alioth.debian.org/u64/program.php…

[deleted]

Re: Why Go Is Not Good

#206

Post by dbaupp »

shadowmint wrote: post #203
wyager wrote: post #30

Earlier quoted context omitted.

>The writer seems to believe that functions on nil pointers crash the program, this is not the case. It's a common pattern in lazy construction to check if the receiving pointer is nil before continuing. And what happens when you don't check? It crashes. That's the unsafe part. These crashes are simply not possible in Rust and Haskell, and the type system notifies you if failure is possible (because the function will…

Woa, Rust is great, but I think you're going a little far on the hyperbole there. You can easily generate a segfault in Rust in 'unsafe' (or 'trusted') code; that might only restrict errors of that nature to code that uses unsafe blocks. Practically speaking that's pretty common; once you enter an FFI unsafe block, you lose all type safety; but you can totally do it without FFI too. Eg. using transmute(). In fact, th…

> You can easily generate a segfault in Rust in 'unsafe' (or 'trusted') code; that might only restrict errors of that nature to code that uses unsafe blocks, but practically speaking that's pretty common; once you enter an FFI unsafe block, you lose all type safety; but you can totally do it without FFI too. Eg. using transmute().

Not directly addressing what you're saying, but, IME people are far too quick to use `unsafe` code. One needs to be quite careful about it as there's a pile of invariants that need to be upheld: http://doc.rust-lang.org/master/rust.html#behavior-considere...

> once you enter an FFI unsafe block, you lose all type safety

You don't lose all type safety, especially not if the FFI bindings you're using are written idiomatically (using the mut/const raw pointers correctly; wrapper structs for each C type, rather than just using *c_void, etc).

Re: Why Go Is Not Good

#207

Post by bjz_ »

mustpax wrote: post #126
wyager wrote: post #117

Earlier quoted context omitted.

>Go makes the cost of generic code explicitly visible. Generics encourage over-generalizing behavior that runs counter to writing highly performant code. I think you may be missing some info regarding generics in Rust and Haskell. As I mentioned in the article, there is zero runtime overhead for generic programming in Rust and Haskell. Zip. Zilch. Nada. That's why their constraint-based static generics system is awes…

Lack of generics is part of the reason why Go is easier to learn and the Go compiler is faster than, say, Rust. Sure, generics don't have runtime overhead in Rust and Haskell but they have other costs. You always pay for abstractions some way.

The rust compiler is actually really quick. The LLVM optimization passes and code gen is where most time is spent (this is after monomorphisation of generics). The Go compiler does very few optimizations compared to LLVM, which leads to faster build times but slower code.

Re: Why Go Is Not Good

#208

Post by oscargrouch »

codygman wrote: post #204
oscargrouch wrote: post #183

Earlier quoted context omitted.

Anyone can encapsulate or "hide" the inner workings so the resulting code will look small.. how much of that code in the frontend is already implemented in the standard library of each language?? To see the reality of it.. a better example would be something without any support library... Cherry picking is easy.. From the same benchmarks Game: spectral-norm - Go http://benchmarksgame.alioth.debian.org/u64/program.php…

Picking something without a library will give an advantage to the other language in most cases because Haskell is very library based. I didn't cherry-pick btw, I just went to the first benchmark which included community-written snippets of both Go and Haskell I could think of. Cherry-picking would be me intentionally skipping over examples such as the one you provided and instead posting my example.

I´ve provided the links as a example of cherry-pick from my part.. showing that its easy to come with something that looks good..

FP tend to be more expressive, and make you feel more powerful.. but they also tend to be more complex and more verbose.. thats the price of power.. it's the trade of

I think its not enough to show something simple, but with the real complexity hidden in some hidden layers..

Also if line of code is the measure of simplicity the Brainfuck language would win everything.. but it doesnt mean you can read what the code express with less effort..

Nothing against Haskell in particular, only that it doesnt shine when the matter is simplicity..

Expressiveness.. Abstraction power.. shure.... but that was not the original point i was making in the original article

Re: Why Go Is Not Good

#209

Post by jacquesm »

ScottBurson wrote: post #109
jacquesm wrote: post #88

Earlier quoted context omitted.

> Yes there are GCs for C, but is anyone successfully doing "systems programming" (whatever that may be) in C with GCs? Actually, yes. But it's hackish (relies on some pretty complex macros) and requires you to adapt certain conventions. Still, it's doable and a whole lot safer than managing your memory directly in terms of leaks and re-use after free. The cost to me really is that macro magic, that should not be req…

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. There is a lot more to this story but I'm not at liberty to tell. Let's just say I learned a lot.

Re: Why Go Is Not Good

#210

Post by Dewie »

richo wrote: post #147
Dewie wrote: post #89

Earlier quoted context omitted.

Not if you just throw something like an exception when the program tries to do it instead of actually accessing that memory location.

that's what mapping an -rwx page at 0x0 does, and as a result it segfaults, which is an access violation.

...I'm talking about throwing an exception or something similar, not getting a segfault. Like in Java.
Post reply on HN