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

I Love Go; I Hate Go

dtrace.org

Post reply on HN
Print view View original

191–200 of 329 posts

Re: I Love Go; I Hate Go

#191

Post by _ak »

fauigerzigerk wrote: post #150
_ak wrote: post #110

Earlier quoted context omitted.

40 ms mutator time per 50 ms time window. That means that your program will never be interrupted for longer than 10 ms within 50 ms. In practice, the STW mark and sweep phases are in the sub-millisecond range, and the GC runs not nearly as often as 20 times a second, so 10 ms of interruptions per 50 ms is the absolute worst case.

I think these are goals, not guarantees, and the numbers are predicated on assumptions about extra free memory available to the GC. There is an inherent tradeoff between pauses, throughput and extra memory requirements.

Well, the latency is capped at 10 ms, the STW phases will stop at that limit. So that guarantee can be kept as long as your memory allocation throughput is low enough so as not to trigger a GC run more than 20 times a second. Which is pretty good. There aren't that many GC implementations in production that will give you a guarantee of the same or similar quality.

Re: I Love Go; I Hate Go

#192

Post by gnuvince »

zaphar wrote: post #166
gnuvince wrote: post #162

Earlier quoted context omitted.

Rust warns you about those things; allows for quicker iteration in development, and gives you a list of things to address when you are ready to polish.

There are a lot of languages that warn you about such things. There are also a lot of projects in those languages that spit out a hundreds of warnings when they compile. Are those warnings bugs? Were they examined by someone to make sure they are acceptable? The older the project the less likely the above is true. Go eliminates an entire class of bugs with this feature. It doesn't just make them detectable and less l…

> On a side note why do we as developers tend to prioritize making the act of writing code easier than the far more frequent act of maintaining that code?

Different phases of the development process call for different priorities: in early dev, you want reduced friction and quick turn-around time (something that the unsed imports and variables errors in Go infringe upon). Later on, you want maintainability and ensure that things don't randomly break (at this point, those errors become quite desirable). We shouldn't emphasize readers over writers all the time, we should emphasize them when it's the correct time to do so, which I'll admit is the majority of the time.

> Optimizing writing you code over reading and maintaining that code long term seems like a case of premature optimization to me.

That's actually something I've been thinking about quite a bit in the past few weeks :) I think if we were really concerned about readability of code, we would have much better literate programming tools (e.g., better integration with existing dev tools) and our programs would be written with the intent of being read by others. How many times have we felt lost in a foreign code base (or worse, a code base we wrote, but don't remember too well) trying to implement a change and not knowing or understanding some of the design decisions, being unaware of key assumptions, etc. There is a lot more to readability and understandability than having functions without unused locals. (By the way, why is it okay for a function to have unused input parameters?)

Re: I Love Go; I Hate Go

#193

Post by laumars »

patates wrote: post #168
laumars wrote: post #158

Earlier quoted context omitted.

> Let me develop first, and not force me to optimize prematurely. I'd argue that cleaning unused code as you work isn't optimisation. It's a part of the refactoring process of development which is something that must happen during the main development phase. But arguments for and against aside, most developers don't see these kinds of compiler errors that often as you'd generally be commenting out unwanted code while…

> It's a part of the refactoring process of development which is something that must happen during the main development phase How is it refactoring if my code never builds in the first place? > pragmatically that still takes up such an insignificant amount of effort when compared with the overall time spent writing code in any particular language. Which is why many Go advocates are willing to put up with it. It's not…

> How is it refactoring if my code never builds in the first place?

Why would you be typing in imports that you've never used? I guess that could happen, but the more likely scenario you had used them at some point, even if just briefly, and then you're refactoring the code.

> It's not a time problem. It's a focus problem. I'm working on something and then out of nowhere, receive compilation errors, [...] pushed down the developers throat with false, dogmatic reasoning

Please don't be so melodramatic. It doesn't happen "out of nowhere" - you've purposely requested the compiler runs. And if you're compiling then you're doing so to either test your code compiles or test it runs - in either case your focus has already intentionally shifted from writing code to testing and debugging it.

> Don't get me wrong: I have huge respect to the people who created go. I just don't like when people defend all the choices they made as "one true way".

I'm not defending it. I'm saying people are being melodramatic about the actual inconvenience it causes. In all of the years I've been writing Go, I think I've spent just as much time coding around that annoyance than I've spent in this thread chatting about it. The difference being, occasionally that annoyance is useful where as the internet arguments about it literally serves no benefit to anyone.

Re: I Love Go; I Hate Go

#194

Post by jsmith0295 »

devishard wrote: post #189
_ph_ wrote: post #160

I like Go quite a lot. Mainly I am a Lisp programmer, so I am not looking for the next most high level programming language. I am looking for a language which gets things done, where Lisp doesn't quite fit. For jobs, which traditionally would have been done in C. Programs that run fast and have a reasonable complexity. It brings back the virtues of the Wirth computer language family back into modern times, as with st…

This post is yet another reinforcement of my assertion that the people who like Go only like it because they have no idea what has happened in programming languages for the last few decades. Case in point: > It brings back the virtues of the Wirth computer language family back into modern times, as with strict type checking and the module system. Strict type checking? Have you used any other languages besides C ? Go'…

Maybe if by "people who know about types languages" you mean "Haskell snobs"

Re: I Love Go; I Hate Go

#195

Post by Klathmon »

tigershark wrote: post #179
sagichmal wrote: post #84

Earlier quoted context omitted.

> There are two phases: active development and release > engineering. For you, perhaps. Go encourages you to think about your problem and develop it in the "release engineering" style from the very beginning. This is a virtue of the language, in my view.

No, there is no encouragement here. Go forces you to treat things that have always been just warnings in other languages as errors. And I wouldn't call a virtue something that doesn't give you a choice. I will be really pissed off if the language thinks that I'm so idiot that I need errors instead of simple warnings for the cases discussed here.

You are human, humans forget, humans get distracted, humans think that their situation is the exception that makes the rule.

A program doesn't suffer from that. Forcing these things to be showstoppers makes sure they NEVER become a problem, and the "cost" (in terms of the developer) is pretty small in the grand scheme of things.

Re: I Love Go; I Hate Go

#196

Post by comex »

_ph_ wrote: post #160

I like Go quite a lot. Mainly I am a Lisp programmer, so I am not looking for the next most high level programming language. I am looking for a language which gets things done, where Lisp doesn't quite fit. For jobs, which traditionally would have been done in C. Programs that run fast and have a reasonable complexity. It brings back the virtues of the Wirth computer language family back into modern times, as with st…

Heh: my initial thought was that Go is nothing like Lisp - Lisp has the most powerful metaprogramming around thanks to its macro system, while Go doesn't even have C-level macros, or any of the type-system features some languages use as an alternative approach to metaprogramming. As a result Lisp is notoriously unopinionated, while Go is very opinionated. Lisp is functional, Go is aggressively imperative. And so on. But I guess the languages share some things: no complex type system, fast compiles, emphasis on simplicity in general, no need for an IDE, old fashioned feel (no, really, that's not a diss necessarily)... and at least Go has reflection.

