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

401–410 of 508 posts

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

#401

Post by physicles »

Having used go full-time for the last 3.5 years, this article didn’t feel like a twist of the knife. Yet all the language evolution efforts I’ve seen in the last two years make me think that early Go was, mixaphorically speaking, lightning in a bottle that won’t strike twice.

- I’ve never hit the file system stuff. We all use Linux; all our code runs on Linux. I’m curious who the people are who are using Go on Windows.

- Network timeouts are a stupid gotcha I first hit about six months into my go tenure. You can set read/write timeouts on the Transport that’s used by the connection though; not sure why that isn’t covered.

- The wall clock time thing is new to me and looks crazy complicated; I’m angry that it’s something I have to know about now. It’s bad enough that time.Time operator == and .Equals() behave mostly but not quite the same.

Something that’s not in the article: the tooling situation (autocomplete, source navigation, and so forth) IS STILL WORSE THAN IT WAS TWO YEARS AGO. The old tools were perfect but were never updated for module support. gopls is still an unfinished mess; last week I had to write a script that auto-kills it if it uses more than 3GB of memory.

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

#402

Post by eudoxus »

g_delgado14 wrote: post #301
lwb wrote: post #294

Earlier quoted context omitted.

Docker’s primary use case is also web services.

Ubuntu is used (mostly?) for web services. Is Ubuntu suitable to be written in Go?

Umm..what? Ubuntus primary use case was not web services, it was a user-friendly PC OS compared to the Linux variants at the time.

It's picked up a lot in the server space because of the familiarity of it, with respect to package management et all.

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

#403

Post by physicles »

fhood wrote: post #35
gameswithgo wrote: post #18

A lot of people seem to be missing an overarching point, which is the benefits of a language having Sum types, so that edge cases can be represented clearly, and in a way where the consumer of the api can't fail to know they exist, and can't fail to handle them. Anyone thinking of making a new language today, should really get some familiarity with Option and Result types. They make so many things not only safer, but…

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

I’ve written go full-time for the last 3.5 years and it still amazes me that by default the linter doesn’t at least warn about unused/uncaptured return error values.

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

#404

Post by eudoxus »

jjuel wrote: post #50
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…

But you knew C# was Windows only. Go was always touted as a cross platform solution due to statically compiled binaries. If said binaries have issues on Windows due to design decisions it seems like a language fault.

The binaries themselves don't have issues. But Go's descision to make the standard library Unix focused isn't a flawed design decision.

If you need OS/platform-specific precision, you're free to create or use an alternative library. The standard lib was never designed to be the magic bullet for cross-platform, but the language internals, compilation, and execution do a good job for many platforms.

We need to keep in focus what the goals of each part of the language are intended for.

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

#405

Post by krebs_liebhaber »

Corrado wrote: post #381
yashap wrote: post #306

Earlier quoted context omitted.

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.

This seems to be a natural result of the fact that the language's creators and implementors work at the same company as the target demographic.

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

#406

Post by krebs_liebhaber »

gavinray wrote: post #110
fasterthanlime wrote: post #89

Earlier quoted context omitted.

I share your conclusion that "the perfect cross-platform library" does not exist, and I also agree that we could use Rust to make one that's worse than the Rust standard library, and we could use Go to make one that's better than the Go standard library. However, Go's limitations make it hard to make one that is much better than the Go standard library. And the Rust standard library is so carefully designed, that the…

Can I give you an utterly useless comment that I am dying to get out of my system now that I see your HN username? I saw the domain name and thought it was a clever phonetic hack, using the dot character literally pronounced to make "faster than li (dot) me", which sounds like "faster than light (dot) me" when you say it out loud. I now see this is not the case at all. Alright, that's all I've got.

I thought it was a play on "quicklime".

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

#407

Post by mntmoss »

WalterBright wrote: post #338
alexhutcheson wrote: post #288

Earlier quoted context omitted.

