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

I Want Off Mr. Golang's Wild Ride

fasterthanli.me

Post reply on HN
Print view View original

381–390 of 508 posts

Re: I Want Off Mr. Golang's Wild Ride

#381

Post by Corrado »

yashap wrote: post #306
fhood wrote: post #22

The author spent a lot of time dwelling on Window's filesystems, at which point many of the readers got bored and started commenting. There are actually a couple of excellent points in here, the majority of which relate to Go's tendency to just be silently completely wrong in its behaviors from time to time, and is absolutely packed with hidden gotchas.

Agreed, the author’s main argument is summarized nicely at the end, and it’s a good one: > It constantly takes power away from its users, reserving it for itself. > It constantly lies about how complicated real-world systems are, and optimize for the 90% case, ignoring correctness. > It is a minefield of subtle gotchas that have very real implications - everything looks simple on the surface, but nothing is. “Our use…

I like to think of it more like Go was built by Google, for Google. If you aren't Google, then Go is probably not right for you.

Re: I Want Off Mr. Golang's Wild Ride

#382

Post by cjhopman »

typon wrote: post #250
Thaxll wrote: post #248

Earlier quoted context omitted.

I didn't make myself clear enough, if something returns an error in Rust and you don't check it will it compile or not?

It will not compile. (As I said earlier, you can always fallback to a panic aka "I don't wanna deal with the error so let my program crash", but an error will not silently propagate through the stack)

That's is completely false, stop spreading misinformation.