Re: I Love Go; I Hate Go

#197

Post by pierre_massat »

devishard wrote: post #189
_ph_ wrote: post #160

I like Go quite a lot. Mainly I am a Lisp programmer, so I am not looking for the next most high level programming language. I am looking for a language which gets things done, where Lisp doesn't quite fit. For jobs, which traditionally would have been done in C. Programs that run fast and have a reasonable complexity. It brings back the virtues of the Wirth computer language family back into modern times, as with st…

This post is yet another reinforcement of my assertion that the people who like Go only like it because they have no idea what has happened in programming languages for the last few decades. Case in point: > It brings back the virtues of the Wirth computer language family back into modern times, as with strict type checking and the module system. Strict type checking? Have you used any other languages besides C ? Go'…

Why is the type system a joke (genuine question)?

Re: I Love Go; I Hate Go

#198

Post by scott_s »

devishard wrote: post #190
_ph_ wrote: post #171

Earlier quoted context omitted.

Sometimes I like to have a fully statically typechecked program. You can do that in Lisp, its easier in Go. Also, it directly produces statically linked executables. You can do a lot of this in SBCL, it also produces executables, has type checking etc. But for some of this, you have to wrestle a bit with the Lisp system. The Common Lisp numeric tower is great - until you want to write low level programs where you jus…

> Sometimes I like to have a fully statically typechecked program. Wait, I thought we were talking about situations where Go was appropriate. What do you use when you want a fully statically typechecked program?

Please don't do this. You obviously disagree that Go is a language which provides full static typechecking. Please instead just state that disagreement, rather than feign confusion. It leads to much better discussions.

Re: I Love Go; I Hate Go

#199

Post by Leon »

millstone wrote: post #57
buro9 wrote: post #54

Earlier quoted context omitted.

goimports guesses the one you want and adds it back.

My question was, since goimports modifies your document (and gofmt even more so), is your undo stack preserved across saves? If so, how?

I believe it has worked well for me for undo. However some other Atom formatters have broken my undo in weird ways, namely the formatter for Node JS I had turned on to auto format on saves. I had to turn it off.

Re: I Love Go; I Hate Go

#200

Post by EugeneOZ »

masklinn wrote: post #175
EugeneOZ wrote: post #161

Earlier quoted context omitted.

Are you drunk? You are responding to the branch my comment started, comment was about error messages and your response contain words: "And while many Rust messages are OK, one should be careful not to confuse familiarity with Rust's error messages[0] with Rust's error messages being good (being inherently informative and good)." So you will still try to pretend we are not talking about error messages here?

> Are you drunk? I'd appreciate you not insulting me, as well as you starting to make sense. > You are responding to the branch my comment started I was not, however, replying to your comment. As I already told you I was replying to valarauca1's comment, which is why my own comment was threaded below and in reply to it, and quoted it. > So you will still try to pretend we are not talking about error messages here? I'…

My question is not more offensive than your "what the hell you are talking about". I regret I don't have "ignore" button for talks like this.
Post reply on HN