31–40 of 111 posts
Earlier quoted context omitted.
Static linking predates dynamic linking by several decades, hardly unique.
Wait, what prior programming language is compiled, can be statically linked, and has an https implementation in it's standard library?
What I like, It is a nice language had it been released in the mid-90's, following the footsteps of Oberon and Limbo. What I dislike, Being designed a decade later ignoring everything that happened in mainstream computing since Oberon and Limbo came to be, then adopting features that weren't properly backed in from the get go.
For one, I think it's mind blowing that they didn't have a good system for dependency management in place from the get-go. Things are pretty good now with go modules but it's like they never even heard of languages like Python and the unholy mess that package management was (and still is to some extent) with Python.
- Compiles to a static binary that's relatively small compared to something like .NET AOT.
- Structural typing.
- No semicolons.
Dislike:
- Lack of exceptions. I can understand wanting to avoid exceptions for safety critical software like avionics, but for most application programming, requiring manual error handling for every function call is cumbersome and unnecessary.
- Too verbose / lacking features. For example, there's not a short syntax for lambda expressions, like the => operator in C# or JavaScript.
- Public / private access modifiers at the package level rather than the class level (there are no classes).
- Language development is driven primarily by Google, who has a history of killing products.
1. Static linking. I'm astonished by how many languages expect the end user to install dependencies/runtime themselves, and something about it feels very impure . 2. The "go" keyword (and the whole goroutine system underneath it). Threads are clunky, somewhat unportable and generally unscalable. Goroutines just feel right. 3. Ability to use multiple major versions of a library. Diamond dependencies are an unsolved pr…
'implements X', is a clear statement that yes, this method is made just for that specific interface.
But this is just academic. I've never actually hit a situation yet where something just happens to implement an interface by chance, and does something completely unexpected.
Dislike: Error handling feels extremely verbose. I like the design choice to return errors explicitly, but it feels like there needs to be a return-if-error syntactic sugar introduced to avoid the endless if err != nil ... return err peppered everywhere.
-The go AST package was a pleasure to use
Dislike:
- Boilerplate error handling
- Excessive verbosity
- Multiple return not being of a type
- Duck Typed interfaces and the empty interface
- Go generate that makes verbosity worse
- Case-sensitive namespacing that leads to hunts for all the
instances
- Namespacing in modules that leads very large files
- Shadowing rules that let you shoot yourself in the
- Rules around =, := and var
- Slice tricks and for loops try to encompass iteration instead of something like list comprehensions
- Nullability and default values
- Short variable names to the point of being meaningless even in the standard library
- The go community's seeming insistence on a singular or idiomatic way to do things
- The standard library is missing basics
Edit: Added some formatting.
I wish channels and goroutines were more strict, so that you could have some basic assurance no race conditions can be present.
Defer is very convenient, which is a problem, as it is a source of bugs. It's usually used to ensure file-like objects get closed, but generally those return important errors when closed. A simple "defer file.Close()" will silently ignore the errors generated.
- Big standard lib, including SQL base classes, allowing very consistent DB code. No 6 different ORMs and slightly different DB code for every DB type. Ahem Rust.
- Cross-compiling is easy and consistent
Dislikes:
- Error handling. Done to death, but it direly needs some syntax sugar like Rust's `?` operator. Seems like 3/4 of any function that does anything significant is `if err` branches.
- Nullabilty and the way references work feels like a footgun. Rust feels more clear about what's happening when. Not sure there's much to be done about it now though.
What I don't like is that Rust is also very intriguing to me :D
- Concurrency. Can shoot yourself in the foot still, but it's overall pretty simple to get started and use.
- Small language surface. Fairly easy to keep most or all of it in your head.
- Good ecosystem, and easy to pull in libraries.
- Good standard library that does a lot out of the box.
- Easy for new people to get started with it.
- Compiles to a single static binary.
Dislike:
- Cluttering of my code with boilerplate error returns (a common criticism!).
- Can't stop consumers of a library from doing the wrong thing. E.g., ensuring that someone always initialises an internal map of a new struct instances is challenging, with tradeoffs for each option.
- In line with previous, overall lacking the language tools to enforce correct usage or behaviour.
- Lots of footguns.