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

321–330 of 367 posts

Re: Why Go Is Not Good

#321

Post by steveklabnik »

jeremyjh wrote: post #296
personZ wrote: post #266

Earlier quoted context omitted.

Go is absolutely fantastic at pragmatic, practical concurrency. In most real-world cases, that does not include a strong immutability base, for instance. Here's the thing about the "Go sucks because Haskell is the best language ever" retort: Haskell has been around for decades longer than Go. It has made essentially zero impact, and even for the case of many of those who use it as the "my big brother" comparison agai…

Haskell is one example; Clojure, Rust, Erlang, Scala are mainly the ones we think about in this category but even in Modern C++ code const is used quite a lot. Go is not yet very widely known or popular outside the HN bubble; I think it is a bit early for "daily driver" argument.

I saw an ad for Go programmers in a taxi once...

Re: Why Go Is Not Good

#322

Post by briantakita »

Peaker wrote: post #287
briantakita wrote: post #244

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'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…

> 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?

True. Though we are discussing nil/null as being a potential state of data. I actually like & utilize Javascript's notion of falsy (false, "", undefined, null, 0). It's not precise, but most of the time, precision is not needed. Just the general notion that there is a value to operate on or not. Optimizing toward brevity supersedes precision in many cases.

> 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 {}".

I mostly do use dynamic languages. Though, the notion of the Go interface makes the api explicit, yet remains decoupled from the rest of the type system, which seems ok. I've seen proponents use these interfaces to later "discover" types.

> Why would you rather opt in? Opt out makes sense because types are so cheap 99% of the time. I would rather opt in if I would otherwise have to think about it every time the situation comes up.

Take a collection as an example. Most of the time, I really just want to put a bunch of objects (data) into the collection. I don't want to be a bookkeeper of what type of data is going into the collection. I trust that the data "works" with the rest of the program and will utilize other mechanisms to prove that it doesn't work. I don't want to have to fight compile errors and have to craft a type system just to put an object into a collection.

---

As a general notion, I like to evolve the design from a simple understanding to a more precise & intricate understanding. My ideal programming language would be forgiving of my initial simplistic domain understanding and facilitate the growth of precision as time goes onward.

Re: Why Go Is Not Good

#323

Post by oscargrouch »

illumen wrote: post #251
oscargrouch wrote: post #201

Earlier quoted context omitted.

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 h…

Rust and Haskell are made to reduce the amount of problems you have. I've seen newbie programmers learn Haskell as a first language in under a term. So I don't believe the marketing from the Google people that their language is worse because it is simpler. Choosing something because marketing told you it was easier is just as silly as choosing something because of ego. Calling people egoists when they choose a tool b…

> Choosing something because marketing told you it was easier is just as silly as choosing something because of ego. Calling people egoists when they choose a tool because of reasoned arguments based on evidence is simply anti-intellectual, and rude.

I Just dont know where in the post i did say something like that.. marketing? egoists? where did i said that?

If you happen to be above average in say english language for instance.. and you know a lot of words and sentences, poems.. but the thing is.. if you choose the speak in the english you know better, you will communicate with fewer people.. or you can just jump to a lower level to communicate so everybody can understand..

Of course you can use the advanced english with elite people.. you can teach people the 'better english' but a lot of them wont care, because they care about other things.. and i dont blame them.. (they may be worried about math or trips)

My point was just something like that.. nothing more, nothing less

Re: Why Go Is Not Good

#324

Post by ScottBurson »

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…

So you had to write your own compiler, operating system, and runtime libraries too?

-- I know, you didn't think it made any sense either. I'm just pointing out that a line has to be drawn somewhere; where it gets drawn is actually arbitrary.

Yeah, I've had to deal with ridiculous mandates from on high too, though none anywhere near that onerous. In my previous job, we were writing a compiler. It was mandated to be in C++ -- the first mistake -- and we had to use smart pointers instead of GC -- also a mistake. But the completely idiotic thing was that we were not allowed to declare any exception classes. The VP of Engineering -- a very smart and experienced but very arrogant guy -- had seen exception hierarchies get out of control before and decided the solution was to ban them.

But that's on a pretty small scale compared to what you're talking about.

Re: Why Go Is Not Good

#325

Post by oscargrouch »

threeseed wrote: post #255
oscargrouch wrote: post #194

Earlier quoted context omitted.

Nothing, thats the point.. its not language that the creators did because they are vain, or want to prove they are smart, or know what beauty is.. its a language that are created to get things done! the beauty of it its the same beauty that we see in Unix or C.. its simplicity.. Dear God.. I dont know why so many programming languages anyway to do the same thing all over again.. just because of the sake of the sintax…

>its a language that are created to get things done And the hundreds of other languages serve what purpose then ?

Im sure some languages, are created just for the sake of sintax, others to prove a marginal point, and others because the author want to be a tech celebrity.. this is "the noise" i was refering to..

We can spot really important languages, that actually put something new in the table.. with real originality and genius.. and the immitators that follow

The clear evidence to what im talking about, is that if you think in a niche that you wnat to create a program, you will have 3 or more langs to choose..

Choice is good? not always.. because once we create codebases in the langs we choose we are trapped..

All the languages we heard of, create programs somehow, otherwise we wouldnt know about.. but some are more pragmatic than others..

My sentence was to explain that the authors of the language were thinking more in the enginnering aspect, than in some theoretical or research

There are a lot of research languages out there... so in my point of view, they were not created with a more pragmatic goal..

