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

I want off Mr. Golang’s Wild Ride (2020)

fasterthanli.me

Post reply on HN
Print view View original

321–330 of 477 posts

Re: I want off Mr. Golang’s Wild Ride (2020)

#321

Post by jokethrowaway »

sph wrote: post #290
Jyaif wrote: post #252

Earlier quoted context omitted.

Can you see the value in being able to create software more quickly, at the expense of the software's stability?

No, the compiler needs to save us from ourselves. What if we get a runtime nil? Oh God, the horror! I understand correctness, I do not understand why we're making languages a nanny state where if we're not completely focused on correctness and zero copy interfaces it's not worth using. I don't want to always care about memory allocation strategies when I want to have some fun on a project. I don't understand why a vo…

I used to prototype in PHP and nowadays I prototype in JS.

I also ship JS in production and it's a painful experience compared to rust or haskell.

Re: I want off Mr. Golang’s Wild Ride (2020)

#322

Post by throw10920 »

throwaway894345 wrote: post #124
throw10920 wrote: post #109

Earlier quoted context omitted.

> Scrolling IMO is a lot easier than squinting to parse dense code. This is a false dichotomy - there's a third option, which is not squinting (because, presumably, you're doing so because you decreased your font size), and being able to see more on the screen at the same time. Moreover, scrolling is bad for cognition . It's pretty well-known that the human brain likes to use spatial maps - that's the reason why memo…

> This is a false dichotomy - there's a third option, which is not squinting (because, presumably, you're doing so because you decreased your font size), and being able to see more on the screen at the same time. It's not a false dichotomy. Visual structure (via whitespace) comes at the expense of strict information density (assuming a fixed font size). If this is not true, then we would never have any (syntactically…

> Density divorces us from context a lot more than physical distance on a screen.

You mean "unreadable code divorces us from context". "Density" doesn't have anything to do with it until you get to the point where your code is so dense as to become unreadable.

Moreover, "physical distance on a screen" is a strawman. The options aren't density and distance, they're density and not being able to see the code on the screen at all - between which, density is objectively better.

Seeing context is always better than not seeing context, assuming equal readability. Go's verbosity is both less readable and less dense than that of other, better-designed languages.

Re: I want off Mr. Golang’s Wild Ride (2020)

#323

Post by zasdffaa »

lliamander wrote: post #311
zasdffaa wrote: post #283

Earlier quoted context omitted.

You don't get always to choose your language, and even then there will be stuff that needs automated cut & paste at a level that the language can't provide (even down to the lexeme level). Which is why I use generated code for my C# work. I use python rather than a preprocessor but either would do. Prepros and code generation in general are just tools, no more nor less, and not good or bad intrinsically. There is no…

I use preprocessors for Java. I'm not averse to using them when I have to work in a more verbose language. And you are right that we often don't have a choice of language to work in. But they are still a sign that the language you are using is deficient. Preprocessors may ameliorate those problems somewhat, but they come with their own costs and complexities. For anyone who is in the position of making a language cho…

Now this is an answer I can work with!

I completely agree they represent a language deficiency and that should be rectified within the language, but that's not always practical than or even possible. Sometimes you have to fiddle with the language at the lexeme level [edit: at the token level, messing about with single keywords for example], which most (all?) most templates/generics won't allow you to do. Also the input to a code generator can be heck of a lot more compact and readable than the code it outputs, as that's a win.

