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

291–300 of 508 posts

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

#291

Post by dilap »

joshuamorton wrote: post #249
steveklabnik wrote: post #142

Earlier quoted context omitted.

That's not an identical translation, the identical Rust would be fn main() { let mut x = 1; x = "foo"; } which indeed fails to compile with a type error. (That being said there is a conflation of static/dynamic and weak/strong going on in this thread, as there always is in these kinds of discussions.)

I'd disagree that this is a better translation. In python-land, `x` is just a name binding. The closest thing might be that `x` is something akin to a Box , but I don't know that that's cleanly expressible in rust. Like in (modern) python you can totally do def foo(): x: Union[str, int] = 1 x = "foo" which would be akin to in rust ?? (sorry my rust foo isn't great). Specifically the semantics don't work here because…

No, the name is definitely mutable. Consider:

  x = 1
  capture = lambda: x
  x = 'foo'
  print capture()
If python were just shadowing, this would print 1. But it prints foo.

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

#292

Post by rob74 »

rhinoceraptor wrote: post #187
hota_mazi wrote: post #108

Earlier quoted context omitted.

> the majority of which relate to Go's tendency to just be silently completely wrong 100% right on. Go's handling of errors is often ridiculed for its verbosity and lack of thought, but the fact that Go makes it so easy to sweep errors under the rug has real and devastating consequences in the real world. Go programs are much less safe than programs written in Rust or Java for that reason.

It's not surprising that other pieces of golang have incredibly broken assumptions, I know this particular one was discovered independently by many people: https://github.com/golang/go/blob/71ab9fa312f8266379dbb358b9... https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/

I don't think this example justifies the expression "incredibly broken assumptions", I would rather call it an "incredible corner case"...

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

#293

Post by hajile »

Thaxll wrote: post #262
hajile wrote: post #239

Earlier quoted context omitted.

Erlang is a stable language that has been around for a long time (almost 35 years now). It's used for way more mission-critical code than golang is ever likely to be used for. It's weird syntax and performance tradeoffs are very well known, but you still won't see anywhere near the number of complaints that you see against golang.

Erlang is less and less used in telecoms and it's the only place if was really used, lot of things have switch to C/C++/Java. As for the reason why it has less complains it's pretty simple no one uses Erlang and it's a niche, it's not a generic purpose language. I can't even tell a single known application or library written in Erlang.

IBM Cloudant runs everything CouchDB which is written in Erlang as does Amazon for SimpleDB. WhatsApp and a bunch of Pinterest are written in Erlang (they may actually be in Elixir, but on BEAM).

To my knowledge Ericsson still writes most things in Erlang. Yahoo uses it for a couple large services. My company use PagerDuty which is also written on BEAM.

I'm sure there are many, many other things in not familiar with, but claims of Erlang's demise are greatly exaggerated.

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

#294

Post by lwb »

zug_zug wrote: post #281
_bxg1 wrote: post #83

I think the mistake may be assuming that Go is meant to be a general-purpose language. From what I can tell, it's purpose-built to be a "web services" language, and its design-decisions center around that. What does that mean? - It's expected to be run on Linux servers (not Windows) and developer workstations (probably not Windows). - It needs to be fast but not blisteringly fast. Micro-performance concerns like the…

Except docker is written in go. Guess they never got the memo to not use go for non-webservices...

Docker’s primary use case is also web services.

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

#295

Post by joshuamorton »

dilap wrote: post #291
joshuamorton wrote: post #249

Earlier quoted context omitted.

I'd disagree that this is a better translation. In python-land, `x` is just a name binding. The closest thing might be that `x` is something akin to a Box , but I don't know that that's cleanly expressible in rust. Like in (modern) python you can totally do def foo(): x: Union[str, int] = 1 x = "foo" which would be akin to in rust ?? (sorry my rust foo isn't great). Specifically the semantics don't work here because…

No, the name is definitely mutable. Consider: x = 1 capture = lambda: x x = 'foo' print capture() If python were just shadowing, this would print 1. But it prints foo.

That's an issue of scoping, not capturing. The x in the lambda isn't scoped to the lambda, it's scoped to the surrounding environment.

So the x closes not over the lambda but the outer scope. So it's as expected given shadowing.

Edit: Since I'm getting throttled:

No, I'm saying that scoping rules are different in python and rust.