They are cool and will push the envelope.. sure! but i dont understand the elitism here, trying to bash things that were created thinking more in the enginnering axis.. while puttting some "not working yet" but "research using the poor programmers as rat labs" in a pedestal..and in the same level as something that works, because it were design to work in a more conservative matter

Re: Why Go Is Not Good

#326

Post by oscargrouch »

Peaker wrote: post #187
eloff wrote: post #122

Earlier quoted context omitted.

Correct. I have to duplicate much of the code for in64 keys and values, the lack of generics hurts there.

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.

Its not like you will be creating a collections library all the time you create some program... yes generics are cool for code reuse.. but i think some people just overreact, turning it into something that will make the language unusable or that you will have to copy-and-paste just because of the lack of generics.. this is far from truth..

Re: Why Go Is Not Good

#327

Post by AnimalMuppet »

Peaker wrote: post #195
mholt wrote: post #22

Earlier quoted context omitted.

In practice, Go has caused me less frustration than any other language I've used. I feel like the author's complaints here aren't really grounded in much experience, or maybe he's trying to use the wrong tool for the job. The author's conclusion: · Go doesn't really do anything new. · Go isn't well-designed from the ground up. · Go is a regression from other modern programming languages. is hardly sustainable. Go was…

> Tell me again that Go does nothing new for us None of the things you mentioned are new. > Go makes concurrent programming safe and easy Mutability & concurrency, nils, interface casts -- these things all go against safe. > Tell me again that there isn't good engineering behind Go. You seem to think that a language that has baked in syntax for concurrency, or that has famous people behind it necessarily has "good en…

You're thinking wrong. You're also proving the grandparent's point.

You're thinking in terms of "here's this set of bullet point features that I think a language has to have to be a proper, modern language." But the grandparent was asking you to consider that a different set of features might have value form some real-world problems that Go's authors had really bumped into. You reply, "Nope, couldn't have - it doesn't have my bullet point features!"

There are more things in programming than are dreamt of in your philosophy of what a programming language should be.

Re: Why Go Is Not Good

#328

Post by sagichmal »

sergiosgc wrote: post #259
bad_user wrote: post #248

Earlier quoted context omitted.

I'm not writing the following to make people pick another language - if Go is suitable for your project in terms of features, runtime, tools and community, then by all means use Go. It's a fairly decent platform to target and it can further evolve to meet more stringent needs. But if we are talking about the cost of abstractions , the biggest elephant in the room is that Go's GC is NOT optional, which makes it unsuit…

>I wish developers would stop equating "complicated" to things "I don't understand". The argument is a bit more about evolved than that, but flawed nonetheless. The argument usually invoked for Go is that, by eschewing selected language features, it prevents developers shooting themselves in the foot with unneeded complexity introduced by faulty abstractions. I get the argument. I have seen my fair share of dug-out-f…

    > The endgame is "Computer, build me a Mars round-trip ship".
I think nobody would argue against that endgame, in the broad strokes. But I think Go can be understood as a response to [what the Go developers perceive as] overly expressive languages, languages that have overstepped our ability to responsibly abstract details, languages whose abstractions hide details that are still important and necessary to make explicit.

Go is "lower level" in that it purposefully eschews those abstractions, but I think it does that successfully, without a significant loss in expressivity, and with a more-than-commensurate gain in understandability, maintainability, performance, etc.

Re: Why Go Is Not Good

#329

Post by zaphar »

lmm wrote: post #240
pcwalton wrote: post #80

Earlier quoted context omitted.

I doubt that null pointers lead to security vulnerabilities. Panics, yes; worse performance, yes; vulnerabilities, unlikely. Null pointers are not dangling or wild pointers, which are the problematic ones.

What if e.g. a programmer calls some normalize function on data before hashing it? Then if the normalize function sometimes returns null and the programmer hasn't handled this case, an attacker could use this to generate collisions.

That particular problem is not specific to null pointers. It's specific to normalizing functions.

Re: Why Go Is Not Good

#330

Post by Peaker »

AnimalMuppet wrote: post #327
Peaker wrote: post #195

Earlier quoted context omitted.

> Tell me again that Go does nothing new for us None of the things you mentioned are new. > Go makes concurrent programming safe and easy Mutability & concurrency, nils, interface casts -- these things all go against safe. > Tell me again that there isn't good engineering behind Go. You seem to think that a language that has baked in syntax for concurrency, or that has famous people behind it necessarily has "good en…

You're thinking wrong. You're also proving the grandparent's point. You're thinking in terms of "here's this set of bullet point features that I think a language has to have to be a proper, modern language." But the grandparent was asking you to consider that a different set of features might have value form some real-world problems that Go's authors had really bumped into. You reply, "Nope, couldn't have - it doesn'…

He said Go had something new to offer, and listed old things.

He said Go makes concurrency safe & easy, when Go emphasizes features that contradict safety and ease.

He said Go tackled problems in a newer way, when Go is really Algol69 + coroutines.

He denied Go regressing from other languages, when it throws away decades of PL research.

In none of this did he say "Here's an alternate set of features that ...". No. He said concrete, specific, wrong things.

What you are saying is a different thing -- and I also disagree with you.

These "bullet list" features weren't invented for the lols. They were created to solve real problems. Problems that Go doesn't have an alternate solution to.

Go programs dereference null. That is a bad thing. Languages with my "bullet point features" do not dereference null.

Go programs duplicate code to handle different types. Ditto.

Go programs can (and thus do!) mutate some data after it was sent to a concurrent goroutine. Ditto.

Go programs can cast down to incorrect types. Ditto.

The "bullet point features" are important. There are alternatives, but Go doesn't sport any of them.

Post reply on HN