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

Why I Don't Like Golang (2016)

teamten.com

Post reply on HN
Print view View original

271–280 of 297 posts

Re: Why I Don't Like Golang (2016)

#271

Post by amedvednikov »

baby wrote: post #267
amedvednikov wrote: post #244

Earlier quoted context omitted.

Always interested in feedback, thanks. Why do you find them unreadable, because of the angle brackets? I've considered using struct Repo ⟨T⟩ { db DB } Instead of struct Repo { db DB } The conversion would be done automatically by vfmt.

Because they are too general. The ultimate test is to read someone else's code and try to figure out what is the actual struct being used in place. You will see that you often have to jump through many many files in order to get a sense of what is actually used in place. This problem becomes even harder when people start nesting generics. Take a look at associated types in Rust. I think it is a better way to do gener…

I see, thanks. Right now V supports generics with only one type T anyway :)

Re: Why I Don't Like Golang (2016)

#272

Post by amedvednikov »

jsjolen wrote: post #247
amedvednikov wrote: post #116

I created a new language [0] that is very similar to Go, but it fixes many things people often complain about, including all of the points in this article (except #2, but I don't think it's a drawback, really). It got lots of attention in a couple of months since the public release, and I often hear people say that they feel like this is "Go done right". It'll be open sourced by June 20. [0]: https://vlang.io

If the size of a struct is changed through hot-code reloading then how does the runtime react?

Only function bodies can changed.

I don't think it's possible to modify structs on the fly.

Maybe it is, I need to think about it/do research.

Re: Why I Don't Like Golang (2016)

#273

Post by WalterBright »

gerbilly wrote: post #253
WalterBright wrote: post #70

Earlier quoted context omitted.

I love C, but it's biggest mistake is clearly the unstoppable decay of arrays to pointers: https://www.digitalmars.com/articles/b44.html A mistake that C++ missed an opportunity to fix.

I read the article you linked. It's too bad they didn't decide to pass a fat pointer with the array dimensions. But when the article implies that null terminated strings and the problems associated with them are caused by arrays decaying to pointers, I get more skeptical. I mean it's not as if arrays in C are bounds checked anyway, so how would that have helped implement strings any better? I guess you could have bou…

> I mean it's not as if arrays in C are bounds checked anyway, so how would that have helped implement strings any better?

I've written an awful lot of C code, and I have much experience with the D way which uses arrays instead of null termination.

When I review a section of code consisting of strlen/strcat/strcpy/etc. I routinely find bugs in it, always centered around a mistake with the 0 termination.

When the array bounds are available, the compiler can optionally insert array bounds checks.

As for getting it for free, avoiding doing the strlen()'s is a big time saver.

Re: Why I Don't Like Golang (2016)

#274

Post by blablabla123 »

kstenerud wrote: post #246
blablabla123 wrote: post #242

Earlier quoted context omitted.

Not sure, I mean there are clear workarounds for the debugging stage, before pushing into a public branch one would probably remove those the same way one would remove other ad hoc debugging code. Of course there are official reasons for this: https://golang.org/doc/faq#unused_variables_and_imports Speaking of myself, in various programming languages both ancient and modern I've run into the situation where debugging…

Yes, the workaround for unused things is: - comment out a line of code to check something. - compile, get an error about unused variables because a variable is unused now that the line that used it is commented out. - go back to the code and comment out that other line. - compile, get another error because there's another two variables that are now unused. - comment those lines out. - compile, get another error becau…

I must admit it's not perfect. What I usually do is add

    _ = unusedVar
and then do the debugging stuff. Not sure why, but over time I ran into this procedure far less often but I do very pedantic error checking like

    return fmt.Errorf("foo(%v): %v", fn, err)
and putting in checks sometimes that can return custom errors. So in my log I often end up with messages like "bar: baz: foo(/data.txt): open: file not found". Debugging usually means for me replacing

    return err
with a more verbose

    return fmt.Errorf("...: %v", err)
and adding mentioned checks and/or additional log messages. Either with the log package or logrus. (And possibly adding unit tests/factoring out code into separate functions.) This gives me information content like in a full Java stack trace but in one line.

But YMMV, probably it also depends what kind of software one writes.

Re: Why I Don't Like Golang (2016)

#275

Post by matt_kantor »

weberc2 wrote: post #49
seandougall wrote: post #36

Earlier quoted context omitted.

If you get a pebble stuck in your shoe, you can usually get over it within a couple minutes, and start to ignore the minor annoyance. But if it stays there all day, it could eventually get pretty painful. It all depends on how much walking you do.

And to the parent’s point, most people simply learn to remove the pebble in the first month. ;)

The pebble is still there, but most people learn to walk in such a way that they don't put their full weight on that part of their foot.

