Hacker Newsnew | past | comments | ask | show | jobs | submit | gtycomb's commentslogin

It is here in HN that I first heard Pablo Neruda's "No culpes a nadie". Even though a fan of Neruda I somehow had missed this. Perhaps this speaks to you something too:

        ## Don't Blame Anyone

 Never complain about anyone, nor anything,
 because basically you have done
 what you wanted in your life.

 Accept the difficulty of improving yourself
 and the courage to start changing yourself.
 The triumph of the true man emerges from
 the ashes of his mistake.

 Never complain about your loneliness or your
 luck, face it with courage and accept it.
 In one way or another it is the outcome of
 your acts and the thought that you always
 have to win.

 Don't be embittered by your own failure or
 blame it on another, accept yourself now or
 you'll keep making excuses for yourself like a child.
 Remember that any time is
 a good time to begin and that nobody
 is so horrible that they should give up.

 Don't forget that the cause of your present
 is your past, as well as the cause of your
 future will be your present.

 Learn from the bold, the strong,
 those who don't accept situations, who
 will live in spite of everything. Think less in
 your problems and more in your work and
 your problems, without eliminating them, will die.

 Learn how to grow from the pain and to be
 greater than the greatest of those
 obstacles. Look at yourself in the mirror
 and you will be free and strong and you will stop
 being a puppet of circumstances because you
 yourself are your own destiny.
 
 Arise and look at the sun in the mornings
 and breathe the light of the dawn.
 You are part of the force of your life;
 now wake up, fight, get going, be decisive
 and you will triumph in life. Never think about
 luck because luck is
 the pretext of losers.


That is not a Neruda poem. It is apocryphal. Pablo,ever the communist, would have never written such a piece of libertarian crap.I am surprised that such a fan of Neruda as you claim to be did not notice that.


I was about to share it with people claiming it was from Neruda. I did a bit of searching and it appears that it is indeed apocryphal. Thanks for saving me the embarrassment.


Not surprised to see such a salty reply from a Neruda fan.


I am not a particular fan of Neruda (I prefer Vallejo,Ramos Sucre or Machado), so save your snarky comment.


I barely know anything about Neruda, and i was thinking... geez, I thought he was known as a good poet, did he really write that garbage? Maybe it lost something in translation? Whether you 'agree' with what it's apparently didactically trying to say or not, that's just a bad poem.


> Maybe it lost something in translation?

Native Spanish speaker here, and the original text is just as lackluster


Savage burn. Their True Neruda Fan Score is never going to recover from that one.


Perhaps you in your limited understanding of communism, fed to your by your propagandist overlords to control you, have failed to understand how someone could hold both views. Or maybe you just don't get people. multitudes.

Either way, it's a fact. Protip: this is the part where you see reality and update your perspective


I wish I could give you a thumbs up for speaking plain truth here. Anyway programmers will find out for themselves how best to satisfy their customer need.


In addition to your list here, I am drawn by ES6 on the backend. This is not javascript of the early days.

On Differentiable Programming, you might be aware of a tensorflow counterpart in javascript:

https://www.tensorflow.org/js

I tested this to a certain extent and its not a toy. Its well thought out product from a very talented team, and has the ease of coding that we love about javascript. It can run on browsers!

This being said, we should note the strengths of a statically compiled language with the ease of installation and deployment like with Go, Rust, Nim, etc. in enterprise scale numerical computing.


Nim is a languge that has good performance and I had good experience porting an enterprise Python application to Nim (for performance gain). For a new user the risk obviously is the newness of Nim but the Nim team was very helpful and prompt whenever I posted a question. Its a very complete and surprisingly issue-less language.

Hopefully Arraymancer will help increase its reach, I wish the implementors all the best.


OP likes Swift and he compared it to other languages Python, Go, C++ & Rust, Julia. In the enterprise sphere that I am in, I haven't seen Swift and its hard to move a team in this direction at this point.

Python already drives a significant market and captured talent in numerical differentiable programming, particularly because of the ease with which prototyping and tuning is done with it. Obviously when we want to scale we have the conversation on some other option.Personally its a bit frustrating that Go support for TensorFlow or one of the competitors is not quite satisfactory and this is surprising, I can't explain it.

Instead of inventing any new language why don't one of you -- Python, Go, C++ & Rust, Julia, or Swift -- complete the job with end-to-end differentiable programming. 'Complete' to me means a language level seamless GPU (or related distributed/parallel architecture) and language level deployment ease (the kind of thing done with Kubernetes) and integration with embedded hardware.


Written form please. This saves time in many ways, such as searching for certain chunks of information when trying to form an early opinion on how this product fits one's need. I went through your dev documentation today and the organization is good. I wish you would present the more detailed booking example in the same conversational style as the shorter hello world example at start. When a developer sees the first page with the bullets of interesting features (service discovery, load balancing, etc), they would want to get a broader picture of the architectural approaches combining these features (through coding examples). Interesting work. Thanks for creating it.


Isn't it Go?


This is a fair question if you’re lucky enough not to be familiar with devops tooling.

No, it’s not Go. Go is a general purpose programming language. What parent poster wants is more like Terraform, but better (I assume). With semantics that reflect devops actions.

You might write that tool in Go :) but the users wouldn’t necessarily know. Just like a gamer doesn’t need to know about C++.


You could use Go to generate Terraform configs. I’m using Python to generate CloudFormation and it’s an order of magnitude easier and more maintainable than vanilla CloudFormation, especially for large integrations.


I don't miss generics either, not in the least. The interface system, Go's particular approach to it, takes me a long way ...

I won't ask for any new feature for today or tomorrow. But for day after tommorow, within a longer time research horizon, I wonder whether compiled and distributed Go applications can be made to interact along the lines of interfaces within an application now. May be its my struggle with Kubernates (as a newbie) that makes me want: Can there be secure language mechanisms supporting clustering, scheduling etc in a distributed enviroment with an external agent armed only with prior package interface definitions of a deployed Go application.

Please don't sacrifice performance, and fast compilation times. That module system is looking good!


Favourties: > Worked on most of the Go standard library. Primary author of net/http, database/sql, os/exec, Go's build/test CI system, etc.

Thank you. Software poetry they are to me.

And this one: > met Googler wife

Best wishes, Brad Fitz


I am an average Go programmer, so I may not be deep into Go as you might be. However the mention of GOPATH catches my eye. All my issues with GOPATH went away for me when I started using the Go Modules: https://blog.golang.org/using-go-modules. Also Go's approach to err is one the reasons I started gravitating to Go -- my old Go code is more readable because of the verbose (error as strings in my code) and hence easier to maintain. Go is a surprisingly practical language for distributed, system oriented, undertakings I'd say


I'm not going to lie, I never understood why the gopath was so hard for people until I saw a friend using it.

The go developers where all unix heads, and as unix heads setting a path env variable was so natural it almost doesn't bear mentioning.

A unix dev is going to follow the following flow: cd into the project i'm working on in the terminal (I use fasd for this) export my gopath from history (ctrl+r GOPATH=) launch emacs on the files I need develop

However, many "younger" devs grewup with IDE's. They interact with a project by launching goland, which means mucking with this stuff isn't first class.

Not that it adds much, just some food for thought on why GOPATH existed and you found it clunky.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: