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

Go's Sweet 16

go.dev

Post reply on HN
Print view View original

211–220 of 280 posts

Re: Go's Sweet 16

#211

Post by gf000 »

LexiMax wrote: post #70
MagicMoonlight wrote: post #62

I just can’t get over the idiotic syntax. Instead of “int x” You have “var x int” Which obscures the type, making it harder to read the code. The only justification is that 16 years ago, some guy thought he was being clever. For 99.99% of code, it’s a worse syntax. Nobody does eight levels of pointer redirection in typical everyday code.

16 years is a bit of an under-estimate. I think the first popular language with this form of declaration was Pascal. var foo: char; Go was developed by many of the minds behind C, and inertia would have led them to C-style declaration. I don't know if they've ever told anybody why they went with the Pascal style, but I would bet money on the fact that Pascal-style declarations are simply easier and faster for compute…

I have no problem with ident: type. I have problem with dropping the colon between them for no good reason, even though there used to be 2 quite well-established patterns every language adhered to.

Re: Go's Sweet 16

#212

Post by vips7L »

Xeoncross wrote: post #177
vips7L wrote: post #63

Earlier quoted context omitted.

Go is in the same performance profile as Java and C#. There are tons of benchmarks that support this.

1) for one-off scripts and 2) If you ignore memory. You can make about anything faster if you provide more memory to store data in more optimized formats. That doesn't make them faster. Part of the problem is that Java in the real world requires an unreasonable number of classes and 3rd party libraries. Even for basic stuff like JSON marshaling. The Java stdlib is just not very useful. Between these two points, all m…

I genuinely can’t think of anything the Java standard library is missing, apart from a json parser which is being added.

It’s your preference to prefer one over the other, I prefer Java’s standard library because atleast it has a generic Set data structure in it and C#’s standard library does have a JSON parser.

I don’t think discussions about what is in the standard library really refutes anything about Go being within the same performance profile though.

Re: Go's Sweet 16

#213

Post by gf000 »

tapirl wrote: post #88

> Go stands by its compatibility promise—the old way will continue to work in perpetuity ... It is so weird that they still claim this after they have made the the semantic change for 3-clause for-loop in Go 1.22. When a Go module is upgraded from 1.21- to 1.22+, there are some potential breaking cases which are hard to detect in time. https://go101.org/blog/2024-03-01-for-loop-semantic-changes-... Go toolchain 1.22…

It's especially funny considering that this issue has been known from lisps for 50+ years..

Re: Go's Sweet 16

#214

Post by LexiMax »

o11c wrote: post #191
vlovich123 wrote: post #176

Earlier quoted context omitted.

It’s not true of C/C++ which need changes to the build system. Also true for rust workspaces which is how I’d recommend structuring monorepos although it is generally easy (you just need to add a small cargo.toml file) or you can not use a workspace but you still need to declare the binary if I recall correctly.

It's true for any C/C++ project which bothers to write 10 lines of GNU `make` code. The problem is that many projects still pander to inferior 1980s-era `make` implementations, and as such rely heavily on the abominations that are autotools and cmake.

Autotools is far too pessimistic, but there are still considerable differences between different compiling environments. Tooling like CMake will always be necessary unless you are only targeting unix and your dependency graph isn't terribly deep.

Even in that specific niche I find using a programmatically generated ninja file to be a far superior experience to GNU make.

Re: Go's Sweet 16

#215

Post by submeta »

Been writing Python code for over twenty years, and using it for personal and work projects, not mainly, but to suppport my work. Recently I ported some of my code to Go and was blown away: Cross compiler, creating binaries, concurrency done right, super fast code. I come very late to the party, and writing software is not my main job, but Go is such a nice complement for my toolbelt. Python for prototyping or writing small services with fastapi, go for network realted stuff, serving lots of users. Super happy with this.

And I am wondering if Rust would be a good addition. Or rather go with Typescript to complement Python and Go.

Re: Go's Sweet 16

#216

Post by Someone »

mseepgood wrote: post #134
Someone wrote: post #125

Earlier quoted context omitted.

