Earlier quoted context omitted.
There's also always a package to handle that issue. [0][1][2] As well as other options. [3] I like to imagine that the "no generics, no way" crowd would never use the stairway in their building if the elevator broke down. [0] https://github.com/clipperhouse/gen [1] https://github.com/cheekybits/genny [2] https://github.com/cosmos72/gomacro [3] https://appliedgo.net/generics/
Ah, but the generics building was conceived with an elevator to start with, and it will eventually be repaired. Go's building architects decided an elevator was superfluous, as everyone should walk 20 stores high every single day, it is good for their health.
Go 2018 Survey Results
71–80 of 91 posts
Re: Go 2018 Survey Results
#72Earlier quoted context omitted.
Same here... .net core is around but the APIs and runtimes MS created aren't really loved by anyone. With WPF seemingly abandoned and UWP being ... itself, there isn't much enthusiasm left. A little sad, since I believe C# to be superior to JAVA, but I haven't used it for anything for about two years now. It maybe won't go away, but I think it lost a lot of relevance.
WPF is one of the corner stones of .NET Core 3.0, and one of the UI frameworks mostly used in life sciences device management UIs. UWP isn't going anywhere, as much as haters would like to.
I used WPF in medical applications like you said, but that was around 4-5 years ago.
Currently I believe UWP will never significantly take off on the desktop outside of Microsoft.
Re: Go 2018 Survey Results
#73Earlier quoted context omitted.
>Go also favors libraries over frameworks and is super thoughtful about using too many untested dependancies which means we don’t get stuck in frameworks that become legacy (rails) The Go standard library doesn't come close to replicating the functionality of Rails, let alone the gem ecosystem of Ruby/Rails. If you don't need it, great! Otherwise, you're spending time re-implementing what already exists and probably…
> The Go standard library doesn't come close to replicating the functionality of Rails Why would it? It's the standard library. Go has a massive ecosystem of third parties libraries, and unlike Ruby, which was a one trick pony, Go has libraries for pretty much anything you could want to do. It's exceedingly versatile and it has better integration into modern infra. Why? Because it's all written in Go. Prometheus, Kub…
>we don’t get stuck in frameworks that become legacy (rails)
And now advocate
>Go has a massive ecosystem of third parties libraries
What is so special about these libraries that prevent them from becoming legacy?
Re: Go 2018 Survey Results
#74Earlier quoted context omitted.
> The Go standard library doesn't come close to replicating the functionality of Rails Why would it? It's the standard library. Go has a massive ecosystem of third parties libraries, and unlike Ruby, which was a one trick pony, Go has libraries for pretty much anything you could want to do. It's exceedingly versatile and it has better integration into modern infra. Why? Because it's all written in Go. Prometheus, Kub…
I really enjoy Go and reach for it first when starting a project. However, Ruby on Rails still has use cases that it's better suited for than Go. Other languages, too, have their uses. Please don't trash talk other languages just because you have a favorite. It's unprofessional.
If there are use cases where Rails is a better fit than Go, than by all means make your argument and I'll make my rebuttal. Maybe we will both learn something, or maybe someone who reads the discussion will learn something. Not every tool is useful, and not every useful tool will be useful tomorrow.
Re: Go 2018 Survey Results
#75Earlier quoted context omitted.
> The Go standard library doesn't come close to replicating the functionality of Rails Why would it? It's the standard library. Go has a massive ecosystem of third parties libraries, and unlike Ruby, which was a one trick pony, Go has libraries for pretty much anything you could want to do. It's exceedingly versatile and it has better integration into modern infra. Why? Because it's all written in Go. Prometheus, Kub…
You said: >we don’t get stuck in frameworks that become legacy (rails) And now advocate >Go has a massive ecosystem of third parties libraries What is so special about these libraries that prevent them from becoming legacy?
Libraries are just collections of functionality that you can mix or match. Good libraries are framework or paradigm agnostic and are very unmagical in their interface.
Libraries are replaceable, frameworks are usually not. In Go, if you use an interface to abstract the library calls you need (which is trivially easy to do) you can easily replace any library in your code. But ditching Rails is a ground up rewrite of your entire application and chances are you have read entire books on Rails so switching is going to cost you a lot.
Re: Go 2018 Survey Results
#76Earlier quoted context omitted.
I really enjoy Go and reach for it first when starting a project. However, Ruby on Rails still has use cases that it's better suited for than Go. Other languages, too, have their uses. Please don't trash talk other languages just because you have a favorite. It's unprofessional.
Comparing technologies is a core part of the profession actually. What's worse is when people see a new tool or language and instantly dismiss it because it's not something they already know. A professional considers the technical capabilities in her tools and is willing to upgrade with the times. If there are use cases where Rails is a better fit than Go, than by all means make your argument and I'll make my rebutta…
Hypothetical situation: a company has a large and complex Ruby on Rails application that is its primary revenue stream. All of its employees are well-versed in RoR. The operations team consistently reports performance to be within acceptable ranges, and customers are happy with the product.
This scenario is common. Just replace "Ruby on Rails" with any other language/framework.
Staying with the existing ecosystem is the ideal choice for the business, rather than rewriting everything in Go.
Re: Go 2018 Survey Results
#77Earlier quoted context omitted.
Depends where you work, but if it's related to Kubernetes, service mesh ect ... Go is pretty popular nowdays.
Not everyone is on the K8s, Docker hype. They are today's NoSQL.
I'm guessing your job relies on people sticking with Java SQL stacks.
Re: Go 2018 Survey Results
#78Earlier quoted context omitted.
Comparing technologies is a core part of the profession actually. What's worse is when people see a new tool or language and instantly dismiss it because it's not something they already know. A professional considers the technical capabilities in her tools and is willing to upgrade with the times. If there are use cases where Rails is a better fit than Go, than by all means make your argument and I'll make my rebutta…
Alright, I'll bite. Hypothetical situation: a company has a large and complex Ruby on Rails application that is its primary revenue stream. All of its employees are well-versed in RoR. The operations team consistently reports performance to be within acceptable ranges, and customers are happy with the product. This scenario is common. Just replace "Ruby on Rails" with any other language/framework. Staying with the ex…
So they task one or two engineers to learn Go. They learn Go in one or two days, and rewrite some scripts in Go. Big success, the scripts are much faster and are statically typed. Then they decide that for a new piece of functionality they'll write it as a service. Since Ruby and Go are both officially support grpc languages, it's easy to connect them using a protobuf schema, and have the RoR app call out to Go.
Slowly over time, more new features are written as small Go services, until eventually everything in the RoR app is legacy, or can be replaced by any API gateway.
Now if the company needs to switch again, they can just rewrite individual services in a different language.
Re: Go 2018 Survey Results
#79Earlier quoted context omitted.
Ah, but the generics building was conceived with an elevator to start with, and it will eventually be repaired. Go's building architects decided an elevator was superfluous, as everyone should walk 20 stores high every single day, it is good for their health.
More like Go’s building comes building-agnostic, whether you have 20 stories or not. Anything you need (such as a generic elevator) can be added on. No need to walk 20 stories every day because you can just add what you need in through reusable packages.
Re: Go 2018 Survey Results
#80Earlier quoted context omitted.
Alright, I'll bite. Hypothetical situation: a company has a large and complex Ruby on Rails application that is its primary revenue stream. All of its employees are well-versed in RoR. The operations team consistently reports performance to be within acceptable ranges, and customers are happy with the product. This scenario is common. Just replace "Ruby on Rails" with any other language/framework. Staying with the ex…
Rewrites are almost never the right call, I agree. The company knows this, but they also see how RoR has locked them in and that the web ecosystem has changed in a lot of ways that makes the RoR proposition not so great. So they task one or two engineers to learn Go. They learn Go in one or two days, and rewrite some scripts in Go. Big success, the scripts are much faster and are statically typed. Then they decide th…
To put it another way - if my 2007 Honda Accord gets me to work reliably, why should I bother to buy a 2020 Tesla Model S?