In Rust (and cpp) there's the concept of scopes/closures as a first class feature. This concept doesn't exist in python (python has namespaces, I guess, instead, there's no good terminology here).

See https://stackoverflow.com/questions/2295290/what-do-lambda-f.... This is due to weird scoping, not name mutability.

Second edit:

Well ok on second thought I see where you're going here. I was trying to avoid thinking about copy-on-scope-change behavior, but you actually do have to consider that and you're right.

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

#296

Post by jjnoakes »

_bxg1 wrote: post #83

I think the mistake may be assuming that Go is meant to be a general-purpose language. From what I can tell, it's purpose-built to be a "web services" language, and its design-decisions center around that. What does that mean? - It's expected to be run on Linux servers (not Windows) and developer workstations (probably not Windows). - It needs to be fast but not blisteringly fast. Micro-performance concerns like the…

If the language was meant to be run on unix machines for web services, it shouldn't support anything else in a half-done manner with silent errors and corruption.

The situation as it is now is just poor language and/or library design - choosing to support different operating systems with an API that requires the wrong thing to happen in some cases.

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

#297

Post by AnimalMuppet »

tedmielczarek wrote: post #195
thestoicattack wrote: post #178

Earlier quoted context omitted.

C and C++ don't have good stories for working on embedded systems without a standard library?

Not in the language standard they don't, no. The C99 standard basically says "good luck with that": "5.1.2.1 Freestanding environment 1. In a freestanding environment (in which C program execution may take place without any benefit of an operating system), the name and type of the function called at program startup are implementation-defined. Any library facilities available to a freestanding program, other than the…

And that's all perfectly fine.

If I'm running embedded with no OS, I'm in a very specific environment. My code is going to be tied to my specific hardware, including almost certainly the specific CPU chip. (In this situation, it's usual to have a "CPU" chip that includes several peripherals on-chip, to reduce parts cost. Code is not portable to a CPU with different peripherals, even if it's from the same family.) So, if I can't reuse the code anyway, do I care that I can't reuse the one line that is the "main" function definition?

If I'm running embedded with no OS, what should happen if the program terminates by exiting main? Where is there to go?

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

#298

Post by ptr »

hajile wrote: post #293
Thaxll wrote: post #262

Earlier quoted context omitted.

Erlang is less and less used in telecoms and it's the only place if was really used, lot of things have switch to C/C++/Java. As for the reason why it has less complains it's pretty simple no one uses Erlang and it's a niche, it's not a generic purpose language. I can't even tell a single known application or library written in Erlang.

IBM Cloudant runs everything CouchDB which is written in Erlang as does Amazon for SimpleDB. WhatsApp and a bunch of Pinterest are written in Erlang (they may actually be in Elixir, but on BEAM). To my knowledge Ericsson still writes most things in Erlang. Yahoo uses it for a couple large services. My company use PagerDuty which is also written on BEAM. I'm sure there are many, many other things in not familiar with,…

Erlang is mainly used in the control plane at Ericsson -- you'd never write a DSP in it for example. Most code is sadly not Erlang.

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

#299

Post by rapind »

twic wrote: post #237
whatever_dude wrote: post #37

Earlier quoted context omitted.

This. I like, and agree, with the conclusion, and wish more people would get to it: > Over and over, Go is a victim of its own mantra - “simplicity”. (...) > It constantly lies about how complicated real-world systems are, and optimize for the 90% case, ignoring correctness. > This fake “simplicity” runs deep in the Go ecosystem. I've always liked simplicity and on my own design, I tend to go for abstraction; trying…

A post about fixing Date in JavaScript got me thinking about why it took so long for languages to get good date/time APIs. I think it's because it took so long to accept that date and time really is complicated. If you sit down and work it out carefully, you end up with Joda-Time (more or less - not in all the details, but in the set of abstractions). If you balk at that and make something simpler, you make a subtly…

IMO taking some time to deeply understand typical date / time abstractions is almost as useful as learning SQL, basic algos, and git. It'll keep coming up throughout your career and inevitably bite you in the ass.

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

#300

Post by heelix »

klodolph wrote: post #164
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.

That said… I feel that Rust’s use of WTF-8 for OsString on Windows has resulted in some really nasty problems, especially since OsString doesn’t expose any useful methods for string manipulation. As far as I can tell, Rust’s approach fails to hide any of the complexity, and then adds the additional complexity of a new encoding and conversions on top. I can see that there’s some end goal of being able to work with OsS…

Not a Rust guy, but I did have to look up WTF-8. Had to chuckle at the 'wobbly transformation format' as I was translating it something else. :)
Post reply on HN