Heavily modified example based on my actual code (no animals harmed):

   makeClasses = [
       ("Dog", "chases", "Cat"),
       ("Fox",  "eats", "Chicken"),
   ...
each line of which produces a small class.

Also completely agree they come with their own costs, but sometimes the cost is lower than the cost of not using code generation.

Re: I want off Mr. Golang’s Wild Ride (2020)

#324

Post by shadowgovt »

lliamander wrote: post #293
shadowgovt wrote: post #277

Earlier quoted context omitted.

Out of curiosity (if you're at liberty to say), what has bit you? I do Node / TypeScript basically all day these days, and I'm probably too close into the forest anymore; I'm wondering if other people are getting bitten by things that I just roll right past because I'm used to the pain. The extremely weak (and frankly incorrect) Date handling that's built into JavaScript is the first thing that comes to mind.

Fair question, here's a few: - object methods cannot be passed as arguments to a function or another method like regular functions can because they lose their 'this' pointer. - array.sort() is broken. It does the sort in-place and converts the elements to strings before sorting . - const doesn't support separate declaration and assignment. This makes it harder to conditionally decide what to assign to a variable whil…

That's a good list, and I was right; I've been at this so long I've forgotten that most of those are 'WAT' to the average user.

Regarding `object methods cannot be passed as arguments to a function or another method like regular functions can because they lose their 'this' pointer.`: yeah, the fact that JS objects are actually kinda weird li'l things is frustrating. There are nowadays two ways to handle that:

- referencing the object in a closure binds the object instance. `(x) => foo.bar(x)` will do the right thing

- there is an explicit bind operator, so you can do `myCallbackTaker(instance.myFunction.bind(instance))`

... but I agree that in a better language, you'd be expected to do neither of those things.

Re: I want off Mr. Golang’s Wild Ride (2020)

#325

Post by throwaway894345 »

throw10920 wrote: post #322
throwaway894345 wrote: post #124

Earlier quoted context omitted.

> This is a false dichotomy - there's a third option, which is not squinting (because, presumably, you're doing so because you decreased your font size), and being able to see more on the screen at the same time. It's not a false dichotomy. Visual structure (via whitespace) comes at the expense of strict information density (assuming a fixed font size). If this is not true, then we would never have any (syntactically…

> Density divorces us from context a lot more than physical distance on a screen. You mean " unreadable code divorces us from context". "Density" doesn't have anything to do with it until you get to the point where your code is so dense as to become unreadable. Moreover, "physical distance on a screen" is a strawman. The options aren't density and distance, they're density and not being able to see the code on the sc…

> You mean "unreadable code divorces us from context". "Density" doesn't have anything to do with it until you get to the point where your code is so dense as to become unreadable.

As density increases, the difficulty of parsing also increases. At a certain, relatively early point, that difficulty rapidly exceeds the costs of scroll-and-scanning.

> Moreover, "physical distance on a screen" is a strawman. The options aren't density and distance, they're density and not being able to see the code on the screen at all - between which, density is objectively better.

Well, we know density is not "objectively better" because scrolling exists (granted, if you have a hard requirement on a code editor that doesn't allow for scrolling, then you should definitely stick with the densest language you can find), and a little scroll-and-scanning is better than parsing dense code.

Re: I want off Mr. Golang’s Wild Ride (2020)

#326

Post by iudqnolq »

sph wrote: post #297
lakomen wrote: post #160

Earlier quoted context omitted.

I concur. I was used to a professional tone, then joined discord-go. Showed some of my online code to receive a "shit structure" response by some anime girl avatar youngling. When I started explaining how I don't think docker is the way to go I was met with passive aggressive behavior and plain false responses trying to justify its use. But Go's discord server wasn't to only bad experience. Angular might as well have…

You can't base your opinion on anything, particularly computer languages, off of your Discord experience, come on. The Discord demographic is teenagers and young adults, that's the last place where you'd find professional and mature advice about a programming language. I mean, even Reddit is better, and it still is a cesspool.

I've found the rust discord nice and respectful (although I'm also a young adult). I also don't think [edit: PL] reddit is particularly a cesspool, at least compared to HN.

Re: I want off Mr. Golang’s Wild Ride (2020)

#327

Post by sfvisser »

Mawr wrote: post #310
fasterthanlime wrote: post #191

Earlier quoted context omitted.

What an extremely convenient template to dismiss any nuanced argument against "worse is better". You even get to question my credentials a couple times! (I apparently pick metrics that are convenient to my argument, and fundamentally misunderstand programming language design). Even if I accept the premise that "I'm challenging Go on things it doesn't promise to deliver" (which is disingenuous to begin with — correctn…

> What an extremely convenient template to dismiss any nuanced argument against "worse is better". Nuance is exactly what I'm arguing for, there's none in the article. > You even get to question my credentials a couple times! (I apparently pick metrics that are convenient to my argument, and fundamentally misunderstand programming language design). You're right, I apologize. I usually try hard to never directly addre…

> It's perfectly valid to trade off correctness for gains elsewehere.

Agreed, but no-one is disputing that, right? The problem is that very often saying correctness was given up in order to gain velocity and simplicity is simply a lie. Incorrectness can easily lead to slow development and tons of complexity.

It’s only fun when the trade-off is actually a trade-off.

Re: I want off Mr. Golang’s Wild Ride (2020)

#328

Post by tandr »

christophilus wrote: post #280
jitl wrote: post #94

Earlier quoted context omitted.

- Most Node code I encounter that uses “streams” gets something wrong. Usually minor, sometimes major stuff like forgetting errors exist altogether, or to reject a promise wrapper when an error occurs. - Incorrect use of concurrency stuff like process.nextTick. This function probably doesn’t do what you think it does based on the function name - it won’t “yield to the event loop”. - for years Buffer and friends was t…

> Most Node code I encounter that uses “streams” gets something wrong This is really true. I ported a Node project to Go for this reason, and the streams in Go were miles easier to reason about.

Sorry, what are Go's "streams"? Thank you!

Re: I want off Mr. Golang’s Wild Ride (2020)

#329

Post by christophilus »

tandr wrote: post #328
christophilus wrote: post #280

Earlier quoted context omitted.

> Most Node code I encounter that uses “streams” gets something wrong This is really true. I ported a Node project to Go for this reason, and the streams in Go were miles easier to reason about.

Sorry, what are Go's "streams"? Thank you!

Their reader / writer interfaces, basically. It's not exactly equivalent, but for my usecase, it was.

Re: I want off Mr. Golang’s Wild Ride (2020)

#330

Post by christophilus »

kaba0 wrote: post #300
mause_piep wrote: post #281

What would be a good alternative to Go, with - large and well maintained standard lib - great runtime characteristics - esp. reasonable memory usage - developer ergonomics - matureness - long term stability - preferably managed memory I really have used a lot of languages. They all have some downsides. I like Kotlin a lot but the JVM is just to cumbersome and resource heavy. Grade is way to complex. Rust is way to cu…

How is the JVM cunbersome? I do understand your concern about it using more memory (though I feel it is often overblown. Sure, it’s not a hand-optimized C executable, but the performance is top-notch and the memory usage can be very well controlled)

The binaries you get from GraalVM are bigger than Go's and if you are doing something like hosting a bunch of little services on a cheap VPS, Go definitely is nicer there.
Post reply on HN