The author of Joda-Time actually thinks that even Joda-Time didn't get it quite right, and believes the java.time libraries in Java 8 and above (aka JSR-310[1]) are better than Joda-Time: https://blog.joda.org/2009/11/why-jsr-310-isn-joda-time_4941... It turns out that abstractions for time are really hard to get right. [1] https://jcp.org/en/jsr/detail?id=310

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.

That solves the problem for one computer, but I can't see how it would solve it for networks and databases, given a computing environment that will continue to evolve and foil compatibility.

But a time protocol that recieves the wide adoption of TCP/IP might suffice.

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

#408

Post by eximius »

reggieband wrote: post #346
eximius wrote: post #340

Earlier quoted context omitted.

> What I'm suggesting is that wasn't demonstrated. An in-depth analysis of the respective languages APIs for a particular targeted problem isn't enough? I won't disagree that readers might make a leap to intuit the author thinks Rust is overall better. But that extra leap doesn't mean he failed to show Rust was better at a particular problem. In fact, that is WHY people would make that un-warranted leap. > But the po…

> An in-depth analysis of the respective languages APIs for a particular targeted problem isn't enough? It isn't the same . There is another cheeky quote I can paraphrase: Everyone has a plan until they get punched in the face. He is comparing a Go implementation that has been punched in the face in a real-world use case against a Rust implementation that was sitting on the sidelines. If the point of the article (and…

You mean the Rust language that has dozens of cross platform implementations of coreutils binaries? Go might be larger, but I hardly think Rust qualifies as sitting on the sidelines.

That's a fair opinion. I think the article is richer for having shown what a better API can look like for contrast.

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

#409

Post by joshuamorton »

dilap wrote: post #399
joshuamorton wrote: post #379

Earlier quoted context omitted.

Actually hmm, I may want to take back my earlier comment. There are multiple things at play. There's scoping (where rust will copy across scope boundaries for non-ref types, which allows closing over something as in your first example above). Then there's mutable refs and mutable variables, which as hope-striker mentioned I was confusing, possibly because I was using ints in my example. If instead we used a vec: fn m…

Python's scope & mutability rules are idiosyncratic, but that's a distraction from what's going on here. Let's go back to steveklabnik's ancestor comment: "That's not an identical translation, the identical Rust would be:" fn main() { let mut x = 1; x = "foo"; } He was saying the identical Rust would not be: fn main() { let x = 1; let x = "foo"; } These are being compared to the following Python: x = 1 x = "foo" So c…

I disagree that those are doing the same thing. I propose that the actual answer is c:

    use std::cell::RefCell;

    fn mystery_c() -> i32 {
        let x = RefCell::new(1);
        let capture = || x.borrow();
        x.replace(2);
        return *x.borrow() * *capture();
      }
  
    fn main() {
        println!("{}", mystery_c())
    }
Which is what I meant when I said that Box might be the analogous thing (I guess it's actually RefCell, whoops!). And note that in this case, x is immutable :P

That said I accept your broader point, the effect is that python names act like mutable rust names, although the reality is slightly more complex (my final example is, I believe, the closest to actual reality).

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

#410

Post by nwallin »

nonbirithm wrote: post #221
bluejekyll wrote: post #82

Earlier quoted context omitted.

> the author would have been well to leave Rust out of it most of the time. Initially I thought the same, but then I realized that it was being used as a means of expressing that it doesn’t have to be this way. That there are better choices, and here’s an example of better choices. Probably too much detail on the Rust, but using it to contrast with some of the poor decisions pointed out in Go is useful.

Is there a language besides Rust that could be used instead as this example? As in, languages whose standard library was so carefully designed from previous experience that the design of features like Permissions/PermissionsExt and OsString deliberately take into account the design of both Windows and Unix-like internals. The author mentioned part of the reason the filesystem API is so awkward in Go is because Go was…

C++17's std::filesystem is awesome.

One of the benefits of C++'s minimal standard library is that when something finally does get added 20 years after it's an established technology the OS primitives have already solidified. (threads and mutexes in C++11 for another example)

Post reply on HN