3 ms·

Nothing can be omakase in Go. The language disallow it, unless you completely opt out of its type system. But then, what's the point of using a statically typed

by camus2 10y ago

Nothing can be omakase in Go. The language disallow it, unless you completely opt out of its type system. But then, what's the point of using a statically typed language? Go is built in a way that forbids writing abstractions. When I say forbid it really does forbid it. Even C is more expressive. Buffalo isn't a framework, unless a router + few bells and whistles is now considered "framework".

grey-area 10y ago
Go is built in a way that forbids writing abstractions. There are lots of abstractions in Go - e.g. structs, interfaces, goroutines, channels. It may not have all the abstractions you're used to (e.g. inheritance, generics), and might still be lacking in areas, but your statement is extreme hyperbole and not useful. As to whether something is a framework or not, why is this important to you?
- sethammons 10y ago
  Not op, but a framework vs toolkit is important to me. I like the gorilla toolkit because I can easily take parts or leave them or create them. I've not investigated buffalo, but the term framework instantly gives me a bad taste in my mouth. When I think of a framework, I think "our way or they highway" and the very moment you need to do something a bit different than what the framework expects or assumes, you are in for a world of hurt.
- camus2 10y ago
  > There are lots of abstractions in Go These are not abstraction a Go developer is writing himself. You are talking about language features. Indeed, the languages cheats and does things the users is not allowed to do, like append or delete functions.
  - grey-area 10y ago
    Well structs, interfaces do allow the user to create abstractions, in quite a nice way I think - it's very bare-bones compared to say inheritance in C++, and deliberately so. the languages cheats and does things the users is not allowed to do, like append or delete functions. I agree and find this slightly distasteful too, but I think it was borne of pragmatism. There is definitely also a cost to language purity and parsimony, and I'm glad they're a little pragmatic, but collections are the only area I've felt the language is seriously lacking in elegance (maybe option types would be nice too). Personally I find it quite pleasant to create abstractions in, those grips notwithstanding.

by camus2 10y ago

grey-area 10y ago

Go is built in a way that forbids writing abstractions. There are lots of abstractions in Go - e.g. structs, interfaces, goroutines, channels. It may not have all the abstractions you're used to (e.g. inheritance, generics), and might still be lacking in areas, but your statement is extreme hyperbole and not useful. As to whether something is a framework or not, why is this important to you?

sethammons 10y ago
Not op, but a framework vs toolkit is important to me. I like the gorilla toolkit because I can easily take parts or leave them or create them. I've not investigated buffalo, but the term framework instantly gives me a bad taste in my mouth. When I think of a framework, I think "our way or they highway" and the very moment you need to do something a bit different than what the framework expects or assumes, you are in for a world of hurt.
camus2 10y ago
> There are lots of abstractions in Go These are not abstraction a Go developer is writing himself. You are talking about language features. Indeed, the languages cheats and does things the users is not allowed to do, like append or delete functions.
- grey-area 10y ago
  Well structs, interfaces do allow the user to create abstractions, in quite a nice way I think - it's very bare-bones compared to say inheritance in C++, and deliberately so. the languages cheats and does things the users is not allowed to do, like append or delete functions. I agree and find this slightly distasteful too, but I think it was borne of pragmatism. There is definitely also a cost to language purity and parsimony, and I'm glad they're a little pragmatic, but collections are the only area I've felt the language is seriously lacking in elegance (maybe option types would be nice too). Personally I find it quite pleasant to create abstractions in, those grips notwithstanding.