4 ms·

Sounds like Buffalo is omakase?

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.
ascotan 10y ago
Go is omakase. "But there's a fine line between a friendly suggestion and a belligerent diner. That line is usually exposed when the suggestion is declined: "I'm sorry, but hotdogs don't really fit our sushi menu, and while you may not care for unagi, we picked it for a reason. But thanks for the suggestions!". If only most arguments about the menu would stop there. But they don't, do they? They usually carry on and on. BUT I REALLY DON'T LIKE UNAGI!!! IT'S OFFENDING MY TASTE BUDS THAT IT'S PART OF THE DEFAULT COURSE SETTING. TAKE IT OOOOOOFFFFF!! Okay, buddy, sit down and have a sake." http://david.heinemeierhansson.com/2012/rails-is-omakase.html http://david.heinemeierhansson.com/2012/rails-is-omakase.htm... Don't get me wrong, I love the language, however, I think about this everytime I read about language proposals being nuked (cough generics).
kevinmannix 10y ago
Explanation on "omakase"? I haven't heard that term before and Google only provides sushi restaurants nearby...
- charlieegan3 10y ago
  Was a reference to this post: http://david.heinemeierhansson.com/2012/rails-is-omakase.html http://david.heinemeierhansson.com/2012/rails-is-omakase.htm... where Rails is described as a curated set of defaults/components/tools/options.

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.

ascotan 10y ago

Go is omakase. "But there's a fine line between a friendly suggestion and a belligerent diner. That line is usually exposed when the suggestion is declined: "I'm sorry, but hotdogs don't really fit our sushi menu, and while you may not care for unagi, we picked it for a reason. But thanks for the suggestions!". If only most arguments about the menu would stop there. But they don't, do they? They usually carry on and on. BUT I REALLY DON'T LIKE UNAGI!!! IT'S OFFENDING MY TASTE BUDS THAT IT'S PART OF THE DEFAULT COURSE SETTING. TAKE IT OOOOOOFFFFF!! Okay, buddy, sit down and have a sake." http://david.heinemeierhansson.com/2012/rails-is-omakase.html http://david.heinemeierhansson.com/2012/rails-is-omakase.htm... Don't get me wrong, I love the language, however, I think about this everytime I read about language proposals being nuked (cough generics).

kevinmannix 10y ago

Explanation on "omakase"? I haven't heard that term before and Google only provides sushi restaurants nearby...

charlieegan3 10y ago
Was a reference to this post: http://david.heinemeierhansson.com/2012/rails-is-omakase.html http://david.heinemeierhansson.com/2012/rails-is-omakase.htm... where Rails is described as a curated set of defaults/components/tools/options.