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

191–200 of 280 posts

Re: Go's Sweet 16

#191

Post by o11c »

vlovich123 wrote: post #176
liveoneggs wrote: post #173

Earlier quoted context omitted.

I don't understand how this isn't also true for practically every other language?

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.

Re: Go's Sweet 16

#193

Post by jiehong »

culebron21 wrote: post #87

To me, Go is like Rust oversimplified beyond reason. It edits your code when you don't ask, removing things you just started; it lacks iterators -- every time you must write a big cycle instead. It lacks simple things like check if a key exists in a map. Proponents say it has nothing under the hood. I see under-the-hood-magic happen every time. 1) The arrays append is one example. Try removing an element from an arra…

One thing Go took from C that I dislike: overly short variable names (like in interface names when implementing function are usually 1 or 2 letters, but also chan!).

Other random things I hate:

- first element in a struct, if unnamed, acts like extending a struct;

- private/public fields of method based on capitalisation (it makes json mapping to a struct have so much boilerplate);

- default json lib being so inept with collections: an empty slice is serialised as null/absent (empty list is not absence of a list, WTF, but the new json lib promises to fix that json crap);

- error type being special, and not working well with chanels;

- lambda syntax is verbose;

- panics (especially the ones in libs);

- using internal proxy in companies for packages download is very fiddly, and sucks.

But, the tooling is pretty good and fast, I won’t lie. The language won’t win beauty contests for sure, but it mostly does the job. Still weak at building http servers (limited http server libs with good default headers, very limited openapi spec support).

Re: Go's Sweet 16

#194

Post by jchw »

goranmoomin wrote: post #124
jchw wrote: post #25

Earlier quoted context omitted.

