31–40 of 91 posts
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
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 pro…
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.
Earlier quoted context omitted.
> 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.
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 com…
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.
Earlier quoted context omitted.
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 com…
>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…
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.
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 pro…
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…
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.
Earlier quoted context omitted.
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 li…
Sincere questions, I don't come from a OOP background, and do have plenty of Go! experience, so I feel like I'm missing the nuance of this post. 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 b…
“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)
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.)
Go has not displaced anything around here. Still plain old Java, .NET and C++ as always.
Unity is increasing C# popularity, though. So maybe .NET is not going away, at least yet.
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.
Earlier quoted context omitted.
Go has not displaced anything around here. Still plain old Java, .NET and C++ as always.
Where I'm located, .NET has died years ago. Just Java, Go and C++ now. I guess these things are regional. Unity is increasing C# popularity, though. So maybe .NET is not going away, at least yet.
Earlier quoted context omitted.
Sincere questions, I don't come from a OOP background, and do have plenty of Go! experience, so I feel like I'm missing the nuance of this post. 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 b…
> 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 fixe…
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.