The question on its own is useless given the audience - yes. However if you combine that question with the - e.g. - primary field a person works in it gets interesting.
Say a person said they're mostly writing finance software and Go isn't a language they'd prefer to use for their next project.
Those two data points on their own also don't tell much - but if multiple people answer with that combination the Go team knows that they aren't covering the needs of the finance sector appropriately.
With that knowledge they can e.g. request more information from those people and start working to fix those issues.
> Go team knows that they aren't covering the needs of
This is true for anything where Go is underused or not used and the bias here still stands, since those people are very unlikely to be represented in the survey.
As a person who is mostly writing finance software I can tell that Go is not very well suited for any kind of rich application domain (which finance definitely is). OOP and Java + C# in particular have a very strong hold in finance. We can argue whether composition is an adequate substitute for inheritance, but the lack of generics is pretty much a non-starter.
Go works very well in domains with a well-defined and limited set of entities.
> What causes OOP to be well suited for finance's use case?
What are the short-comings of structs/interface methods that Go! provides in the financial space?
“Things” in finance are amenable to the classical PIE of OOP. Many concepts, e.g. financial instruments are extended version of something that was invented earlier. E.g. you have an abstract concept of an interest rate swap and specific versions of it (like fixed-fixed, foxes floating, cross-currency etc). This works pretty well with inheritance and polymorphism.
When you talk about money, finance is very particular about what you can do and what you cannot do. E.g. if money are subtracted from one account, they should appear in another, or balance cannot go negative. It is easier to enforce rules like that on a language level with encapsulation.
> If Go! had generics, would that change it's suitability for finance?
I believe so. You have built in “generics” for most popular collections like maps and arrays, which is fine for command like utilities and lots of system-level software. But in finance (an other problem domains tbh) you often need a generic version of a more complicated data structure, e.g. dataframe, tree, implementation of flyweight pattern, or data cube.
> I would think that first-class concurrency would be useful in that space, is it?
Good support of first class concurrency is useful everywhere. Just so it happened that given that C++, Java, and C# together reign in different domains of finance, we are already quite comfortable with concurrency primitives of these languages (usually some kind of multithreading)
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.
Maybe language communities are formed from people that need or don't-need those kind of affordances. e.g. Imagine the office environment you'd have if all your cohort were people that walked 20 flights without making it an issue.
The point is to very roughly quantify that selection bias, no? Obviously, if Go neglects certain areas or doesn't fit well enough, people who consider those areas important don't use Go and are not represented in the survey.
Asking what languages people use at work or when not at work is an obvious place to start this sort of survey, it should be no surprise that Go is ranked highly among people who found it on the Go website, and it didn't surprise the authors of the survey either who pointed it out and quickly moved on to more meaningful statistics.
I'm a big fan of both Go and Rust, and it's really interesting to see Rust ranked #3 in preference but #17 in expertise.
Rust is not a simple language by any means -- it's a great replacement for C++, but I'd be pretty surprised if it displaced the popular general purpose languages (which Go has actually managed to do.)
I agree with you, but I still think you're going to see Go, Rust and friends eating away at that code base.
FYI I'm language agnostic, but I'd like to see c++ eventually replaced. .NET is currently looking good, and I'm ambivalent on Java, but I think there are valid reasons to be looking at go right now,if not rust. They both seem to be tuned to modern hardware design despite the hype.
That's largely because it's the easiest way to deal with Custom Resource Definitions within Kubernetes, and because many of the tools that make writing a Controller or Operator easy are only exposed as internal APIs.
It's also because a k8s daemonset or sidecar takes 5 to 10x less memory to run using Go. No one wants to run small pods with JVM and xms / xmx settings to 512MB.
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.
Maybe not. But users might go somewhere else. I have yet to meet anyone in real life that developed anything with UWP because it allegedly (has been a while) still lacks very basic features relating to UI at least (i know it is not restricted to that). I have nothing against WPF, although I am not a fan of XAML. But I think MS isn't really focusing on it. We will see.
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.
> There is an old study about 4.5 million .NET developers in 2004. Today, if I have to guess, there are at least 7-8 million .NET developers in the world.
> VS Code and GoLand are surging in popularity and are now the most popular code editors among survey respondents.
I wish the package situation for Go was better for SublimeText. Currently most of the worthwhile golang packages that add vet, goimports, fmt, etc support are either abandoned or buggy. Margo bailed on using Package Control so it's difficult to install, not to mention buggy.
I've used VSCode for a while but it chokes sometimes and you can't beat the speed, ease, and power of SublimeText.
At the end of last year, a great systematic rewrite of Sublime's Go grammar was merged. So at that (admittedly surface-) level, it's doing very well.
I just maintain my own on-save hooks, build systems and plugins to integrate various quality-of-life Go tools. With the benefit of being able to tailor any such functionality to exactly the way you like to work and nothing more, it's far less effort than it would be to create the all-singing-all-dancing comprehensive package that is absent.
I'd be particularly interested in seeing a low-expertise / high-expertise comparison on satisfaction / desired improvements. It takes a while to learn (in every language) what's going to bite you and how to deal with it / how well it works.
Working with go was...fun! Simple as that. I really feel like the authors of the language found a very good mix of expressiveness, speed and ease of use.
Go and Rust are actually a great combo with only a little overlap. What’s great is that they are both C family and have some shared principles and flow.
When you need a decent concurrency story, moderate speed, and have a problem that is concrete, choose Go. It’s a good candidate for replacing Python, Ruby, JavaScript, and smaller Java projects.
Rust is better if you need maximum performance, are building a large project where more abstraction where parametric polymorphism can help, or need thread safety. It’s a replacement for larger Java projects, C++, and C.
Generally I write more Go projects, but my Rust projects tend to be bigger and are doing very complex things like user space networking or wringing maximum performance out of a kernel subsystem or running in a very low resource environment.
Both languages have made my teams enjoy their work more. We also have empirically measured a decrease in time spent fixing bugs and other production issues, as well as reduced resource consumption (mostly from getting rid of Python for Go) and snappier cli tools that are saving us $$$$$$ in terms of time and hardware). Both languages are built for modern problems and getting stuff done.
Also Go and Rust position us to hit Wasm hard. I can’t understate how important Wasm support is and how both of these languages are already miles ahead of the competition. This is containers right before Docker. Your company should be pivoting or have a strategy to get on deck with these languages.
> Your company should be pivoting or have a strategy to get on deck with these languages.
That’s a bold blanket statement. Besides the fact that I would die inside a little if I had to use Go every day of my life, Go is in no position to replace any of the aforementioned languages (Python, Js, Ruby, C++), let alone all of them, not by a mile.
I don't think your parent meant that a language broadly replaces another but rather that Go and Rust lend themselves well for some types of projects typically done in other languages.
Not C++, but definitely the other languages outside of some non standard SWE domains like ML, where Python is going to be an obvious winner. Otherwise Go beats them by having a type system but still supporting duck typing through interfaces, having a modern concurrency story, being easier to learn (the Go spec can be read in one evening), having less features to abuse, faster development loops with lightning fast compile times and catching more errors at compile time, and just generally being faster and having a garbage collector that is tuned for low latency (a good fit for web services). We can also start faster which is really important for container workloads, idle with less memory which is important for horizontal scaling, and use less CPU which means smaller machines and more colo.
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) or use stuff that has security holes or that will change out from under us (npm).
>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 doing a worse job of it.
> 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, Kubernetes, etcd, terraform, docker, caddy, fleet, influxDB, synthing, coachroachDB, gogs, mino... all written in Go. Go is cloud first, and has first class support for multicloud abstractions written by the go team. It's got great support for rpc through grpc and protocol buffers both of which are much easier to use in a statically compiled C like language that resembled the protocol buffers primitives.
Rails literally offers nothing you can't get from Go, and it doesn't make you pay for the stuff you aren't using. With Go you don't write in a DSL based on the language, you just write regular Go code. You aren't a rails developer, you're a Go developer.
Err, both Python and Ruby have a much bigger ecosystem than Go. Not only that but you're speaking as if Python or Ruby were usually used in the context of building infrastructure-level services (k8s, dbs, consul, docker, etc.) instead of business logic / applications kind of services ( gitlab, shopify, your usual startup CRUD).
Why would you even compare both? You wouldn't want to create gitlab V1 with Go just like you wouldn't want to write Kubernetes in Ruby.
> Go has libraries for pretty much anything you could want to do.
Except for CRMs, GUI, DB drivers with the same feature level as JDBC or ADO.NET, Office/PDF docs (full spec not hello world stuff), GPGU, 3D game engines (Unreal/Unity/CryEngine,...), ...
Go has libraries, more than you can count, for CRMs, PDF, GUIs (and TUIs), and DBs (including standard library support for SQL).
I actually try to use as few libraries as possible. Unlike the C# and Java developers I actually know how to code and can whip up something to do exactly what I need in the same time it takes you to read your Javadocs.
Aren't there more third party libraries for java than for go?
Then that is no reason to go from java.
Performance wise they seem to be pretty similar too. Of course not for startup time in serverless environments but for most server applications.
It sounds like we are down to productivity (and developer happiness) which are a bit unclear and probably different for different teams and organizations. I would guess that large organizations will get into problems if they switch everything to go and then have to re-train all developers, or hire new ones.
For libraries, I have never once found Go lacking. I’ve noticed that because Go jumped to the front of the line quite recently you are more likely to find packages that are being actively maintained than Java.
That said there are always edge cases, and I have run into places where the only Java library I could get was proprietary, which is pretty usual for Java and pretty rare for Golang.
As you many already know the authors of Go are bell labs folks who practically invented hacking and showing up large enterprises (Multics), so there is a hacker mentality in the Go ecosystem that makes ditching libraries and writing a little bit more code attractive to Gophers. I highly encourage anyone learning Go to try to adopt this mindset, Russ Cox has a great blog post about the dangers of depdancies that are often easily dismissed by the Java and Javascriptors.
As for resource consumption Go and Java generally execute at the same speed but that’s where the comparison ends. Java has been trying to modernize in some ways but they have fundamental barriers over a statically compiled language, and in typical Java fashion there’s a lot of finger pointing at Jigsaw and Vert.X as answers to Java’s failings, but the truth is that the former has been in development for years and the latter is massively complicated for Java’s target audience. I believe they are also working on fibers, but again that’s far down the line.
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 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.
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.
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 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.
Businesses don't stand still, you're either actively working on a product, or you're building a new product and the old product is in maintenance mode. So to follow your analogy, a businesses is always trying to get itself into a new car. If electric cars are the future, they don't want to be in a gas powered Honda Accord while their competition is riding around in Teslas.
In larger companies, spending less on gas can also save you a lot of money. If I can write a Go app that doesn't require as much AWS compute, or have a type system that lets me spend less time on bugs and more time on features, that's hitting my bottom line.
Framework != library. A framework is defined by a DSL or all encompassing architecture that has an opinion on how you structure your app. Frameworks trade choice for supposed convenience.
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.
This doesn't accurately represent what Rails is today (or has been for quite a while). Most of its functionality comes from libraries that you can replace as you see fit. You can easily build your own "Rails" if you want by using libraries.
>Frameworks trade choice for supposed convenience.
It's not just convenience. By coalescing on one standard set of libraries it becomes much more likely that those individual libraries will be maintained.
>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.
What you describe in the first half is effectively recreating Rails. Expending that initial cost in order to avoid the possibility of expending it later doesn't make sense.
And you're not right about the cost of switching from Rails. You can use pretty much all the code you write without Rails. The effort will come in creating whatever it is you want to use to replace Rails.
It's a bit ridiculous to reduce Rust to the requirement of "performance" or parametric polymorphism.
Go doesn't have a proper, complete type system. This means entire classes of preventable bugs are not prevented by the compiler. Yeah, its fast, but you can pass in null instead of object references and the compiler won't even bat an eye. Not to mention the extremely verbose error handling and the lack of abstractions all around (no sum types, no iterators, no array filter/map, etc) despite being more "high-level" than Rust in layman terms.
This is nonsense. There's no definition or checklist that defines what a complete type system is. In that vein, Haskell doesn't have a proper type system because it lacks dependent types, and a bunch of other features that are only available through language extensions.
We are still not at a place yet where the from first principles, type driven approach is going to always be the right choice over the hack out code approach. Rust simply takes more investment to learn, and more time to master, and while I agree that investment pays off 1000x, and that Java and C++ should stop existing, Go is a better fit for the people who just want a productive, reasonably efficient language that can get stuff done. Having a very simple hammer like Go that limits what people can do and sticks to what people already know is useful and beneficial.
> This is nonsense. There's no definition or checklist that defines what a complete type system is
The Go programming language and the compiler have too many soundness holes, therefore I call the type system incomplete. When you can pass in a null literal in place of an object and the compiler doesn't stop you, it goes against any common sense. Not to mention the pervasive use of reflection (interface{}) due to lack of generics.
Allowing null pointers to exist in a new programming language is a decision to ignore decades of progress in pl theory and type system research. It makes sense for google knowing the motivation behind Go, but telling people to avoid Rust unless they need polymorphism or performance is disingenuous at best.
> We are still not at a place yet where the from first principles, type driven approach is going to always be the right choice over the hack out code approach.
Yes, I know Java for sure allows this. There are workarounds to enforce stricter behavior via things like @NonNull and checker frameworks, but it obviously never works as well as it would on a language level.
"By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed" - Fran Allen
There is a strong narrative around rust being suitable for “extracting/wringing/squeezing” the last drop of performance.
Why do people pushing those claims think a go program compiled down to native executable is slower then rust
Is it the rust compiler is better ? Is the go stdlib slower ? Is it the gc
The GC is going to add some overhead is it that bad for most uses except for real time critical large s/w
- The Rust compiler uses the LLVM backend, which is generally more aggressive about optimizations and code generation. The Go compiler is a custom compiler (I think plan 9 inherited) and as of fairly recently didn't do some optimizations that are fairly common otherwise (non-leaf inlining).
- Rust as a language heavily favors automatic (stack) allocation, and does not favor complex object graphs, so that will often help make algorithms more cache-friendly. In go, stack allocation is strictly an optimization. This is somewhat defeated by the common use of 'smart' pointer types.
- Due to using segmented stacks, the function prologue/epilogue is a bit more involved in go, than it is in a language like rust.
So with rust, it is - with some work - possible to have code that executes as the equivalent C code would. I guess in go you could too, but it'd be quite a bit harder, and go against the grain of the language.
Compared to the performance of a typical interpreted dynamic language, this is a fairly marginal difference however.
> If you want a working pain-free solution learn C++17 instead
A solution to what, exactly? I'll admit I haven't worked with C++ in awhile, but I'm skeptical of C++AnyYear being "pain-free". What do you like in C++17 that you feel is lacking in Rust?
This is a really bold statement that sounds like it’s coming from someone who is afraid that their knowledge of C++ is going to be obsoleted in a few years.
C++ 17 is still a mess. You still lack a proper package manager, type constraints, modules, sane lookup rules for function calls, thread safety, a proper monastic future type, I could go on.
Also most people won’t see C++ 17 or 14 for another decade. Even if the language decides to start bolting on more features the ecosystem is still very slow.
Those same people are less likely to throw their company jewels away and rewritte everything from scratch, specially if they are using UI toolkits, graphical debuggers, game engines or GPGPU.
That's an OS usability issue, not a language problem. Personally, Nix solved this for me.
> type constraints
C++ has type constraints, and ones that actually work. I suspect what you call 'type constraints' is something that can't exist if you understand the difference between 'run-time' and 'compile-time'.
> sane lookup rules for function calls
A very minor issue. If you don't like function overloads, then don't use them.
> thread safety, a proper monastic future type
Please no. The kind of 'thread safety' you want destroys the benefit of using threads in the first place. C++ threading is perfect as it is.
> Also most people won’t see C++ 17 or 14 for another decade.
Frankly, I don't care about these twisted people stuck in enterprise hell.
90 comments
[ 2.7 ms ] story [ 153 ms ] threadIt doesn't really say much given the selection bias.
Why can't you look for the value in the article instead of picking stupid holes in it?
Say a person said they're mostly writing finance software and Go isn't a language they'd prefer to use for their next project. Those two data points on their own also don't tell much - but if multiple people answer with that combination the Go team knows that they aren't covering the needs of the finance sector appropriately. With that knowledge they can e.g. request more information from those people and start working to fix those issues.
This is true for anything where Go is underused or not used and the bias here still stands, since those people are very unlikely to be represented in the survey.
Go works very well in domains with a well-defined and limited set of entities.
What causes OOP to be well suited for finance's use case?
What are the short-comings of structs/interface methods that Go! provides in the financial space?
If Go! had generics, would that change it's suitability for finance?
I would think that first-class concurrency would be useful in that space, is it?
“Things” in finance are amenable to the classical PIE of OOP. Many concepts, e.g. financial instruments are extended version of something that was invented earlier. E.g. you have an abstract concept of an interest rate swap and specific versions of it (like fixed-fixed, foxes floating, cross-currency etc). This works pretty well with inheritance and polymorphism.
When you talk about money, finance is very particular about what you can do and what you cannot do. E.g. if money are subtracted from one account, they should appear in another, or balance cannot go negative. It is easier to enforce rules like that on a language level with encapsulation.
> If Go! had generics, would that change it's suitability for finance?
I believe so. You have built in “generics” for most popular collections like maps and arrays, which is fine for command like utilities and lots of system-level software. But in finance (an other problem domains tbh) you often need a generic version of a more complicated data structure, e.g. dataframe, tree, implementation of flyweight pattern, or data cube.
> I would think that first-class concurrency would be useful in that space, is it?
Good support of first class concurrency is useful everywhere. Just so it happened that given that C++, Java, and C# together reign in different domains of finance, we are already quite comfortable with concurrency primitives of these languages (usually some kind of multithreading)
You can define an interface with methods that allow objects to be processed in a more generic fashion.
I think that more than anything it would require a change of mindset that people understandably don't want to deal with.
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/
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.
Java/net are just not fun and the mentality of the developers seems off-putting to a lot of new devs and those seeking to move fast and ship stable.
Rust is not a simple language by any means -- it's a great replacement for C++, but I'd be pretty surprised if it displaced the popular general purpose languages (which Go has actually managed to do.)
Still plain old Java, .NET and C++ as always.
FYI I'm language agnostic, but I'd like to see c++ eventually replaced. .NET is currently looking good, and I'm ambivalent on Java, but I think there are valid reasons to be looking at go right now,if not rust. They both seem to be tuned to modern hardware design despite the hype.
They are today's NoSQL.
I'm guessing your job relies on people sticking with Java SQL stacks.
Unity is increasing C# popularity, though. So maybe .NET is not going away, at least yet.
It maybe won't go away, but I think it lost a lot of relevance.
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.
https://www.c-sharpcorner.com/forums/how-many-c-sharp-develo... (2014)
Coming from Java, I find that I don't miss generics and exceptions as much anymore as I thought I would :)
I wish the package situation for Go was better for SublimeText. Currently most of the worthwhile golang packages that add vet, goimports, fmt, etc support are either abandoned or buggy. Margo bailed on using Package Control so it's difficult to install, not to mention buggy.
I've used VSCode for a while but it chokes sometimes and you can't beat the speed, ease, and power of SublimeText.
I just maintain my own on-save hooks, build systems and plugins to integrate various quality-of-life Go tools. With the benefit of being able to tailor any such functionality to exactly the way you like to work and nothing more, it's far less effort than it would be to create the all-singing-all-dancing comprehensive package that is absent.
When you need a decent concurrency story, moderate speed, and have a problem that is concrete, choose Go. It’s a good candidate for replacing Python, Ruby, JavaScript, and smaller Java projects.
Rust is better if you need maximum performance, are building a large project where more abstraction where parametric polymorphism can help, or need thread safety. It’s a replacement for larger Java projects, C++, and C.
Generally I write more Go projects, but my Rust projects tend to be bigger and are doing very complex things like user space networking or wringing maximum performance out of a kernel subsystem or running in a very low resource environment.
Both languages have made my teams enjoy their work more. We also have empirically measured a decrease in time spent fixing bugs and other production issues, as well as reduced resource consumption (mostly from getting rid of Python for Go) and snappier cli tools that are saving us $$$$$$ in terms of time and hardware). Both languages are built for modern problems and getting stuff done.
Also Go and Rust position us to hit Wasm hard. I can’t understate how important Wasm support is and how both of these languages are already miles ahead of the competition. This is containers right before Docker. Your company should be pivoting or have a strategy to get on deck with these languages.
That’s a bold blanket statement. Besides the fact that I would die inside a little if I had to use Go every day of my life, Go is in no position to replace any of the aforementioned languages (Python, Js, Ruby, C++), let alone all of them, not by a mile.
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) or use stuff that has security holes or that will change out from under us (npm).
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 doing a worse job of it.
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, Kubernetes, etcd, terraform, docker, caddy, fleet, influxDB, synthing, coachroachDB, gogs, mino... all written in Go. Go is cloud first, and has first class support for multicloud abstractions written by the go team. It's got great support for rpc through grpc and protocol buffers both of which are much easier to use in a statically compiled C like language that resembled the protocol buffers primitives.
Rails literally offers nothing you can't get from Go, and it doesn't make you pay for the stuff you aren't using. With Go you don't write in a DSL based on the language, you just write regular Go code. You aren't a rails developer, you're a Go developer.
Why would you even compare both? You wouldn't want to create gitlab V1 with Go just like you wouldn't want to write Kubernetes in Ruby.
Does Gitea[1] count (fork of Gogs)?
I understand your point (I love Python, too), but I can't help finding some amusement in it since it has been done. :)
[1] https://github.com/go-gitea/gitea
Except for CRMs, GUI, DB drivers with the same feature level as JDBC or ADO.NET, Office/PDF docs (full spec not hello world stuff), GPGU, 3D game engines (Unreal/Unity/CryEngine,...), ...
Modern infra is the NoSQL of 2019.
I actually try to use as few libraries as possible. Unlike the C# and Java developers I actually know how to code and can whip up something to do exactly what I need in the same time it takes you to read your Javadocs.
If everyone rewrites their own, nobody will ever help you with yours.
citation needed
Performance wise they seem to be pretty similar too. Of course not for startup time in serverless environments but for most server applications.
It sounds like we are down to productivity (and developer happiness) which are a bit unclear and probably different for different teams and organizations. I would guess that large organizations will get into problems if they switch everything to go and then have to re-train all developers, or hire new ones.
That said there are always edge cases, and I have run into places where the only Java library I could get was proprietary, which is pretty usual for Java and pretty rare for Golang.
As you many already know the authors of Go are bell labs folks who practically invented hacking and showing up large enterprises (Multics), so there is a hacker mentality in the Go ecosystem that makes ditching libraries and writing a little bit more code attractive to Gophers. I highly encourage anyone learning Go to try to adopt this mindset, Russ Cox has a great blog post about the dangers of depdancies that are often easily dismissed by the Java and Javascriptors.
As for resource consumption Go and Java generally execute at the same speed but that’s where the comparison ends. Java has been trying to modernize in some ways but they have fundamental barriers over a statically compiled language, and in typical Java fashion there’s a lot of finger pointing at Jigsaw and Vert.X as answers to Java’s failings, but the truth is that the former has been in development for years and the latter is massively complicated for Java’s target audience. I believe they are also working on fibers, but again that’s far down the line.
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.
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.
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.
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?
In larger companies, spending less on gas can also save you a lot of money. If I can write a Go app that doesn't require as much AWS compute, or have a type system that lets me spend less time on bugs and more time on features, that's hitting my bottom line.
>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.
>Frameworks trade choice for supposed convenience.
It's not just convenience. By coalescing on one standard set of libraries it becomes much more likely that those individual libraries will be maintained.
>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.
What you describe in the first half is effectively recreating Rails. Expending that initial cost in order to avoid the possibility of expending it later doesn't make sense.
And you're not right about the cost of switching from Rails. You can use pretty much all the code you write without Rails. The effort will come in creating whatever it is you want to use to replace Rails.
Go doesn't have a proper, complete type system. This means entire classes of preventable bugs are not prevented by the compiler. Yeah, its fast, but you can pass in null instead of object references and the compiler won't even bat an eye. Not to mention the extremely verbose error handling and the lack of abstractions all around (no sum types, no iterators, no array filter/map, etc) despite being more "high-level" than Rust in layman terms.
This is nonsense. There's no definition or checklist that defines what a complete type system is. In that vein, Haskell doesn't have a proper type system because it lacks dependent types, and a bunch of other features that are only available through language extensions.
We are still not at a place yet where the from first principles, type driven approach is going to always be the right choice over the hack out code approach. Rust simply takes more investment to learn, and more time to master, and while I agree that investment pays off 1000x, and that Java and C++ should stop existing, Go is a better fit for the people who just want a productive, reasonably efficient language that can get stuff done. Having a very simple hammer like Go that limits what people can do and sticks to what people already know is useful and beneficial.
The Go programming language and the compiler have too many soundness holes, therefore I call the type system incomplete. When you can pass in a null literal in place of an object and the compiler doesn't stop you, it goes against any common sense. Not to mention the pervasive use of reflection (interface{}) due to lack of generics.
Allowing null pointers to exist in a new programming language is a decision to ignore decades of progress in pl theory and type system research. It makes sense for google knowing the motivation behind Go, but telling people to avoid Rust unless they need polymorphism or performance is disingenuous at best.
> We are still not at a place yet where the from first principles, type driven approach is going to always be the right choice over the hack out code approach.
Why not?
C# 8 will fix this by switching defaults (opt-in due to backwards compatibility), and Java has type annotations since ages.
Hence why it feels wrong to a new kid on the block to ignore what the language community at large already agreed were design errors.
"By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed" - Fran Allen
Why do people pushing those claims think a go program compiled down to native executable is slower then rust Is it the rust compiler is better ? Is the go stdlib slower ? Is it the gc
The GC is going to add some overhead is it that bad for most uses except for real time critical large s/w
- The Rust compiler uses the LLVM backend, which is generally more aggressive about optimizations and code generation. The Go compiler is a custom compiler (I think plan 9 inherited) and as of fairly recently didn't do some optimizations that are fairly common otherwise (non-leaf inlining).
- Rust as a language heavily favors automatic (stack) allocation, and does not favor complex object graphs, so that will often help make algorithms more cache-friendly. In go, stack allocation is strictly an optimization. This is somewhat defeated by the common use of 'smart' pointer types.
- Due to using segmented stacks, the function prologue/epilogue is a bit more involved in go, than it is in a language like rust.
So with rust, it is - with some work - possible to have code that executes as the equivalent C code would. I guess in go you could too, but it'd be quite a bit harder, and go against the grain of the language.
Compared to the performance of a typical interpreted dynamic language, this is a fairly marginal difference however.
Yes, there's can be benefit to starting from scratch with a different language w.r.t. training new teams with good habits and skills from the start.
But going into Rust just because it's fashionable at the moment is a recipe for pain several years down the line.
If you want a working pain-free solution learn C++17 instead.
A solution to what, exactly? I'll admit I haven't worked with C++ in awhile, but I'm skeptical of C++AnyYear being "pain-free". What do you like in C++17 that you feel is lacking in Rust?
C++ 17 is still a mess. You still lack a proper package manager, type constraints, modules, sane lookup rules for function calls, thread safety, a proper monastic future type, I could go on.
Also most people won’t see C++ 17 or 14 for another decade. Even if the language decides to start bolting on more features the ecosystem is still very slow.
No, it is not.
> proper package manager, modules
That's an OS usability issue, not a language problem. Personally, Nix solved this for me.
> type constraints
C++ has type constraints, and ones that actually work. I suspect what you call 'type constraints' is something that can't exist if you understand the difference between 'run-time' and 'compile-time'.
> sane lookup rules for function calls
A very minor issue. If you don't like function overloads, then don't use them.
> thread safety, a proper monastic future type
Please no. The kind of 'thread safety' you want destroys the benefit of using threads in the first place. C++ threading is perfect as it is.
> Also most people won’t see C++ 17 or 14 for another decade.
Frankly, I don't care about these twisted people stuck in enterprise hell.
As a system guy, I am also happy to follow two OS projects in these two:
[1] https://github.com/mit-pdos/biscuit [2] https://github.com/redox-os/redox