This code will compile (see https://play.rust-lang.org/?version=stable&mode=debug&editio...):

  pub fn foo() -> Result {
      Err(1)
  }
  
  pub fn bar() -> Result {
      foo();
      Ok(())
  }
It will provide a warning, but there's a ton of stuff in c++ that would throw a warning and you wouldn't say that it "will not compile".

A trivial change that still doesn't handle the error would get rid of the warning.

  pub fn foo() -> Result {
      Err(1)
  }
  
  pub fn bar() -> Result {
      println!("{:?}", foo());
      Ok(())
  }

Re: I Want Off Mr. Golang's Wild Ride

#383

Post by Measter »

Animats wrote: post #253
btilly wrote: post #190

Earlier quoted context omitted.

And the other one is the tendency for Go's design to say "exceptions are allowed for me but not for thee". When I worked at Google I used other languages by some of the same authors and they showed the same design philosophy. Make things with an enforced simplicity, and where there were more special use cases that the language designer needed, they created escape hatches for themselves but not the language users.

And the other one is the tendency for Go's design to say "exceptions are allowed for me but not for thee". Yes. Exceptions are kind of a pain, but the workarounds for not having them are worse. Passing back "result" types tends to lose the details of the problem before they are handled. Rust is on, what, their third error handling framework? Exceptions have a bad reputation because C++ and Java botched them. You need…

>Yes. Exceptions are kind of a pain, but the workarounds for not having them are worse. Passing back "result" types tends to lose the details of the problem before they are handled. Rust is on, what, their third error handling framework?

Rust's non-panicking error handling hasn't really changed: you return a Result.

What has changed is the details of how to implement your ErrorType. Should it store some sort of context? What useful helper functions can there be? Things like that. What these error handling frameworks provide is macro-based code generation to implement these details, and extension traits for the helper funcitons. They don't change overall method of error handling.

Or, at least, I've not seen one that does.

Re: I Want Off Mr. Golang's Wild Ride

#384

Post by ben509 »

dralley wrote: post #353
WalterBright wrote: post #338

Earlier quoted context omitted.

Date & Time need to be baked into the operating system so it only has to be gotten right once, and then every programming system benefits.

So long as they actually get it "right". Compare to Windows' APIs originally taking UCS-2, then UTF-16, when now we would all rather be using UTF-8.

In fairness to Windows and Java, they weren't wrong. There was no UTF-16, rather, UCS-2 was the accepted standard because the plan for Unicode was to encompass languages in use, not emojis and historical langauges. That changed and we're stuck with that legacy.

Re: I Want Off Mr. Golang's Wild Ride

#385

Post by luord »

I kept waiting for practical examples that showed how these shortcomings made go a non-starter, and ultimately all I got was a mention, right at the end, about how he hit a particular bug multiple times.

I mean, currently I work in a go shop and I hate nearly everything about it, all just from what he calls "the bad", which is enough to make me not feel precisely happy about writing it. The content of this article, what he calls "the ugly", comes across as a bit nitpicky in comparison.

Nonetheless, it is a good article about string and path handling, time, and being irresponsible with what one is depending on.

Re: I Want Off Mr. Golang's Wild Ride

#386

Post by stjohnswarts »

zgramana wrote: post #102
umvi wrote: post #2

Maybe I'm a zealot, but I don't really consider "doesn't work as well on windows" a con of a language. C# is (or at least used to be) utter garbage on Linux compared to Windows. I don't hold that against C#, but rather recognize that Linux/Windows are very different, and that compiler maintenance and development is non-trivial (and obviously Microsoft is going to prioritize Windows). This article is basically a rant…

Given than Mono-the first open source C# implementation-was used to build banshee going back 15+ years, C# on *nix deserves more credit than is given here.

absolutely, not sure why this dude is dumping on it? Has he even used it in the last 5 years?

Re: I Want Off Mr. Golang's Wild Ride

#387

Post by ajross »

int_19h wrote: post #373
ajross wrote: post #362

Earlier quoted context omitted.

That sounds more like a legal argument than an engineering one. I mean, who cares what the mechanisms are and what the precise rules and enforcement mechanisms are? The point is there are complicated features that are OK in some contexts but not others, that this varies between problems and between languages, and that some parties make different decisions on how to make use of them even when implementing software for…

It is very much an engineering argument, because writing maintainable software requires respecting contracts. If an escape hatch is private, you can't depend on it, because code doing so will break when the hatch changes (and there's no guarantee that it won't).

The discussion is about Go-internal features, and whether or not dogfooding should be required. There's no contract being broken.

Re: I Want Off Mr. Golang's Wild Ride

#388

Post by stjohnswarts »

temac wrote: post #314
bsimpson wrote: post #181

> Nine out of ten software engineers agree: it's a miracle anything works at all There was a beautiful rant about a decade ago called something like "everything's broken all the time and nobody cares." The gist of it is that all software is written by people. Anyone who's written software knows that it's usually riddled with hidden corner cases, unfortunate tradeoffs, rushed deadlines, etc. Software is also moving in…

> Software is also moving into critical spaces like aerospace, medicine, banking, etc. The thrust of the article is that we're trusting more-and-more critical infrastructure to a discipline that anyone who's worked in knows is untrustworthy. "Anyone" who's worked in those industries knows SW can be done in a trustworthy way. At least not less than other engineering disciplines . "hidden corner cases, unfortunate trad…

*self fulfilling prophecy.

Re: I Want Off Mr. Golang's Wild Ride

#389

Post by ben509 »

Karunamon wrote: post #105
jsjddbbwj wrote: post #100

Earlier quoted context omitted.

No, Python is not strongly typed by any serious definition of the concept.

Isn't the existence of TypeError and the various things you're not allowed to do implicitly (eg: 1 + "a", something Javascript will happily let you do) a definition of strongly typed?

If it's qualified as a "serious definition," they're setting up a No True Scotsman argument.

Re: I Want Off Mr. Golang's Wild Ride

#390

Post by ben509 »

throwaway894345 wrote: post #162
fhood wrote: post #35

Earlier quoted context omitted.

I surprises me that most people here aren't up in arms in agreement with this point. Code that is silently incorrect is an absolute disaster on an enterprise level. I spend a lot of time writing seemingly redundant double and triple error checking into my code, only to have the designers of the LANGUAGE say, "yeah, most filepaths are utf-8 so seems good enough to me".

> Code that is silently incorrect is an absolute disaster on an enterprise level. Enterprise software is not well-known for its quality or correctness.

That's a valid point. Enterprise software can be continually buggy and broken and still be commercially viable.

So that things are silently wrong is not a disaster as much as it is a dumpster fire that corporations are happy to shovel cash into while a whole lot of people huddle around it for warmth.

Post reply on HN