> Which makes sense, it's got the smallest language spec of any of them I think go is fairly small, too, but “size of spec” is not always a good measure for that. Some specs are very tight, others fairly loose, and tightness makes specs larger (example: Swift’s language reference doesn’t even claim to define the full language. https://docs.swift.org/swift-book/documentation/the-swift-pr... : “The grammar described he…

You're looking at the wrong production. They are octal literals: octal_lit = "0" [ "o" | "O" ] [ "_" ] octal_digits .

Thanks! Never considered that a 21st century language designed for “power of two bits per word” hardware would keep that feature from the 1970s, so I never looked at that production.

Are there other modern languages that still have that?

Re: Go's Sweet 16

#217

Post by bayindirh »

duskwuff wrote: post #196
o11c wrote: post #191

Earlier quoted context omitted.

It's true for any C/C++ project which bothers to write 10 lines of GNU `make` code. The problem is that many projects still pander to inferior 1980s-era `make` implementations, and as such rely heavily on the abominations that are autotools and cmake.

C/C++ library dependencies are a thing, and there's no universal solution to acquiring and installing them.

The most universal thing in C/C++ is vendoring, IMHO.

If you are distributing source, you distribute everything. Then, it only needs a compiler and libc. That vendored package is tested, and it works on your platform, so there's no guesswork.

Re: Go's Sweet 16

#218

Post by arccy »

millerm wrote: post #160
zerr wrote: post #145

Earlier quoted context omitted.

One thing I don't like when it comes to Golang jobs - it is rare to see pure software engineering positions. For some reason, most Go jobs requirements include AWS, Kubernetes/Docker, CI/CD setup, etc... DevOps stuff, which is not the case for positions in other stacks.

I haven't been able to find a job anywhere, using any language, that didn't require all that stuff these days. I wish I could go back to pure development, but now we all get this entire infra-crap thrown at us too. Which then means... you support the environments, the runtime, and the code. It's a 24/7 world and I don't care for it anymore.

it's alignment of incentives.

nowadays devs are less inclined to pump out crappy code that ends up with some ops guy having to wake up in the middle of the night

Re: Go's Sweet 16

#219

Post by Mawr »

dmoy wrote: post #127
Mawr wrote: post #105

Earlier quoted context omitted.

Yeah, but just going back to warnings would be a regression. I believe the correct approach is to offer two build modes: release and debug. Debug compiles super fast and allows unused variables etc, but the resulting binary runs super slowly, maybe with extra safety checks too, like the race detector. Release is the default, is strict and runs fast. That way you can mess about in development all you want, but need to…

> Debug compiles super fast and allows unused variables etc, but the resulting binary runs super slowly, maybe with extra safety checks too, like the race detector. At least in the golang / unused-vars at Google case, allowing unused vars is explicitly one of the things that makes compilation slower. In that case it's not "faster compilation as in less optimization". It's "faster compilation as in don't have to chase…

Right, I meant that the binary should run slowly on purpose, so that people don't end up defaulting to just using the debug build. A nice way of doing so without just putting `sleep()`s everywhere would be to enable extra safety checks.

Re: Go's Sweet 16

#220

Post by bborud »

o11c wrote: post #191
vlovich123 wrote: post #176

Earlier quoted context omitted.

It’s not true of C/C++ which need changes to the build system. Also true for rust workspaces which is how I’d recommend structuring monorepos although it is generally easy (you just need to add a small cargo.toml file) or you can not use a workspace but you still need to declare the binary if I recall correctly.

It's true for any C/C++ project which bothers to write 10 lines of GNU `make` code. The problem is that many projects still pander to inferior 1980s-era `make` implementations, and as such rely heavily on the abominations that are autotools and cmake.

This is the theory, yes. And then reality comes bursting through the door and you are confronted with the awfulness that is the C/++ toolchain. Starting with multi-OS, multi-architecture builds, and then plunging into the cesspit that is managing third party dependencies.

Let’s be real. C/++ has nothing even approaching a sane way to do builds. It is just degrees from slightly annoying to full on dumpster fire.

Post reply on HN