Live data from Hacker News

Why We Switched from Python to Go (2021)

softwareengineeringdaily.com

271–280 of 301 posts

Re: Why We Switched from Python to Go (2021)

#271
post #228

Earlier quoted context omitted.

> As with all of these posts, the big reason is never really written: > "I just wanted to learn a new language" Strong disagree. If the actual purpose was learning new things, they'd have chosen a language which does things a little differently than all of the mainstream. At least Haskell or some Lisp... The fact they chose Go shows they care primarily about the practical side.

They didn't say they wanted to learn new things, they wanted to learn a new language. I can want to learn how to drive a race car in addition to my Toyota Corrola without wanting to lear how to operate a crane (though that would be pretty interesting honestly).

Where is the joy of learning a new language if not for learning new concepts? It just does not make sense to me. Learning a new standard library and build tools and all that stuff? Is that much fun?

People want to learn a new language for reasons: perhaps they want to learn new concepts, perhaps they want a language that's faster, perhaps they want a more mature ecosystem, perhaps they want to increase their employability. There aren't people who "want to learn a new language" as their ultimate end goal.

Re: Why We Switched from Python to Go (2021)

#272
post #271

Earlier quoted context omitted.

They didn't say they wanted to learn new things, they wanted to learn a new language. I can want to learn how to drive a race car in addition to my Toyota Corrola without wanting to lear how to operate a crane (though that would be pretty interesting honestly).

Where is the joy of learning a new language if not for learning new concepts? It just does not make sense to me. Learning a new standard library and build tools and all that stuff? Is that much fun? People want to learn a new language for reasons: perhaps they want to learn new concepts, perhaps they want a language that's faster, perhaps they want a more mature ecosystem, perhaps they want to increase their employab…

Maybe go is faster than any other language they've used? I'm not contending the fact that they have a reason for wanting to learn go as that new language. Just that your claiming they clearly weren't interested in learning since they didn't choose some esoteric language is fallacious.

Re: Why We Switched from Python to Go (2021)

#273
post #116

Earlier quoted context omitted.

yeah sure, I have zero user and well, it may be like that until my death :-) that project was an excuse for learning rust. But now I understant rust a bit more, well, I'm a bit scare to wait 45 sec on each build for a side project (ie a project I do on my very limited spare time) :-) but anyway, rust is really cool to work with (I have a python/C++/assembler/R background). The level of checking it does is really mind…

Try to debug where your compile times are going[1][2], but if you want a good rule of thumb: separate your crate into multiple if you can (that way incremental compilation will yield better results), switch to an alternative linker, like mold or lld, and use trait objects instead of generics (monomorphization can be expensive during compilation, while trait objects can be slower at runtime, but not enough to be worth…

Thanks to some hints in those articles (basically, enabling incremental builds on release mode), I've been able to remove about 70% (yes!) of the build time :-)

Thanks!

Re: Why We Switched from Python to Go (2021)

#274

Earlier quoted context omitted.

For a lot of people like me, Go was something of a better scripting language. It wasn't as hard to grok as C or Rust, it wasn't as slow as Ruby, Python or PHP. most of all, it it was designed to make use of multiple cores. Surprisingly, having testing and formatting built into the tooling is also a huge win after spending years debating and changing choices in scripting land. Go is the new PHP/Node.js and Rust is the…

My feelings exactly. I love go because of how productive and resilient can be. In months programming in it I've barely had any null pointer exceptions. If it compiles, and passes the linters, it mostly works aswell.

Yeah, null pointers and the compiler writing more code for you (overlaps with generics) are pretty high on my wish list.

I'm bringing someone up in Go and they forget to initialize some map or struct: `&Foo{data:map[int]int{}}` and crash the app.

Re: Why We Switched from Python to Go (2021)

#275
post #261

Earlier quoted context omitted.

> I run a service that uses 4 threads in Python and it's horribly slow and unreliable. I worked on a service in Go that used hundreds of concurrent go routines and it was reliable as hell. That is very anecdotal to the point where I’m not sure it is all that useful. Go is supposedly good at parallelism, yet it has plenty of warts to the point where it is not at all more stable than any other mainstream language out t…

Java didn't have a comparable thread/worker model to Go until this year, and arguably added it because of the success of Go routines for highly parallel services. Also, go accomplishes the same with much less verbosity because it's the default operating mode. So yes, you can do everything with Java that you can with Go (not true with Python) but it's a bit like using a semi-truck to commute.

Let’s not mix up virtual threads with the overall paradigm used for parallelism. Sure, on the former front Go was ahead for a time, but both are still pretty prone to race conditions and all the usual problems associated with parallel code.

Re: Why We Switched from Python to Go (2021)

#276

Earlier quoted context omitted.

Whenever someone complains about Python's indentation-as-syntax, my mind translates it as "this programmer writes terribly formatted code". If your code is properly formatted, then indentation will never be a problem. Copy/pasting large blocks, yeah, you can mess it up. But any editor worth using will let you select several lines of text and hit Tab or Shift-Tab to add/remove an indentation level, so fixing it only t…

> But any editor worth using will let you select several lines of text and hit Tab or Shift-Tab to add/remove an indentation level ...or has equivalent functionality that doesn't require the mouse ;)

Selecting multiple lines of text in an IDE does not require a mouse. Just hold Shift and use the up/down arrows.

The ability to select text in this way has existed in Windows for at least 20 years.

Re: Why We Switched from Python to Go (2021)

#277
post #169

Earlier quoted context omitted.

> 1) Easy to use pointers. There's just pointers, not like C where you can have anywhere from 4 to 8 different types depending on your platform. And no, pass by reference vs. value are not the same as pointers. Do you mean C++? Or am I confused?

