Earlier quoted context omitted.
Rust is descended from ml? Isn't Rust a algol based language? Is it functional?
OCaml was a really strong influence on Rust. The first Rust compiler was written in OCaml. Rust's traits are also similar to Haskell's typeclasses.
Why we switched from Python to Go
211–220 of 406 posts
Re: Why we switched from Python to Go
#212Earlier quoted context omitted.
That's a very good thing for a language to have, indeed. But Go isn't the best thing to look into for productivity-via-the-type-system. What is (barring the purely functional languages' learning curve) is most any ML descendant; albeit Rust in particular if Go-like performance is desirable.
Rust is descended from ml? Isn't Rust a algol based language? Is it functional?
Re: Why we switched from Python to Go
#213Earlier quoted context omitted.
elaborate?
I've occasionally had things spontaneously break. Most recently the cryptography package just stopped installing on deployment. Had to add a pip upgrade on deploy, which somehow prevented the AMI I was using from installing some of its requirements. Had to add those packages to my project requirements. Also some of the data analysis packages don't work with virtualenv.
Erm... Why the heck are you running pip when deploying software? O_o It should be a build step, not a deployment step.
Re: Why we switched from Python to Go
#214Earlier quoted context omitted.
IMO Go has poor primitives that make even straightforward code needlessly complicated. Slices are probably the worst. Compare Python's way to inserting a value into a list: a.insert(i, x) With the way that the Go docs suggest: a = append(a[:i], append([]T{x}, a[i:]...)...) Sorting and for-range loops are other examples.
I prefer to the Go way. The python way gives people the impression that the insert operation is cheap. In fact, it is not.
Re: Why we switched from Python to Go
#215Earlier quoted context omitted.
I tried using Go this weekend and basically just abandoned it when I learned that it only had 'generic's for three built-in types and other than that you are forced to essentially dynamic cast everywhere. I just don't get the appeal. Go seems a lot like what you'd get if you just removed every language feature that anyone has ever complained about; for good reason or not.
It seems like the domains where Go is used often don't make heavy use of custom containers or data structures, so that makes the pressure on the language makers lower than it would otherwise be.
Re: Why we switched from Python to Go
#216Earlier quoted context omitted.
The answer is that for a huge variety of software, performance is not important, or perhaps is only important for a subset of the application. My personal experience is that the dynamic languages you've laid out generally have frameworks that are extremely conducive to rapid prototyping (Django is my favorite). I've seen and done the dance many times -- start with a Django/Rails/Laravel app, get a free admin and buil…
Yeah, plus even if performance is important, the app layer isn't necessarily the best place to optimize. It doesn't really matter how fast you sprint between database calls if the database and its IO dominate your site's performance profile, which they often do...
A python application can be anywhere from 10x to 50x slower than a native application. It also probably consumes at least 5x more memory.
Writing the same app in a compiled language is not even an optimization. It's just baseline work to ensure the code is not super slow.
Like, if you know you will sort a list of 10 items, choosing quicksort from the stdlib instead of bubble sort is not even an optimization. It's just common sense.
Re: Why we switched from Python to Go
#217Python was my entry into the programming world, and I've been an evangelist ever since... Or I was until I ran into distribution and parallelism. Since then, Nim has been my go-to language of choice. It is all that Python was, plus unbelievable speed, compiling to shippable binaries, and some other cool language features that admittedly, are still beyond my scope of abilities. Still quite lacking in libraries compare…
Agreed completely. We're in the process of porting our Python 'shim' (aka agent, at https://Userify.com - plug SSH/sudo key management) to Nim right now, so that we can provide a fully static shim for CoreOS and other minimal distros, and eventually Windows; there are a few languages that can do this cleanly, such as Go, Ocaml, and Lua, but Nim is just blindingly fast and actually pretty fun to code in. Great stuff.
There are some companies using Nim, but they're not in this list
Re: Why we switched from Python to Go
#218Re: Why we switched from Python to Go
#219Earlier quoted context omitted.
I prefer to the Go way. The python way gives people the impression that the insert operation is cheap. In fact, it is not.
WTF?! Isn't the point of an abstraction to make simple what is complex? Insert into a list should always be like the python example. If go's standard list doesn't have that, maybe it's time for someone to write a better library.
Re: Why we switched from Python to Go
#220Wait just one minute, Thierry... Are you telling me that Python helped you create a viable tech-oriented newsfeed and activity stream business, serving 500 companies and more than 200Million "end users"? That sounds like a great incentive for any entrepreneur to get started with Python. You've gotten this far by using the language you've turned away from! Further, I'm confident you didn't solve every challenge you've…