This might not be the most efficient way to walk, but once you've done it for a while it starts to feel natural.

Re: Why I Don't Like Golang (2016)

#276

Post by jsjolen »

amedvednikov wrote: post #272
jsjolen wrote: post #247

Earlier quoted context omitted.

If the size of a struct is changed through hot-code reloading then how does the runtime react?

Only function bodies can changed. I don't think it's possible to modify structs on the fly. Maybe it is, I need to think about it/do research.

Don't worry, it pretty much isn't possible to do so without semantics which will basically make your program "drift" during run-time away from what a newly compiled program would do.

EDIT: Assuming inlining and call-by-value struct is a possibility.

Re: Why I Don't Like Golang (2016)

#277

Post by gravypod »

apta wrote: post #142
jayd16 wrote: post #64

Earlier quoted context omitted.

I see this complaint against Java a lot. If you're going to slum it in a language with no ecosystem so you don't feel overwhelmed, why not just use less of the Java ecosystem?

These complaints are usually by people who have not been using modern Java, or who have just been reading or hearing unsubstantiated claims about it. Or who haven't worked in large golang projects to see all the mess it brings with it because of how underpowered it is. Look up libraries like Spark[1] or Javalin[2] and you get something quite light weight. Or DropWizard[3] if you need something more holistic. That bei…

I've used Spark in prod. Worked great and was the highest QPS service in the company I worked at. It was pushing >5GB/hour of JS over ~50 running containers at more than ~1000QPS/container each doing a bunch of crypto (AES) & and data wrangling (JDBC). Only thing that was difficult was serving SSL but that was the Java SSL-key ecosystem's fault. Ideally SSL would come from an edge load balancer but this company had a strange requirement that there was no 80 traffic.

Re: Why I Don't Like Golang (2016)

#278

Post by jstimpfle »

pjmlp wrote: post #270
jstimpfle wrote: post #257

Earlier quoted context omitted.

UB is not what makes C fast. A good (and fast) program does not contain undefined behaviour, at least ideally. The only speed advantage of Fortran, to my knowledge, comes from pointer aliasing information that C compilers have a harder time to infer. But that's more a consequence of the programming domain. Fortran is not a systems programming language. Fortran has specialized data structures for scientific computing…

Fran Allen begs to differ. Plus the experience from all from us that had access to early C compilers on CP/M and home micros. IBM already had a LLVM like toolchain for their RISC research with PL.8 and respective OS. Only later did they switch to UNIX due to the market they were after. Surviving mainframes are still writen on their system languages. As for Fran Allen point of view: "Oh, it was quite a while ago. I ki…

Why do you keep sidestepping logical arguments with irrelevant quotes? Correct programs don't contain UB (even the fast ones), so UB is not what makes C fast.

Not checking for UB (aka invalid configurations) at runtime is what makes C (and any other language) fast - or more precisely, it's what allows compilers to emit efficient code.

Some languages / compilers rule out UB statically through the type system or other means, but that comes with tradeoffs that might, or might not, be worth making in your domain.

Re: Why I Don't Like Golang (2016)

#279

Post by weberc2 »

matt_kantor wrote: post #275
weberc2 wrote: post #49

Earlier quoted context omitted.

And to the parent’s point, most people simply learn to remove the pebble in the first month. ;)

The pebble is still there, but most people learn to walk in such a way that they don't put their full weight on that part of their foot. This might not be the most efficient way to walk, but once you've done it for a while it starts to feel natural.

And then you switch to Go thereby removing the metaphorical pebble, but you have to relearn how to walk efficiently. See how pointless this is?

Re: Why I Don't Like Golang (2016)

#280

Post by pjmlp »

jstimpfle wrote: post #278
pjmlp wrote: post #270

Earlier quoted context omitted.

Fran Allen begs to differ. Plus the experience from all from us that had access to early C compilers on CP/M and home micros. IBM already had a LLVM like toolchain for their RISC research with PL.8 and respective OS. Only later did they switch to UNIX due to the market they were after. Surviving mainframes are still writen on their system languages. As for Fran Allen point of view: "Oh, it was quite a while ago. I ki…

Why do you keep sidestepping logical arguments with irrelevant quotes? Correct programs don't contain UB (even the fast ones), so UB is not what makes C fast. Not checking for UB (aka invalid configurations) at runtime is what makes C (and any other language) fast - or more precisely, it's what allows compilers to emit efficient code. Some languages / compilers rule out UB statically through the type system or other…

Because C guys keep spreading the false arguments that C was some kind of language sent by god to solve all performance issues, while we in the trenches when the language sprung into existence know it wasn't never the case.

Not to mention the fact that other programming languages, on the mainframe and workstation space, were already starting to collect the benefits of whole program optimizers.

Post reply on HN