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

101–110 of 280 posts

Re: Go's Sweet 16

#101

Post by pekim »

culebron21 wrote: post #93
9rx wrote: post #92

Earlier quoted context omitted.

> proper enums It has proper enums. Granted, it lacks an enum keyword, which seems to trip up many. Perhaps what you are actually looking for is sum types? Given that you mentioned Rust, which weirdly[1] uses the enum keyword for sum types, this seems likely. Go does indeed lack that. Sum types are not enums, though. > sensible arrays & slices, without any magic and awkward syntax Its arrays and slices are exactly th…

> It has proper enums. Well, then they look awkward and have give a feel like it's a syntax abuse. > Its arrays and slices are exactly the same as how you would do it in C. So while it is true that trips up many coming from languages that wrap them in incredible amounts of magic, but the issue you point to here is actually a lack of magic. In Rust, I see exactly what I work with -- a proper vector, material thing, or…

Inserting elements in to a slice can be done quite easily since the introduction of the slices package to the standard library.

https://pkg.go.dev/slices#Insert

Re: Go's Sweet 16

#102

Post by throw-the-towel »

Xeoncross wrote: post #3

I know they say that your programming language isn't the bottleneck, but I remember sitting there being frustrated as a young dev that I couldn't parse faster in the languages I was using when I learned about Go. It took a few more years before I actually got around to learning it and I have to say I've never picked up a language so quickly. (Which makes sense, it's got the smallest language spec of any of them) I'm…

Unfortunately, it's the remaining 20% of Rust features that provide 80% of its usefulness.

Re: Go's Sweet 16

#103

Post by wanderlust123 »

robryan wrote: post #60
wanderlust123 wrote: post #48

Earlier quoted context omitted.

I think lack of classes is highly desirable. So much enterprise code is poorly put together abstractions. I think go needs some more functional aspects, like iterators and result type/pattern matching.

Go does have iterators: https://pkg.go.dev/iter

Thanks! Did not see this until your message, looking forward to make use of this

Re: Go's Sweet 16

#104

Post by dontlaugh »

Xeoncross wrote: post #28
echelon wrote: post #26

Earlier quoted context omitted.

Rust is the most defect free language I have ever had the pleasure of working with. It's a language where you can almost be certain that if it compiles and if you wrote tests, you'll have no runtime bugs. I can only think of two production bugs I've written in Rust this year. Minor bugs. And I write a lot of Rust. The language has very intentional design around error handling: Result , Option , match, if let, functio…

I agree with a lot of what you said. I'm hoping Rust will warm on me as I improve in it. I hate nil/null. > Go... extremely exhausting boilerplate error checking This actually isn't correct. That's because Go is the only language that makes you think about errors at every step. If you just ignored them and passed them up like exceptions or maybe you're basically just exchanging handling errors for assuming the whole…

It’s very common in Go to just pass the error on since there’s no way to handle it in that layer.

Rust forces you to think about errors exactly as much, but in the common case of passing it on it’s more ergonomic.

Re: Go's Sweet 16

#105

Post by Mawr »

the_gipsy wrote: post #84
throw1111221 wrote: post #50

Earlier quoted context omitted.

Well that's good, since Go was specifically designed for juniors. From Rob Pike himself: "It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical." However, the main design goal was to reduc…

> This is why unused dependencies are a compile time error. https://go.dev/doc/faq?utm_source=chatgpt.com#unused_variabl... > There are two reasons for having no warnings. First, if it’s worth complaining about, it’s worth fixing in the code. (Conversely, if it’s not worth fixing, it’s not worth mentioning.) Second, having the compiler generate warnings encourages the implementation to warn about weak cases that can…

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 clean up before releasing. It would also take the pressure off having release builds compile fast, allowing for more optimisation passes.

Re: Go's Sweet 16

#106

Post by the_gipsy »

Mawr wrote: post #105
the_gipsy wrote: post #84

Earlier quoted context omitted.