Null, void, wild, dangling in core C. DOS also had far, near. I believe one of the Windows Visual something platforms had extensions that added another three or four.

I love Golang but its pointers are awful. "Nil is not really Nil" has tripped >1M Go programmers. It's the "trillion dollar" mistake.

People make fun out of C++ all the time. Yet, Go has some extraordinary Gotchas of its own. You need to read "The Go Bestiary" to make sure you don't blow your head off.

Re: Why We Switched from Python to Go (2021)

#278

Earlier quoted context omitted.

Ya, and if you look at the language space, there's nothing else that offers #1. That set of features isn't related to the language itself (though the language was designed to allow those features). This is where Go is appealing, it's not the language itself, it's the properties it brings with it. Cross-compilation, multi-spec, reasonable performance and low memory footprint. Single binaries. And I'd add fast compilat…

That's a great point, and one I hadn't considered. One language feature that Go brings is first-class multi-threading and communication amongst and with child threads. The only languages I know that can compete with Go with similar properties are Nim, Zig, and Rust. I'd like to include Delphi / Free-Pascal, but cross-compilation can be a bit of headache at times.

I didn't know Mom and Zig had those properties, I'll have to check them out.

Rust I believe doesn't do true cross-compilation, isn't it just relying on you using virtualization like docker and other to do so?

Re: Why We Switched from Python to Go (2021)

#279

Earlier quoted context omitted.

> But any editor worth using will let you select several lines of text and hit Tab or Shift-Tab to add/remove an indentation level ...or has equivalent functionality that doesn't require the mouse ;)

Selecting multiple lines of text in an IDE does not require a mouse. Just hold Shift and use the up/down arrows. The ability to select text in this way has existed in Windows for at least 20 years.

I've literally never coded in Windows. Seems like a weird choice.

Re: Why We Switched from Python to Go (2021)

#280

Earlier quoted context omitted.

Python is a pretty terrible language to work with. Tooling sucks. Dependency conflicts are common. There's no test framework/runner worth a damn. Web frameworks are inferior to those in most other languages. If you're doing data science things, it's hard to beat pandas/numpy. I get that those are popular in that community because the barrier to entry with Python is low. People who are just looking for a tool to solve…

> Web frameworks are inferior to those in most other languages. That's quite a statement. Go on, for most of the other languages, show me a web framework that's better than Django. Python absolutely has deployment challenges, but the performance is Good Enough™ and the speed of modelling and maintaining and accessing databases in Django's ORM is so much better than anything else I've found. Its Admin interface too is…

> That's quite a statement. Go on, for most of the other languages, show me a web framework that's better than Django.

I think that’s subjective, so take this with a grain of salt. I do have a different opinion though. Also, my point isn’t to argue, but to encourage consideration.

I’ve used Django and Python quite extensively in the past and I would say that, for me, Phoenix/Elixir and Ruby on Rails are both better web frameworks than Django.

The reason I feel this way is that Phoenix/Elixir, for example, has much better dependency management and tooling than Python/Django (e.g., Mix is vastly superior to Pip, in my opinion).

Also, when I was using Django in the past, even the core team suggested using a different directory layout than is generated by default. This meant that every Django application I worked on had a completely different project layout. Both Phoenix and Rails are more opinionated regarding their project layouts. Some may consider this bad, but the benefit is I can go to any Phoenix or Rails project and instantly be productive because I know where all my controllers, models, views, templates, and contexts are going to be. I also like that Phoenix is much faster, more scalable, and makes better use of hardware resources than either Python or Ruby.

I think Python and Django are excellent, but I’d place them at #3 in my top-three list of web frameworks. That’s just my opinion though.

Post reply on HN