Just so we're on the same page, this is the current JS spec: https://262.ecma-international.org/16.0/index.html I don't agree. (And frankly don't like using JS without at least TypeScript.)

While I might not think that JS is a good language (for some definition of a good language), to me the provided spec does feel pretty small, considering that it's a language that has to be specified to the dot and that the spec contains the standard library as well. It has some strange or weirdly specified features (ASI? HTML-like Comments?) and unusual features (prototype-based inheritance? a dynamically-bounded thi…

Shrugging it off as just being large because it contains the "standard library" ignores that many JS language features necessarily use native objects like symbols or promises, which can't be entirely implemented in just JavaScript alone, so they are intrinsic rather than being standard library components, akin to Go builtins rather than the standard library. In fact, in actual environments, the browser and/or Node.JS provide the actual standard library, including things like fetch, sockets, compression codecs, etc. Even ignoring almost all of those bits though, the spec is absolutely enormous, because JavaScript has:

- Regular expressions - not just in the "standard library" but in the syntax.

- An entire module system with granular imports and exports

- Three different ways to declare variables, two of which create temporal dead zones

- Classes with inheritance, including private properties

- Dynamic properties (getters and setters)

- Exception handling

- Two different types of closures/first class functions, with different binding rules

- Async/await

- Variable length "bigint" integers

- Template strings

- Tagged template literals

- Sparse arrays

- for in/for of/iterators

- for await/async iterators

- The with statement

- Runtime reflection

- Labeled statements

- A lot of operators, including bitwise operators and two sets of equality operators with different semantics

- Runtime code evaluation with eval/Function constructor

And honestly it's only scratching the surface, especially of modern ECMAScript.

A language spec is necessarily long. The JS language spec, though, is so catastrophically long that it is a bit hard to load on a low end machine or a mobile web browser. It's on another planet.

Re: Go's Sweet 16

#195

Post by kgwxd »

zer00eyz wrote: post #156
bccdee wrote: post #123

Earlier quoted context omitted.

Nail guns are great because they're instant and consistent. You point, you shoot, and you've unimpeachably bonded two bits of wood. For non-trivial tasks, AI is neither of those. Anything you do with AI needs to be carefully reviewed to correct hallucinations and incorporate it into your mental model of the codebase. You point, you shoot, and that's just the first 10-20% of the effort you need to move past this piece…

> Nail guns are great because they're instant and consistent. You point, you shoot, and you've unimpeachably bonded two bits of wood. You missed it. If I give a random person off the street a nail gun, circular saw and a stack of wood are they going to do a better job building something than a carpenter with a hammer and hand saw? > Anything you do with AI needs to be carefully reviewed Yes, and so does a JR engineer…

You are responsible for the AI code you check in. It's your reputation on the line. If people felt the need to assume that much responsibility for all code they review, they'd insist on writing it themselves instead.

Re: Go's Sweet 16

#196

Post by duskwuff »

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.

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

Re: Go's Sweet 16

#197

Post by duskwuff »

mikewarot wrote: post #192

And here I was anticipating a release of Go for the Apple ][ computer[16] [16] https://en.wikipedia.org/wiki/SWEET16

It might be possible. TinyGo exists, and can target some devices with even less memory than the Apple II, like the ATmega328 microcontroller.

Re: Go's Sweet 16

#198

Post by piekvorst »

jiehong wrote: post #193
culebron21 wrote: post #87

To me, Go is like Rust oversimplified beyond reason. It edits your code when you don't ask, removing things you just started; it lacks iterators -- every time you must write a big cycle instead. It lacks simple things like check if a key exists in a map. Proponents say it has nothing under the hood. I see under-the-hood-magic happen every time. 1) The arrays append is one example. Try removing an element from an arra…

One thing Go took from C that I dislike: overly short variable names (like in interface names when implementing function are usually 1 or 2 letters, but also chan!). Other random things I hate: - first element in a struct, if unnamed, acts like extending a struct; - private/public fields of method based on capitalisation (it makes json mapping to a struct have so much boilerplate); - default json lib being so inept w…

[dead]

Re: Go's Sweet 16

#199

Post by duskwuff »

MagicMoonlight wrote: post #64
ModernMech wrote: post #51

Oh wow, so it's already been 16 years since Google steamrolled the Go! language, which had existed a decade before Go and had every right to the name. This was when they were still pretending "do no evil" was their brand. There may be no honor amongst thieves but there is honor amongst langdevs, and when they did Go! dirty, Google made clear which one they are. Status changed to Unfortunate https://github.com/golang/…

Does anyone use that other language? No!

Go! wasn't even published as its own project [1] until 2015, well after Go(lang) was available. It previously existed as an unpublished CVS repository in an obscure Sourceforge project [2]; I can't fault the Go developers for ignoring or overlooking it. You can find a circa-2002 version of Go! in the archived CVS repository of the Sourceforge project, but none of the project's release files appear to contain it.

(Ignore the "Last Update: 2013-09-06" on the project page - that's the date that SourceForge performed an automatic migration. Any real activity on the project seems to have petered out around 2002, with one final file released in 2003.)

[1]: https://github.com/fgmccabe/go

[2]: https://sourceforge.net/projects/networkagent/

Re: Go's Sweet 16

#200

Post by gf000 »

kermatt wrote: post #36
roncesvalles wrote: post #23

Earlier quoted context omitted.

The nice thing about Go is that you can learn "all of it" in a reasonable amount of time: gotchas, concurrency stuff, everything. There is something very comforting about knowing the entire spec of a language. I'm convinced no more than a handful of humans understand all of C# or C++, and inevitably you'll come across some obscure thing and have to context switch out of reading code to learn whatever the fuck a "part…

> I'm convinced no more than a handful of humans understand all of C# or C++ How would the proportion of humans that understand all of Rust compare?

Rust managed to learn a lot from C++ and other languages' mistakes.

So while it has quite a bit of essential complexity (inherent in the design space it operates: zero overhead low-level language with memory safety), I believe it fares overall better.

Like no matter the design, a language wouldn't need 10 different kinds of initializer syntaxes, yet C++ has at least that many.

Post reply on HN