> This is why unused dependencies are a compile time error. https://go.dev/doc/faq?utm_source=chatgpt.com#unused_variabl... > There are two reasons for having no warnings. First, if it’s worth complaining about, it’s worth fixing in the code. (Conversely, if it’s not worth fixing, it’s not worth mentioning.) Second, having the compiler generate warnings encourages the implementation to warn about weak cases that can…

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…

That doesn't make any sense, you'd still need to run the linters on release. Why bail out on "unused var" and not on actually harmful stuff.

Re: Go's Sweet 16

#107

Post by Mawr »

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…

> it lacks iterators -- every time you must write a big cycle instead

It has iterators - https://pkg.go.dev/iter.

> It lacks simple things like check if a key exists in a map.

What? `value, keyExists := myMap[someKey]`

> Try removing an element from an array - you must rely on some magic and awkward syntax, and there's no clear explanation what actually happens under the hood (all docs just show you that a slice is a pointer to a piece of vector).

First of all, if you're removing elements from the middle of an array, you're using the wrong data structure 99% of the time. If you're doing that in a loop, you're hitting degenerate performance.

Second, https://pkg.go.dev/slices#Delete

Re: Go's Sweet 16

#108

Post by gr4vityWall »

echelon wrote: post #26
Xeoncross wrote: post #15

Earlier quoted context omitted.

Yes, for me I've always pushed the limits of what kinds of memory and cpu usage I can get out of languages. NLP, text conversion, video encoding, image rendering, etc... Rust beats Go in performance.. but nothing like how far behind Java, C#, or scripting languages (python, ruby, typescript, etc..) are from all the work I've done with them. I get most of the performance of Rust with very little effort a fully contain…

Rust is the most defect free language I have ever had the pleasure of working with. It's a language where you can almost be certain that if it compiles and if you wrote tests, you'll have no runtime bugs. I can only think of two production bugs I've written in Rust this year. Minor bugs. And I write a lot of Rust. The language has very intentional design around error handling: Result , Option , match, if let, functio…

Borgo could be that language for you. It compiles down to Go, and uses constructs like Option instead of nil, Result instead of multiple return values, etc. https://github.com/borgo-lang/borgo

Re: Go's Sweet 16

#109

Post by xigoi »

ajross wrote: post #34
morshu9001 wrote: post #24

Earlier quoted context omitted.

This is also what I like about JS, except it's even easier than Go. Meanwhile Python has a surprising number of random features.

The Javascript world hides its complexity outside the core language, though. JS itself isn't so weird (though as always see the "Wat?" video), but the incantations required to type and read the actual code are pretty wild. By the time you understand all of typescript, your templating environment of choice, and especially the increasingly arcane build complexity of the npm world, you've put in hours comparable to what…

…do you know you can just write JavaScript and run it in the browser? You don’t need TypeScript, NPM or build tools.

Re: Go's Sweet 16

#110

Post by culebron21 »

9rx wrote: post #98
culebron21 wrote: post #93

Earlier quoted context omitted.

> It has proper enums. Well, then they look awkward and have give a feel like it's a syntax abuse. > Its arrays and slices are exactly the same as how you would do it in C. So while it is true that trips up many coming from languages that wrap them in incredible amounts of magic, but the issue you point to here is actually a lack of magic. In Rust, I see exactly what I work with -- a proper vector, material thing, or…

> Well, then they look awkward and have give a feel like it's a syntax abuse. So nothing to worry about? > how do I insert an element in the middle of an array? Same as in C. If the array allocation is large enough, you can move the right hand side to the next memory location, and then replace the middle value. Something like: replaceWith := 3 replaceAt := 2 array := [5]int{1, 2, 4, 5} size := 4 for i := size; i > re…

Ok, so mostly we agree. And I was right that you can't just concatenate different slices (e.g. to remove one item from the middle), hence Go has to do a lot of work under the hood to do that. I count this as magic.
Post reply on HN